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

[Vadim Zeitlin]

On Thu, 4 Apr 2019 23:47:05 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2019-04-02 02:22, Vadim Zeitlin wrote:
GC> > On Mon, 1 Apr 2019 18:47:49 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC>   http://git.savannah.nongnu.org/cgit/lmi.git/commit/?h=odd/multiarch
GC> [...]
GC> > - I actually don't remember why had I written that I preferred using
GC> >   symlinks before, but now I have serious doubts about this. As long as
GC> >   we have this PERFORM variable anyhow, what prevents us from determining
GC> >   the right PATH/WINEPATH combination once and putting it inside this
GC> >   variable?
GC> 
GC> $PERFORM is either 'wine' or '', as in
GC>   "$PERFORM" lmi_wx_shared.exe

 Yes, so if we set it to "PATH=... WINEPATH=..." it should work, shouldn't
it? BTW, just to be clear, I was only speaking about using this variable in
the makefiles, not interactively.

GC> Or would adding {$HOST, $PATH, $WINEPATH} to the existing $PERFORM
GC> be enough to accomplish our purposes? We'd have to take care to
GC> write it in front of commands we enter manually such as:
GC> -  wine ./lmi_wx_shared --ash_nazg --data_path=/opt/lmi/data
GC> +  $PERFORM ./lmi_wx_shared --ash_nazg --data_path=/opt/lmi/data
GC> but that's not so terrible, as I already must remember to write
GC> "wine" there.

 Yes. FWIW other makefiles I've seen call such variables RUN or
RUN_<SOMETHING>, which might be a bit more clear than PERFORM.

GC> And maybe that could be replaced by some hypothetical
GC> script whose name is easier to type, such as 'do':
GC>   do ./lmi_wx_shared --ash_nazg --data_path=/opt/lmi/data
GC> and thus [obligatory Molière quote elided] it's something I've
GC> already been doing without realizing it (though everyone else would
GC> have to start speaking prose, too).

 Indeed, many other people already do do something like this.

GC> But first let's establish the goal, as to which I think we agree:
GC> 
GC> >   [...] It looks like this ought to make everything work and we
GC> >   wouldn't need to update the symlinks. In particular, I'd really like to
GC> >   have both 32- and 64-bit versions on the same machine in parallel, which
GC> >   is not really compatible with needing /opt/lmi/bin symlink to point to
GC> >   just one of them.
GC> 
GC> Yes, that's exactly my goal: to have
GC>   {32,64}-bit X {linux, msw} X {gcc, clang} X ...
GC> builds coexisting simultaneously;

 Perfect; we are in absolute agreement then.

GC> And here are some things that aren't quite use cases, but maybe
GC> "desiderata":
GC> 
GC> - We shouldn't need to spell out an architecture whenever we
GC>   run a command. I.e., our custom is to navigate thus
GC>     cd /opt/lmi/bin
GC>   and then run commands such as
GC>     wine ./lmi_wx_shared
GC>   but it would be less convenient to have to navigate thus
GC>     cd /opt/lmi/x86_64-w64-mingw32/bin
GC>   or alternatively to enter commands such as
GC>     wine /opt/lmi/bin/x86_64-w64-mingw32/lmi_wx_shared

 Sorry if I'm just stating the obvious, but there is no escaping the fact
that you will need to specify one of N builds of lmi to use. It can be done
either globally, i.e. by setting PATH global variable (likely by sourcing
some shell script taking care of doing it and everything else properly), or
for each command, by specifying the path, or at least a subset of the path,
in it.

GC> - We must retain the ability to work with multiple terminals.
GC>   For instance, I just run
GC>     konsole --tabs-from-file ~/konsole_tabs &
GC>   to get five predefined terminal tabs:
GC>     vim -p /opt/lmi/src/lmi/tabs/**/startup*
GC>   and I want to do
GC>     /opt/lmi/src/lmi[0]$make install
GC>   in the "Build" tab to build with my latest code change, then
GC>     /opt/lmi/bin[0]$wine ./lmi_wx_shared
GC>   in the "Run" tab to run lmi with that code change. That is,
GC>   I really want all these tabs to use the same architecture.

 I'd say that this is a counter goal as I think it would be useful to be
able to test different builds of lmi in parallel in the different terminals
or GNU Screen windows. I.e. you should be able to launch konsole itself
from a parent terminal with the same environment set for all its tabs by
default, of course, but it shouldn't somehow ensure that the environment is
indeed the same for all of them.

GC> What we have today is a set of variables in the environment:
GC> 
GC>  - $PERFORM for running 'wine' wherever appropriate
GC>  - $LMI_HOST to select an architecture
GC>      (we'll stop using it to set $PERFORM because that's nasty)
GC>  - $PATH to find libraries, both when building and running lmi
GC>  - $WINEPATH to find libraries, similarly, under 'wine'
GC> 
GC> and what we want is a method to choose one at a time among many
GC> configurations--one that supports frequent switching robustly.
GC> Candidates:
GC> 
GC> (1) [not recommended] Set all of the variables above, compatibly,
GC> all the time, by hand. This is fragilissimo: after trying it,
GC> I thought symlinks were much easier.

 Yes, doing it manually is definitely too error-prone.

GC> (2) One environment variable (benign version): $PERFORM, caffeinated.
GC>   MAGIC="PATH=/some/paths WINEPATH=whatever HOST=gnu_host_string 
PERFORM=whatever"
GC> I already use 'wine' wherever necessary on the command line,
GC> and makefiles use $PERFORM wherever necessary to support my
GC> work in a chroot; everyone else would have to use it, too
GC> (so it imposes a new inconvenience on everyone but me).
GC> But this alone wouldn't DTRT for
GC>   make install
GC> or other such commands.
GC> 
GC> (3) One environment variable to bring them all and in the
GC> darkness bind them (maleficent version): $PERFORM on crack.
GC> We'd have to type it before 'make', e.g.:
GC>   "$INCANTATION" make install
GC> but it would be robust...unless we forget to use it, and type
GC>   make install
GC> which could break everything. And the 'do' script hypothesized
GC> above, on crack, would be just as evil.
GC> 
GC> (4) A different sort of script--call it 'set_architecture.sh',
GC> for instance. It would set all appropriate environment variables
GC> consistently (so we'd have to 'source' it rather than run it).
GC> We'd run it each time the architecture is to be switched. This
GC> is a disciplined version of (1), without the inconvenience of
GC> (2) or (3).

 I think this is the best approach for interactive use. I am not sure if
this should be used in the makefiles. At the very least, running "make
HOST=xxx" should complain if "xxx" is different from the host set in the
environment.

GC> (5) [branch 'odd/multiarch'] Symlinks:
GC>   ln -sfn /opt/lmi/"$HOST_ARCHITECTURE"/local /opt/lmi/local
GC>   ln -sfn /opt/lmi/"$HOST_ARCHITECTURE"/bin /opt/lmi/bin
GC> This has the unique advantage that it works across terminals.
GC> It also seems to be the only one so far that supports this
GC> convenient usage:
GC>   cd /opt/lmi/bin
GC>   [wine] ./lmi_wx_shared
GC> (without changing $PATH, it makes $PATH point elsewhere).

 Of course it shouldn't be forbidden to create such symlinks if you'd like
to. But I just hope it won't be required to create them and that some way
of running lmi without them would also be available.

GC> (6) Let's step back and look at this from another angle. What
GC> exactly do we have in /opt/lmi/bin/ that we want to run as ./foo
GC> when that's our current working directory? `ls /opt/lmi/bin` finds:
GC> 
GC> DLLs not directly invokable:
GC>   skeleton.dll, wx_new.dll, libantediluvian.dll, liblmi.dll
GC> 
GC> never run at the command line:
GC>   antediluvian_cgi.exe, antediluvian_cli.exe
GC>   bcc_ar.exe, bcc_cc.exe, bcc_ld.exe, bcc_rc.exe
GC>   elapsed_time.exe
GC> 
GC> rarely run at the command line:
GC>   generate_passkey.exe
GC>   ihs_crc_comp.exe
GC>   product_files.exe
GC> 
GC> these are the only ones we really care about:
GC>   lmi_cli_shared.exe
GC>   lmi_wx_shared.exe
GC>   rate_table_tool.exe
GC>   wx_test.exe
GC> 
GC> ...so there are only four special cases, all similar; can they be
GC> treated otherwise? e.g., via four nearly-identical shell scripts?
GC> which could even subsume variations across architecture etc.:
GC> 
GC>   ./lmi_cli_shared.sh i686

 Is this really better than

        $ lmi_run lmi_cli_shared i686

? The advantage of a single lmi_run script is that there is just one of it,
and not 4 (or, tomorrow, 5...).

GC> (7) As an alternative to (6), we could write a 'switch_arch.sh'
GC> script that just establishes a symlink for each of those binaries.
GC> I'm not sure that's much different from (5), unless file symlinks
GC> are generally preferable to directory symlinks for some reason I'm
GC> not aware of. But this seems to be a popular approach for 'install'
GC> targets in autotoolized libraries. And, like (5), it transparently
GC> affects already-running terminals, which from my POV is good.

 From my POV it's bad and I indeed don't see any advantage to this approach
compared to (5).


 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
(after possibly checking for some common problems?) and for a "local", i.e.
per-command, solution it would be to have a "lmi_run" helper script. But,
of course, I'm not at all representative of the target demographic here,
and will find some way to do what I need to do anyhow, so please feel
completely free to ignore my preferences.

 Regards,
VZ