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

[Greg Chicares]

On 2017-05-23 14:29, Vadim Zeitlin wrote:
> On Mon, 22 May 2017 21:29:49 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Vadim--I'm hoping to build lmi and its dependencies simultaneously for
> GC> various hosts, all in the same chroot (running msw binaries via wine):
> GC>   - x86_64-linux-gnu (gtk)
> GC>   - x86_64-w64-mingw32
> GC>   - i686-w64-mingw32 (until we can convert users to x86_64)
> GC> and ultimately with clang as well as gcc, and I'm wondering what
> GC> directory structure to use. I imagine this is a problem you've already
> GC> solved; do you have a recommendation?
> 
>  To be brief, I use something similar to your (3): i.e. I put host-specific
> stuff in a directory called ${uname}-${uname -m}

Now I've done something like that, on this new branch:
  http://git.savannah.nongnu.org/cgit/lmi.git/commit/?h=odd/multiarch
and I'd be very glad if you would tell me what you think of it.

I've restricted this initial attempt to 32- and 64-bit msw builds,
but it shouldn't be too much extra work to extend it to other
architectures and other compilers...

> and I add a "-compiler"
> suffix when more than one ABI is used. So I can have directories like
> Linux-x86_64-clang, Linux-x86_64-gcc6 and even Linux-x86_64-suncc (yes,
> this one is not used much any longer, but it was nice to test with it when
> I had to build stuff under Solaris (which I still inexplicably regret
> (probably should blame Lem for this (and definitely not Tarkovsky))).

Are you saying that the film lacks the novel's depth?

> GC> I see (at least) three options:
> GC> 
> GC> (1) All binaries in one directory, with host-prefixed names, like gcc:
> GC>   i686-w64-mingw32-lmi
> GC>   x86_64-w64-mingw32-lmi
> GC>   x86_64-linux-gnu-lmi
> GC> I've never seen this style for anything but cross compilers. I could do
> GC> this for lmi itself, but dependencies like libxml2 don't generally have
> GC> prefixed names, and I'm looking for a single uniform approach.
> 
>  The only benefit of this approach that I see is that it allows to reuse
> architecture-independent files.

After spending much of the weekend wrestling with what I've finally
committed on a branch, I'd say it has one small additional benefit:
it would make it harder to mis-re-use architecture-dependent files.
IOW, perhaps I would have gotten a message like
  i686-whatever-lmi.exe cannot find i686-whatever-xml2.dll
instead of
  whatever-lmi cannot find xml2.dll
when there's obviously an xml2.dll on $PATH, or on $WINEPATH, or
even in one directory reachable through $PATH and another reachable
through $WINEPATH.

But that would have been helpful only in initial debugging. After
a few weeks, it would stop being useful, but it would remain ugly
forever.

> I don't think it's a big deal and you can
> always just symlink [the directories containing] them instead.

As can be seen in branch odd/multiarch, at first I tried to avoid
symlinks--thinking that explicit paths might be clearer, when
actually they created an awful lot of extra work and frustration.

> GC> (2) Host-prefixed subdirectories, like debian multiarch:
> GC>   /usr/lib/i386-linux-gnu/libxml2.so.2
> GC>   /usr/lib/x86_64-linux-gnu/libxml2.so.2
> GC> For msw builds, libxml2 installs binaries in two places:
> GC>   /opt/lmi/local/bin/libxml2-2.dll
> GC>   /opt/lmi/local/lib/libxml2.dll.a
> GC> and I could insert an autotools triplet before or after bin/ and lib/ ,
> GC> or I could append it to the string "local", thus:
> GC>   /opt/lmi/local-i686-w64/bin/libxml2-2.dll
> GC>   /opt/lmi/local-x86_64-w64/bin/libxml2-2.dll
> GC> (i.e., build libxml2 with 'prefix=/opt/lmi/local-x86_64-w64').

Not as appealing as (3)...

> GC> (3) A single host-prefixed directory for each architecture (and even
> GC> for each compiler). I suppose this is what I'd get by specifying
> GC> something like 'exec-prefix=/opt/lmi/i686-w64'. Then we'd have
> GC>   /opt/lmi/src [same for all]
> GC>   /opt/lmi/i686-w64/bin  [lmi's own binaries]
> GC>   /opt/lmi/i686-w64/local/bin/libxml2-2.dll
> GC>   /opt/lmi/i686-w64/local/lib/libxml2.dll.a
> GC>   /opt/lmi/x86_64-w64/bin [lmi's own binaries]
> GC>   /opt/lmi/x86_64-w64/local/bin/libxml2-2.dll
> GC>   /opt/lmi/x86_64-w64/local/bin/libxml2.dll.a
> GC> 
> GC> (1) doesn't seem like a good choice. I'm not sure whether there's
> GC> really much difference between (2) and (3), but (3) seems to maintain
> GC> a more obvious separation. What do you think?
> 
>   I agree that (3) is the most clear one. Whether you use uname or GNU host
> triplet is just a matter of convention, I guess the latter is more
> canonical.

I chose the GNU host triplet. We have to use it anyway to build
autotoolized libraries. Establishing a set of synonyms would add
confusion while saving only a few characters.