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: 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



reply via email to

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