Re: [PATCH] scripts: add autotools-install, for those stuck with outdated tools

[Jim Meyering]

Stefano Lattarini wrote:
> On 08/31/2012 10:58 AM, Jim Meyering wrote:
>> FYI, this adds the autotools-install script, formerly at:
>>
>>     http://people.redhat.com/meyering/autotools-install
>>
>> As the commit log says, it is a:
>>
>>     New script, so you can always build
>>     from git-cloned sources, even when they require bleeding edge
>>     m4, autoconf, automake, etc.
>>
>>
>> From c1495a1107871f451fd680d5c23b2c71af6e9971 Mon Sep 17 00:00:00 2001
>> From: Jim Meyering <address@hidden>
>> Date: Fri, 31 Aug 2012 10:55:03 +0200
>> Subject: [PATCH] scripts: add autotools-install, for those stuck with
>>  outdated tools
>>
>> * scripts/autotools-install: New script, so you can always build
>> from git-cloned sources, even when they require bleeding edge
>> m4, autoconf, automake, etc.
>> ---
>>  scripts/autotools-install | 206 
>> ++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 206 insertions(+)
>>  create mode 100755 scripts/autotools-install
>>
>> diff --git a/scripts/autotools-install b/scripts/autotools-install
>> new file mode 100755
>> index 0000000..20d02ae
>> --- /dev/null
>> +++ b/scripts/autotools-install
>> @@ -0,0 +1,206 @@

Thanks for all of the feedback.
I've gone ahead and committed it as-is, hoping
that you'll be willing to write the patch.
If not, no problem... I will.

>> +# Building coreutils from a git-cloned directory may require versions of
>> +# tools like autoconf, automake, gettext, etc. that are newer than the ones
>> +# provided by the distribution on which you want to build.  In that case,
>> +# you can use this script to bootstrap the "autotools" tool chain, starting
>> +# with m4 (prereq of autoconf), then autoconf, which a prereq of automake,
>>
> "which is a prereq of automake"

Good catch.  Thanks.

...
>> +
>> +  # Download the each tar-ball along with its signature, if there is one.
>> +  pkgs=
>> +  for t in $(echo $tarballs); do
>>
> Since the rest of the script seems to suggest you want to remain portable
> to non-POSIX Bourne shells (like Solaris 10 /bin/sh): you should use `...`
> nor $(...), for command substitution.
>
>> +    base=$(basename $t)
>>
> Ditto.
>
>> +    pkgs="$pkgs $base"
>> +    test -f $base     || $WGET_COMMAND $t
...
>> +# Don't run as root.
>> +# Make sure id -u succeeds.
>> +my_uid=`id -u`
>> +test $? = 0 || {
>> +  echo "$0: cannot run \`id -u'" 1>&2
>> +  (exit 1); exit 1
>> +}
>>
> Simply use "die" instead?  Also, the GCS now suggest quoting 'like this',
> not `like this'.

Definitely yes.  On both counts.
I suspect I added the die definition later and didn't
go back and find all places where it could then be used.

> Oh, and since you are running with 'set -e', you wan to protect possible
> failures in command substitution:
>
>     my_uid=`id -u` && test -n "$my_id" || die "'id -u' failed"
>
> Otherwise you might get bitten by this behaviour:
>
>     $ bash -e -c 'x=`false`; echo OK'; echo $?
>     1

Good catch.

...
>> +pkgs=$(get_sources)
>> +
> `...`, not $(...)

I'm inclined to push back, here, and leave it as $(...).
If we get problem reports, I'd be tempted to say "use bash",
or at worst, add code to reexec with a better shell.

>> +export PATH=$prefix/bin:$PATH
>> +for pkg in $pkgs; do
>> +  echo building/installing $pkg...
>> +  dir=$(basename $pkg .tar.gz)
>>
> Ditto.
>
>> +  rm -rf dir
>>
> s/dir/$dir/

Oh!  Good one.

>> +  gzip -dc $pkg|tar xf -
>> +  cd $dir
>> +  ./configure CFLAGS=-O2 LDFLAGS=-s --prefix=$prefix    > makerr-config  
>> 2>&1
>> +  make                                                  > makerr-build   
>> 2>&1
>>
> Why this "creative formatting"?  Seems more confusing than useful, at least
> for me.  More instances below.

Fine by me to nuke it.

>> +  if test "$make_check" = yes; then
>> +    case $pkg in
>> +      automake*) expected_duration_minutes=40;;
>> +      autoconf*) expected_duration_minutes=15;;
>> +      libtool*) expected_duration_minutes=3;;
>>
> The libtool testsuite is truly so quick?  I seem to recall differently ....

I suspect that my numbers all come from back long ago,
(7-8 years ago) when I was using a single-core AMD64-based system.
I'll bet that back then the test suite was not as thorough.

>> +      *);;
>> +    esac
>> +    test -n "$expected_duration_minutes" \
>> +      && echo "running 'make check' for $pkg; NB: this can take over" \
>> +              "$expected_duration_minutes minutes"
>> +    make check                                      > makerr-check   2>&1
>> +  fi
>> +  make install                                      > makerr-install 2>&1
>> +  echo done at $(date +%Y-%m-%d.%T)
>>
> `...`, not $(...)
>
>> +  cd ..
>> +done
>> +
>> +# Without checks (and with existing tarballs), it takes just one minute.
>> +# Including all checks, it takes nearly an hour on an AMD64/3400+
>> +
>> +case $PKG_CONFIG_PATH in
>> +  $prefix/lib/pkgconfig:/usr/lib/pkgconfig)
>> +    echo 'Good! your PKG_CONFIG_PATH envvar is already set';;
>> +  *) cat <<EOF;;
>> +**************************************************************************
>> +Be sure that PKG_CONFIG_PATH is set in your environment, e.g.,
>> +PKG_CONFIG_PATH=$prefix/lib/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig
>>
> inconsistency with the value checked above (that lacked 
> "/usr/share/pkgconfig").

A patch would be most welcome.