lmi
[Top][All Lists]
Advanced

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

Re: [lmi] An initial step toward using 'config.guess' more generally


From: Vadim Zeitlin
Subject: Re: [lmi] An initial step toward using 'config.guess' more generally
Date: Fri, 27 Sep 2019 12:30:17 +0200

On Fri, 27 Sep 2019 01:24:09 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2019-09-25 00:55, Vadim Zeitlin wrote:
[...using config.guess...]
GC> >  The idea would be to use relative path to the script, if we included it
GC> > in lmi itself.
GC> 
GC> That feels wrong for
GC>   tools/pete-2.1.1/Makefile
GC> especially. As it stands today, I believe that's independent
GC> of lmi,

 Even if it's true, and I'm not certain about that, is this important?

GC> so that I could copy it to another project if I
GC> wanted to, and it would just work, as long as this line:
GC>   $(shell /usr/share/libtool/build-aux/config.guess)
GC> actually finds the system-default 'config.guess'.

 I don't see anything wrong with customizing an external dependency to
better fit the project it's being integrated into. If you wanted to use
PETE in another project, you'd take its upstream sources (which,
admittedly, are a bit difficult to find for the project which seems to be
dead since ~15 years) and not the customized lmi version.

 BTW, this is another reason I like using Git submodules for external
libraries: they allow to cleanly separate the upstream version from the
(possibly) customized one used by the project.

GC> I really want 'config.guess' to be immediately available everywhere,
GC> just like 'uname'.

 I understand the appeal of this, but in practice there will be multiple
copies of this script on any Linux system and using the fixed version in
lmi itself just seems more reliable than (more or less randomly) choosing
one of the system versions.

 Regards,
VZ

Attachment: pgpfrtkVM2oyO.pgp
Description: PGP signature


reply via email to

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