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

[Vadim Zeitlin]

On Fri, 5 Apr 2019 23:11:57 +0000 Greg Chicares <address@hidden> wrote:

GC> Vadim--With the goal of making lmi's build system more robust, I propose
GC> the following patch, which sets '--build' according to 'config.guess'
GC> for {libxml2, libxslt, liblzma}, as we already do for {wx, wxpdfdoc}.
GC> I've tested it, and it seems to work fine, but I have some questions:
GC> 
GC> (0) I was going to ask whether it's even necessary to specify '--build'
GC> these days, but the current advice, even in 2019, is apparently that
GC> '--build' must be specified whenever '--host' is specified[0].

 I'm aware of this advice, but I've been ignoring it for years without any
ill effects. Autoconf manual seems to contradict itself several times on
the linked page, so all I can say is that using --host=i686-w64-mingw32
does _not_ set build to the same value in practice, e.g. here is an extract
from config.log for configure invocation using the --host option only:

        configure:3114: checking build system type
        configure:3128: result: x86_64-unknown-linux-gnu
        configure:3148: checking host system type
        configure:3161: result: i686-w64-mingw32

and I also have

        build='x86_64-unknown-linux-gnu'
        build_alias=''
        host='i686-w64-mingw32'
        host_alias='i686-w64-mingw32'

in config.status for this build.

 So I'm pretty sure that omitting --build=x86_64-unknown-linux-gnu is
perfectly harmless, although so is specifying too, I guess.


GC> (1) Is the order of './configure' options significant?

 No, unless the same option is repeated multiple times, in which case it's
later value overrides the previous one.

GC> (2) liblzma's 'config.guess' is in a build-aux/ subdirectory, and it
GC> seemed weird to hard-code that...but that's where the wxPdfDoc install
GC> script has it, and the autoconf manual suggests that's the canonical
GC> location...so I guess that's perfectly okay.

 It's indeed a rather weird name, but it does seem to be, if not canonical,
than at least (one of?) the most widespread. FWIW I used admin/build-aux
for these files in wxPdfDocument because I really didn't want to introduce
a new top-level directory just for them (and "admin" already existed).

 In any case, whatever it is, you do need to either hardcode it (which is
fine IMO) or use m4 to process configure.ac and extract AC_CONFIG_AUX_DIR()
argument from it (which doesn't seem to be worth it).


GC> It looks like I added the former $(build_type) in commit cc4a6e45ce,
GC> modeling it on the wx installation procedure. It seemed weird that
GC> 'x86_64-unknown-linux-gnu' was hard-coded when an updated 'config.guess'
GC> reports 'x86_64-pc-linux-gnu' instead for my machine;

 Yes, looking at "git blame", this was changed back in 2015:

http://git.savannah.gnu.org/cgit/config.git/commit/?id=ca9bfb8cc75a2be1819d89c664a867785c96c9ba

without any real explanation. My guess would be that it was done for
consistency with i?86 architectures, for which it has been apparently
always called like this (at least I see RMS commit calling it like this
already back from 1997).

 In any case, I don't think this makes any difference in practice, but
then, to be honest, I have no idea what is the vendor field ever used for
and IME it just isn't.

 Regards,
VZ