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

[Greg Chicares]

On 2019-04-15 23:38, Greg Chicares wrote:
> On 2019-04-05 03:08, Vadim Zeitlin wrote:
[...]
>>  To summarize, my preference for a "global" solution would be to have a
>> "lmi_setenv" script that would be sourced to set up everything correctly
> 
> I believe that describes 'set_arch.sh'.

We're nearly ready to merge branch foo/multiarch into trunk.
Ignoring commentary about a very few open questions, most of
the substantive differences, viewed thus:
  git diff --word-diff-regex=. --unified=0 origin/master HEAD
are a simple matter of inserting $LMI_HOST (or some alias like
$(host_type), or a particular value like "x86_64-w64-mingw32")
at the right point in some filesystem path, e.g.:

prefix        := /opt/lmi/{+$(host_type)/+}local
exec_prefix     := $(prefix){+/$(LMI_HOST)+}
pushd /opt/lmi/{+x86_64-w64-mingw32/+}bin
wine /opt/lmi/{+x86_64-w64-mingw32/+}bin/rate_table_tool
"$PERFORM" /opt/lmi/{+"$LMI_HOST"/+}bin/wx_test [...] | tee 
/tmp/lmi/{+"$LMI_HOST"/+}logs/gui_test
cd /opt/lmi/{+"$LMI_HOST"/+}bin
/opt/lmi/{+"$LMI_HOST"/+}bin/lmi_cli_shared
/opt/lmi/{+"$LMI_HOST"/+}bin/rate_table_tool
for z in /opt/lmi/{+"$LMI_HOST"/+}bin/* ;
/opt/lmi/{+"$LMI_HOST"/+}bin/generate_passkey >passkey
"$PERFORM" /opt/lmi/{+"$LMI_HOST"/+}bin/lmi_cli_shared

If this were C, we might abstract those insertions as a macro.
If this were C++, we might abstract them as a function. Either
way, it wouldn't seem right to insert a variable, particularly
because $LMI_HOST isn't really the right one--to support other
compilers like clang, we'll want to insert something else at
these points.

If this were merely a build system, we'd pass arguments like
"--exec-prefix=" to an autoconf 'configure' script, or use
a tool like 'pkg-config', or write a script like 'wx-config'.

However, this isn't only a build system--it's also a collection
of scripts, makefile targets, and text-file collections of
command-line snippets that also help us test and use lmi. Those
snippets are just a subset of the commands we use or reuse every
day, and I want our everyday work to be disrupted as little as
possible--and only once: if we add clang support, that shouldn't
derange everything we do, all over again.

One straightforward way is to use something like 'set_arch.sh'
(with '--host' and compiler combined into one token, where the
specimen diffs above use only $LMI_HOST), but export some more
variables along with $PATH and $LMI_HOST--for example,
  LMI_BIN_DIR
  LMI_DATA_DIR
  LMI_TEST_DIR
so that 'make system_test' would run
  $PERFORM $LMI_BIN_DIR/lmi_cli_shared --data_path=$LMI_DATADIR
and write its results in $LMI_TEST_DIR/md5sums. That would enable
us to work on several different lines of development at once. For
example, with 'prefix=/opt/lmi-mst' we could make changes to MST
files, while in a separate prefix we could implement new products,
while in a default 'prefix=/opt/lmi' we could prepare releases.
Of course, git branches facilitate working with multiple versions
of the source code, but source code is the only thing they manage:
switch branches and you need to rebuild, because there's only one
collection of compiled and generated files on disk at any moment.
Instead, we want to switch branches without having to rebuild.

Of course, it would be crazy to set LMI_{BIN,DATA,TEST}_DIR
manually, so we'd want something like a script to manage this:
  git branch lmi-mst
  ./set_arch --prefix=lmi-mst --host=i686-w64-mingw32
After a context switch like that, a command such as
  $PERFORM $LMI_BIN_DIR/lmi_wx_shared --data_path=$LMI_DATADIR
would do the right thing, immediately (as long as we had
previously run 'make install' in that context).

I suppose environment variables really would be the best means
of making these settings available. In makefiles and scripts,
the verbosity of calling a script like this:
  g++ $(wx-config --cxxflags) my_file.cpp
doesn't matter, but
  $(lmi-config --bin_dir)/lmi_wx_shared --data_path=$(lmi-config --data_dir)
is just too cumbersome to enter on the command line.

Anyway, I hope I've been able to express what I'd like to
accomplish, and as always I would greatly value your thoughts.