Re: [lmi] Directory structure for multiple-architecture builds

[Greg Chicares]

On 2019-04-23 00:28, Vadim Zeitlin wrote:
> On Mon, 22 Apr 2019 23:35:40 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> However, this isn't only a build system--it's also a collection
> GC> of scripts, makefile targets, and text-file collections of
> GC> command-line snippets that also help us test and use lmi. Those
> GC> snippets are just a subset of the commands we use or reuse every
> GC> day, and I want our everyday work to be disrupted as little as
> GC> possible--and only once: if we add clang support, that shouldn't
> GC> derange everything we do, all over again.
> 
>  What exactly is the currently planned disruption? I was under impressions
> that nothing much was going to change if you continued to use the default
> 32 bit architecture.

The crucial point is that $bindir changes when $exec_prefix does:

 prefix          := /opt/lmi
 # parent directory for machine-specific binaries
-exec_prefix     := $(prefix)
+exec_prefix     := $(prefix)/$(LMI_HOST)
 # binaries that users can run
 bindir          := $(exec_prefix)/bin

It changes from this single, simple directory:
  /opt/lmi/bin
to this pair:
  /opt/lmi/i686-w64-mingw32/bin
  /opt/lmi/x86_64-w64-mingw32/bin
so that running lmi from the command line requires the desired
architecture to be recited explicitly: the old simplicity is lost.
That's especially painful for anyone who works with the production
architecture every day, and rarely uses any other architecture.

OTOH, if we were to do:
  make all
  make bindir=/opt/lmi/bin install
then the simplicity is regained. Is that what you had in mind?
Because in that case truly nothing much would change in our
day-to-day work on the command line with the single architecture
deployed in production.

Of course, the same effect could be achieved more easily by changing
the value in 'GNUmakefile' directly, once and for all:

 # binaries that users can run
-bindir          := $(exec_prefix)/bin
+bindir          := $(prefix)/bin

$bindir is used for three targets only:

 - fardel, which assembles a production release (single architecture only)
 - system_test, which succeeds only for the single production architecture
 - install, which exists only for the convenience of command-line users

and our convenience is best suited by 'bindir := $(prefix)/bin'.
I had been trying to adhere strictly to the "standards" here:
  https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
which prescribe setting bindir as "$(exec_prefix)/bin". If we follow that,
then all everyday commands change, e.g.:

git diff --word-diff-regex="[^ /]+" --unified=0 \
  origin/master HEAD -- INSTALL README.schroot debian/menu gwc/develop1.txt 
gwc/develop2.txt tabs/5/startup_script

It seems better to sidestep all that inconvenience by ignoring that GNU
prescription and setting bindir to "$(prefix)/bin". Do you see any reason
not to do so in 'GNUmakefile'?

> GC> [...] enable
> GC> us to work on several different lines of development at once. For
> GC> example, with 'prefix=/opt/lmi-mst' we could make changes to MST
> GC> files, while in a separate prefix we could implement new products,
> GC> while in a default 'prefix=/opt/lmi' we could prepare releases.
[...]
>  The standard solution to this problem is to use different build
> directories and make the program runnable without installing it. And it's
> not that difficult to use lmi without installing it, after all I do it all
> the time when building it with MSVC -- but it does require a few hacks and
> I'm not sure you'd be interested in them.

It's not urgent, but at your convenience I'd like to know how you do this,
in case you use a method that I haven't even thought of.

>  So it does look like generalizing set_arch.sh to set_lmi_env.sh and
> allowing to define a different installation directory there would make
> sense for lmi.

Exactly.

> Ideally it would be possible to specify both non-default
> build and installation directories at once.

I think the odd/multiarch branch handles arbitrary build directories
pretty well already. Multiple installation directories would be
difficult with today's 'install' target, which simply
 - copies lmi's own binaries  to $INSTALL/bin
 - copies (or generates) data in $INSTALL/data
and relies on $PATH and $WINEPATH to find libraries for the appropriate
architecture. Options for making an $INSTALL directory configurable, and
permitting multiple independent installations:

(1) Copy all required libraries as well as lmi's own binaries, so that
each $INSTALL directory would have a complete set and there'd be no
need to alter any path variable in the environment. That's exactly
what 'make fardel' already does. That's the simplest solution, so is
there any reason why it wouldn't also be the best? When the 'install'
target was designed, around the turn of the century, hard drives were
slow and tiny, so copies were costly in time and space. Today, though:

$du -sh /opt/lmi/fardels/lmi-20190204T1652Z 
167M    /opt/lmi/fardels/lmi-20190204T1652Z
$du -sh /opt/lmi/bin                      
193M    /opt/lmi/bin

and most of the files those two directories contain are identical:
the fardel has only 48M of files that aren't already in /opt/lmi/bin,
so this option would grow an $INSTALL_DIR by 48/193 = 25%.

(2) We could economize space by setting up symlinks, e.g.:
  /opt/lmi/$INSTALL -> /opt/lmi/$ARCHITECTURE/bin
  /opt/lmi/$INSTALL/local_bin_dir -> /opt/lmi/$ARCHITECTURE/local/bin
  /opt/lmi/$INSTALL/local_lib_dir -> /opt/lmi/$ARCHITECTURE/local/lib
and then put those relative directories on $PATH. But that exposes us
to pitfalls, and saves little over the simple-as-dirt option (1).
And once we get a stable file system that handles deduplication
automatically, option (1) will be equivalent, and simpler, so we'd
eventually revert to (1) anyway.

(3) I thought of another idea or two, but then realized that we had
already discussed and dismissed them.

Do you see any reason not to choose option (1)?