[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] An initial step toward using 'config.guess' more generally
From: |
Greg Chicares |
Subject: |
Re: [lmi] An initial step toward using 'config.guess' more generally |
Date: |
Fri, 27 Sep 2019 01:24:09 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
On 2019-09-25 00:55, Vadim Zeitlin wrote:
> On Wed, 25 Sep 2019 00:13:13 +0000 Greg Chicares <address@hidden> wrote:
>
> GC> On 2019-09-23 18:06, Vadim Zeitlin wrote:
>
> [...the problem of getting config.guess...]
>
> GC> > I think the only better solution is to use "automake --add-missing" to
> GC> > actually copy the files that it uses to lmi directory. This could be
> done
> GC> > by running (the already existing, although not really necessary, because
> GC> > autoreconf does the same thing anyhow) autogen.sh script. The main
> drawback
> GC> > of doing it is that you need to have auto{conf,make} and libtool
> installed.
> GC> > But it's not really such an onerous requirement for any Linux system.
> GC>
> GC> Well...I tried that, but
[...]
> GC> I wasn't
> GC> happy with this approach in general. Here's why:
> GC>
> GC> /opt/lmi/src/lmi[0]$grep -rl 'build-aux.*config.guess' * |wc -l
> GC> 11
> GC>
> GC> Some of those occurrences are in scripts that would usually
> GC> be run in the lmi source directory, but not all. Replacing
> GC> /usr/share/libtool/build-aux/config.guess
> GC> with a hardcoded
> GC> /opt/lmi/src/lmi/config.guess
> GC> just makes it harder to make '/opt/lmi/' reconfigurable.
>
> The idea would be to use relative path to the script, if we included it
> in lmi itself.
That feels wrong for
tools/pete-2.1.1/Makefile
especially. As it stands today, I believe that's independent
of lmi, so that I could copy it to another project if I
wanted to, and it would just work, as long as this line:
$(shell /usr/share/libtool/build-aux/config.guess)
actually finds the system-default 'config.guess'.
Of course, that's not the case in a redhat userland, so
it's already broken. But replacing it with
$(shell ../config.guess)
is just broken in a different way.
We could revert this change:
git show aea8ef13fb2 tools/pete-2.1.1/Makefile
which would restore portability, but then we'd be back to
parsing 'uname' output--which is what I wanted to avoid.
> GC> The problem is that
> GC> $ uname
> GC> works probably everywhere, but
> GC> $ config.guess
> GC> doesn't. I had hoped that
> GC> $ /debian/path/to/config.guess
> GC> would work on any system that has autotools installed, but
> GC> such is not the case.
>
> Again, if you include the script in lmi repository, you could rely on
>
> $ ./some-subdirectory/config.guess
>
> to work (where "some-subdirectory" could be "build-aux" or
> "third_party/aux" or whatever else).
I really want 'config.guess' to be immediately available everywhere,
just like 'uname'. That idea doesn't appeal to the maintainers, but
I can force it to work by downloading it from gnu.org into some
reasonable directory. I had considered:
/etc/opt/lmi/config.guess
but as long as I have su privileges throughout my personal universe
I can just use:
/usr/share/libtool/build-aux/config.guess