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

[Vadim Zeitlin]

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} 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))).


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. I don't think it's a big deal and you can
always just symlink [the directories containing] them instead.

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').
GC> 
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.

GC> Whatever choice we make, it might make a lot of sense to use an empty
GC> string for the triplet distributed to end users, so that Kim can just
GC> build a single production version as usual.

 I've just realized that I don't actually know how is the end user
distribution created. Does it use the same structure with "bin"
subdirectory? This would be somewhat unusual (although not exactly unique)
for a MSW application...

 Regards,
VZ