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

[Vadim Zeitlin]

On Wed, 24 Apr 2019 13:56:34 +0000 Greg Chicares <address@hidden> wrote:

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

 Oh, yes, of course, sorry for somehow forgetting this resulting in asking
a rather stupid question above.

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

 Yes, I think it's going to be difficult to justify so IMHO we need some
way of preserving the current layout by default.

GC> OTOH, if we were to do:
GC>   make all
GC>   make bindir=/opt/lmi/bin install
GC> then the simplicity is regained. Is that what you had in mind?

 I think it would be preferable if "make install" did the usual thing by
default and if we'd usually use /opt/lmi/bin for lmi binaries installation,
then it would be better to use this as default bindir value rather than
requiring to specify it explicitly on the command line.

GC> Because in that case truly nothing much would change in our
GC> day-to-day work on the command line with the single architecture
GC> deployed in production.

 This is certainly desirable, so the question is what's the best way to
achieve it, while still allowing to use a different "bindir" if desired.

GC> Of course, the same effect could be achieved more easily by changing
GC> the value in 'GNUmakefile' directly, once and for all:
GC> 
GC>  # binaries that users can run
GC> -bindir          := $(exec_prefix)/bin
GC> +bindir          := $(prefix)/bin

 This really makes exec_prefix useless though, so if we want to do it like
this, I'd rather get rid of exec_prefix completely. But this wouldn't be my
preferred way anyhow.

GC> I had been trying to adhere strictly to the "standards" here:
GC>   https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
GC> which prescribe setting bindir as "$(exec_prefix)/bin". If we follow that,
GC> then all everyday commands change, e.g.:
GC> 
GC> git diff --word-diff-regex="[^ /]+" --unified=0 \
GC>   origin/master HEAD -- INSTALL README.schroot debian/menu gwc/develop1.txt 
gwc/develop2.txt tabs/5/startup_script
GC> 
GC> It seems better to sidestep all that inconvenience by ignoring that GNU
GC> prescription and setting bindir to "$(prefix)/bin". Do you see any reason
GC> not to do so in 'GNUmakefile'?

 I think it would be better to just continue to set exec_prefix to prefix
by default and only set it to $(prefix)/$(LMI_HOST) if LMI_HOST is
explicitly specified. This does create an inconsistency, but we can't have
both perfect consistency and backwards compatibility and I think the latter
is more important than the former.

 The only alternative I can see is using a symlink "bin -> $LMI_HOST/bin",
but I don't believe the extra complexity of dealing with symlinks is worth
the small gain in perceived consistency.


GC> >  The standard solution to this problem is to use different build
GC> > directories and make the program runnable without installing it. And it's
GC> > not that difficult to use lmi without installing it, after all I do it all
GC> > the time when building it with MSVC -- but it does require a few hacks and
GC> > I'm not sure you'd be interested in them.
GC> 
GC> It's not urgent, but at your convenience I'd like to know how you do this,
GC> in case you use a method that I haven't even thought of.

 Looking at what I do now, I see that I've actually got rid of most of the
hacks some time ago and started using subst command to create the directory
structure lmi expects to have. The only remaining hack is that I use the
default value of the --data_path option pointing to "../data" directory
relative to the executable location. And previously I also had a hack to
replacing the hardcoded /etc/opt/lmi in configurable_settings.cpp with a
path relative to the program executable too.


GC> > Ideally it would be possible to specify both non-default
GC> > build and installation directories at once.
GC> 
GC> I think the odd/multiarch branch handles arbitrary build directories
GC> pretty well already.

 I haven't tested it, but can I actually do "make build_dir=/some/path"?
(BTW, I think "builddir" is more common than "build_dir" but I'm really
nitpicking now).

GC> Multiple installation directories would be
GC> difficult with today's 'install' target, which simply
GC>  - copies lmi's own binaries  to $INSTALL/bin
GC>  - copies (or generates) data in $INSTALL/data
GC> and relies on $PATH and $WINEPATH to find libraries for the appropriate
GC> architecture. Options for making an $INSTALL directory configurable, and
GC> permitting multiple independent installations:
GC> 
GC> (1) Copy all required libraries as well as lmi's own binaries, so that
GC> each $INSTALL directory would have a complete set and there'd be no
GC> need to alter any path variable in the environment. That's exactly
GC> what 'make fardel' already does. That's the simplest solution, so is
GC> there any reason why it wouldn't also be the best?

 Yes, I think it would be good to do this. Disk space is still not endless,
so I don't see what do we lose by using "cp -l", but it's a minor detail.

 Regards,
VZ