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

[Vadim Zeitlin]

On Mon, 22 Apr 2019 23:35:40 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2019-04-15 23:38, Greg Chicares wrote:
GC> > On 2019-04-05 03:08, Vadim Zeitlin wrote:
GC> [...]
GC> >>  To summarize, my preference for a "global" solution would be to have a
GC> >> "lmi_setenv" script that would be sourced to set up everything correctly
GC> > 
GC> > I believe that describes 'set_arch.sh'.
GC> 
GC> We're nearly ready to merge branch foo/multiarch into trunk.
GC> Ignoring commentary about a very few open questions, most of
GC> the substantive differences, viewed thus:
GC>   git diff --word-diff-regex=. --unified=0 origin/master HEAD

 FWIW this results in rather strange output for me, I think using word
regex of "[^ /]+" generates something more readable.

GC> are a simple matter of inserting $LMI_HOST (or some alias like
GC> $(host_type), or a particular value like "x86_64-w64-mingw32")

 ... but I can still see this anyhow.

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.

GC> One straightforward way is to use something like 'set_arch.sh'
GC> (with '--host' and compiler combined into one token, where the
GC> specimen diffs above use only $LMI_HOST), but export some more
GC> variables along with $PATH and $LMI_HOST--for example,
GC>   LMI_BIN_DIR
GC>   LMI_DATA_DIR
GC>   LMI_TEST_DIR
GC> so that 'make system_test' would run
GC>   $PERFORM $LMI_BIN_DIR/lmi_cli_shared --data_path=$LMI_DATADIR
GC> and write its results in $LMI_TEST_DIR/md5sums. That would 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.
GC> Of course, git branches facilitate working with multiple versions
GC> of the source code, but source code is the only thing they manage:
GC> switch branches and you need to rebuild, because there's only one
GC> collection of compiled and generated files on disk at any moment.
GC> Instead, we want to switch branches without having to rebuild.

 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.

 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. Ideally it would be possible to specify both non-default
build and installation directories at once.

 Regards,
VZ