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

[Vadim Zeitlin]

On Mon, 1 Apr 2019 18:47:49 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-05-23 14:29, Vadim Zeitlin wrote:
GC> > On Mon, 22 May 2017 21:29:49 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> Vadim--I'm hoping to build lmi and its dependencies simultaneously for
GC> > GC> various hosts, all in the same chroot (running msw binaries via wine):
GC> > GC>   - x86_64-linux-gnu (gtk)
GC> > GC>   - x86_64-w64-mingw32
GC> > GC>   - i686-w64-mingw32 (until we can convert users to x86_64)
GC> > GC> and ultimately with clang as well as gcc, and I'm wondering what
GC> > GC> directory structure to use. I imagine this is a problem you've already
GC> > GC> solved; do you have a recommendation?
GC> > 
GC> >  To be brief, I use something similar to your (3): i.e. I put 
host-specific
GC> > stuff in a directory called ${uname}-${uname -m}
GC> 
GC> Now I've done something like that, on this new branch:
GC>   http://git.savannah.nongnu.org/cgit/lmi.git/commit/?h=odd/multiarch
GC> and I'd be very glad if you would tell me what you think of it.

 I did have a look at it, but I don't really have much to say about it:
IMHO as long as the build system works and is not too complex, it's fine,
and from this point of view these changes definitely pass (I'm judging
only the added complexity here, and it's really not that bad).

 To address some comments/questions in the diff above:

- Personally I think it's better to avoid using deferred evaluation for
  make variables, so I'd definitely prefer defining build_directory later,
  but using ":=" for it.

- I actually don't remember why had I written that I preferred using
  symlinks before, but now I have serious doubts about this. As long as
  we have this PERFORM variable anyhow, what prevents us from determining
  the right PATH/WINEPATH combination once and putting it inside this
  variable? It looks like this ought to make everything work and we
  wouldn't need to update the symlinks. In particular, I'd really like to
  have both 32- and 64-bit versions on the same machine in parallel, which
  is not really compatible with needing /opt/lmi/bin symlink to point to
  just one of them.

- To determine build_type we could use our own simplified logic based on
  uname, which could presumably be much simpler than the same logic, but
  implemented for all known (or used to be known 30 years ago) versions of
  Unix, in config.guess. But I don't think there is any magic way to just
  get this triplet from anywhere, config.guess is the de facto canonical
  source for it.

- I'm not aware of any currently used Bourne-compatible shells where
  "export VAR=value" doesn't work. It doesn't mean they don't exist, of
  course, but IMO chances of building lmi using one of them are negligible.

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

 Perhaps it's just that I'm lacking the depth to fully appreciate it. But
whatever it may be, I definitely prefer the book to the film. Of course,
this is true for any book/film pair and not just this one for me, so it's a
bit tautological to restate it for this particular example.

GC> IOW, perhaps I would have gotten a message like
GC>   i686-whatever-lmi.exe cannot find i686-whatever-xml2.dll
GC> instead of
GC>   whatever-lmi cannot find xml2.dll
GC> when there's obviously an xml2.dll on $PATH, or on $WINEPATH, or
GC> even in one directory reachable through $PATH and another reachable
GC> through $WINEPATH.

 I sympathize as I, of course, have made the same blunder too in the past
(and more times than I care to admit). But IME it's actually easier to
debug this with Wine than with native MSW, as its debug messages clearly
indicate the problem. So in some sense you were lucky.

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

 FWIW I agree that it's a better choice. I use whatever I use just because
I had never really thought before starting to do it. If I had, I would have
chosen to use GNU triplets as well.

 Regards,
VZ