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

[Greg Chicares]

On 2019-09-23 18:06, Vadim Zeitlin wrote:
> On Mon, 23 Sep 2019 17:40:21 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> On our redhat server, installing libtool places config.guess
> GC> in a different location that on my debian box. Everywhere
> GC>   /usr/share/libtool/build-aux/whatever
> GC> is mentioned in lmi's build system, redhat uses
> GC>   /usr/share/libtool/config/whatever
> GC> instead.
> 
>  Note that this is not the only possible location of this file, e.g.
> this thread[*] lists all of the following locations:
> 
>       /usr/lib/rpm/redhat/config.guess
>       /usr/share/libtool/config/config.guess
>       /usr/lib/rpm/config.guess
>       /usr/share/dejagnu/libexec/config.guess
>       /usr/share/automake-1.13/config.guess
> 
> So it looks like the closest equivalent to the Debian path would be
> 
>       /usr/share/libtool/config/config.guess
> 
> but it almost certainly doesn't matter which one do you use anyhow.

I did this manual replacement on the redhat server:

- /usr/share/libtool/build-aux/config.guess
+ /usr/share/libtool/config/config.guess

but my build logs show that I didn't succeed in replacing every
occurrence. A much more reliable workaround would be to copy or
link the file from its redhat location to its debian location;
I think I'll do that in future.

> GC> For now at least, I've just modified it by hand on the redhat box.
> 
>  I think the only better solution is to use "automake --add-missing" to
> actually copy the files that it uses to lmi directory. This could be done
> by running (the already existing, although not really necessary, because
> autoreconf does the same thing anyhow) autogen.sh script. The main drawback
> of doing it is that you need to have auto{conf,make} and libtool installed.
> But it's not really such an onerous requirement for any Linux system.

Well...I tried that, but I didn't much like the result--it
wrote other files that I don't want--so I deleted them and
committed it...on a branch, because I wasn't happy with
this approach in general. Here's why:

/opt/lmi/src/lmi[0]$grep -rl 'build-aux.*config.guess' * |wc -l
11

Some of those occurrences are in scripts that would usually
be run in the lmi source directory, but not all. Replacing
  /usr/share/libtool/build-aux/config.guess
with a hardcoded
  /opt/lmi/src/lmi/config.guess
just makes it harder to make '/opt/lmi/' reconfigurable.

(And when I committed that on a branch, I saw a surprising
file mode:

  [odd/guess_config 3475525a] Import 'config.guess'
   2 files changed, 89 insertions(+), 75 deletions(-)
   create mode 120000 config.guess

so what I committed was actually:

  /opt/lmi/src/lmi[0]$ls -l config.guess
  lrwxrwxrwx 1 greg greg 37 Sep 24 13:35 config.guess -> 
/usr/share/automake-1.16/config.guess

and I'll be interested to examine that after I push it, to
see exactly what's in the git repository--I guess it'll be
a dangling symlink on a system that doesn't have
  /usr/share/automake-1.16/config.guess
Yes--there it is:

  https://git.savannah.nongnu.org/cgit/lmi.git/commit/?h=odd/guess_config
diff --git a/config.guess b/config.guess
new file mode 120000
index 0000000..7c53173
--- /dev/null
+++ b/config.guess
@@ -0,0 +1 @@
+/usr/share/automake-1.16/config.guess
\ No newline at end of file

so I'm really glad it's just a throwaway branch.

> [*] 
> https://lists.fedoraproject.org/archives/list/address@hidden/thread/FLPQOSAGBR73HLE36TNF25IALH6VDQWE/

Fascinating. I kind of understand the POV that every project
should be completely autotoolized, and then no problem exists.
But OTOH we used to use a combination of parsing `uname`
output and testing the GNU triplet, yet it's not satisfactory
to get the same information in different ways, so I replaced
'uname' with 'config.guess' almost everywhere.

The problem is that
  $ uname
works probably everywhere, but
  $ config.guess
doesn't. I had hoped that
  $ /debian/path/to/config.guess
would work on any system that has autotools installed, but
such is not the case.

I'm tempted to install the latest gnu.org version (using the
'wget' command here:
  https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html
, which fetches a newer version than `automake --add-missing`
gave) into /etc/opt/lmi/ , but that doesn't seem to be worth
the bother.