bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposed patch for bootstrap


From: Gary V. Vaughan
Subject: Re: proposed patch for bootstrap
Date: Wed, 6 Apr 2011 23:50:38 +0700
User-agent: Mutt/1.5.20 (2009-06-14)

Howdy Bruce!

On Wed, Apr 06, 2011 at 08:41:43AM -0700, Bruce Korb wrote:
> On 04/05/11 21:06, Gary V. Vaughan wrote:
> >AFAICT, very little (if anything) remains to be done short of actually
> >commiting it to the repository. I did stall on the horrid slurp function
> >shared among a few projects with slight divergences, but that is an
> >issue for bootstrap.conf files (if they haven't been sanitized already).
> 
> I'd suggest a couple of tweaks:
> 
> 1.  gnulib_non_module_files ought to be dependent upon not being set
>     by bootstrap.conf (as is the case), but also $build_aux.
>     if configure.ac or bootstrap.conf changes it, this variable will
>     not be correct.

Could you explain that in a bit more detail, I don't yet understand what
you mean.

> 2.  Perhaps just my preference, but the embedded README/usage/help
>     text feels like too much clutter that belongs in associated
>     doc files rather than filling the first several hundred lines
>     of the script.  :)

Oh, absolutely... that was never meant to live in the file, but to be
moved into gnulib/doc when adopted into upstream.  But to make sure
the README and the script itself didn't get separated or mismatched
during development, I just parked it inside the script until it finds
a better home.  Either way, I think this is much better documented
and carefully designed than the, ahem, organically grown incumbent
gnulib bootstrap script.  All IMHO of course, and I'm somewhat biased :)
 
> Clearly a well designed script.  I vote for sanity checking the thing
> and then plugging it in.  :)  Thanks, Gary.

Thanks for the vote of confidence Bruce... it would surely be nice to
see someone get some mileage out of the suprising amount of time it
took me to write the thing!  Especially the generalisation of neat
stuff like this (many of these are automatically intuited from macro
invocations in configure.ac and aclocal.m4 and dependencies):

Moloch:~ gary$ cd Devo/coreutils--master--0
Moloch:coreutils--master--0 gary$ ./bootstrap
bootstrap: `./bootstrap' differs from `./gnulib/build-aux/bootstrap',
bootstrap: please consider adopting the canonical version from gnulib.
bootstrap: Error: `xz' not found
bootstrap: Error: `autoconf' version == 2.61 is too old
bootstrap:        `autoconf' version >= 2.62 is required
bootstrap: Error: `automake' version == 1.10 is too old
bootstrap:        `automake' version >= 1.11.1 is required
bootstrap: Error: `gettext' not found
bootstrap: Error: README-prereq explains how to obtain these bootstrap programs:
bootstrap:        Program    Min_version Homepage                            
bootstrap:        -----------------------------------------------------------
bootstrap:        bison      -           http://www.gnu.org/software/bison   
bootstrap:        git        1.4.4       http://git-scm.com                  
bootstrap:        gperf      -           http://www.gnu.org/software/gperf   
bootstrap:        makeinfo   -           http://www.gnu.org/software/texinfo 
bootstrap:        perl       5.5         http://perl.com                     
bootstrap:        rsync      -           http://www.samba.org/rsync          
bootstrap:        tar        -           http://www.gnu.org/software/tar     
bootstrap:        xz         -           http://tukaani.org/xz               
bootstrap:        autoconf   2.62        http://www.gnu.org/software/autoconf
bootstrap:        automake   1.11.1      http://www.gnu.org/software/automake
bootstrap:        gettext    0.18        http://www.gnu.org/software/gettext 
bootstrap:        -----------------------------------------------------------

And I'm convinced that I invented a much better method for bootstrap
level tools to parse m4 for interesting macro values than feeding all
that m4 code to sed, and crossing your fingers:  My method uses m4 to
parse the m4, and is thus robust to m4 expansions anywhere at all in
the file, including things like using m4_esyscmd to call git-version-
gen... as long as m4 would get the right values when autoconf
compiles configure.ac into configure, so this method will pick up the
correct argument values during tracing for use in the bootstrap script.
See the body of func_extract_trace for the right way to do this - IIRC
I discussed with Ralf and Bruno briefly at the time I was writing it,
but I can't find the threads right now.  I'd like to port it to
libtoolize too... only I became tired of the ongoing battle to get any
of my patches accepted into the tree of late, so I'll need a lot more
energy before I try to climb that particular mountain next time. ;)
development again.

Anyway, I'm rambling... If there are any non-time-sucking things I can
do to help shepherd this patch into gnulib, I would be very happy to
see it adopted, to encourage its use in gnulib client projects, and to
help maintain it.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Attachment: pgp3si6H0wqkW.pgp
Description: PGP signature


reply via email to

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