[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] Directory structure for multiple-architecture builds

From: Greg Chicares
Subject: [lmi] Directory structure for multiple-architecture builds
Date: Mon, 22 May 2017 21:29:49 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

Vadim--I'm hoping to build lmi and its dependencies simultaneously for
various hosts, all in the same chroot (running msw binaries via wine):
  - x86_64-linux-gnu (gtk)
  - x86_64-w64-mingw32
  - i686-w64-mingw32 (until we can convert users to x86_64)
and ultimately with clang as well as gcc, and I'm wondering what
directory structure to use. I imagine this is a problem you've already
solved; do you have a recommendation? I see (at least) three options:

(1) All binaries in one directory, with host-prefixed names, like gcc:
I've never seen this style for anything but cross compilers. I could do
this for lmi itself, but dependencies like libxml2 don't generally have
prefixed names, and I'm looking for a single uniform approach.

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

(3) A single host-prefixed directory for each architecture (and even
for each compiler). I suppose this is what I'd get by specifying
something like 'exec-prefix=/opt/lmi/i686-w64'. Then we'd have
  /opt/lmi/src [same for all]
  /opt/lmi/i686-w64/bin  [lmi's own binaries]
  /opt/lmi/x86_64-w64/bin [lmi's own binaries]

(1) doesn't seem like a good choice. I'm not sure whether there's
really much difference between (2) and (3), but (3) seems to maintain
a more obvious separation. What do you think?

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]