Re: HEAD: workaround for released autotools

[Gary V. Vaughan]

Hallo Ralf,

On 29 Aug 2005, at 07:25, Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Sun, Aug 28, 2005 at 10:56:24PM CEST:
> > On 28 Aug 2005, at 20:26, Ralf Wildenhues wrote:
> > > Why, oh why wait another minute for bootstrap to finish?  It's not
> > > like this would be the first work-around for limitations in Automake
> > > 2.59.  Besides, your patch adds about as much size to tarball as the
> > > duplicate files do.
> >
> > minute?
> >
> > $ time ./tests/libobj.test -q
> > real    0m12.573s
> > user    0m4.923s
> > sys     0m4.714s
>
> Yeah, on a fast system.

Moderate, 1GHz iBook.  But point taken.

> > vs. a reconf of just $top_srcdir when nothing needs rebuilding:
> >
> > $ reconfdirs=. time ./bootstrap
> *snip*
>
> >       149.91 real       116.73 user        23.87 sys
>
> Bloat is OK if there is other bloat?

I prefer programmatic solutions to mandraulic is all... why do the  
calculation
yourself when you have a computer right in front of you?

> > > Hmm.  I know more than one system where a plain "configure" without
> > > options will not lead to a working compiler configuration.  No, not
> > > everyone has config.site's employed.  I for one don't.
> >
> > Are you referring to the CONFIGSITE setting from m4general.m4sh?
>
> No.  I refer to a site where I have to add CFLAGS=-xarch=v9 in  
> order to
> get working code.  Or where cross-compilation is the default, and
> execution of built programs will fail.

Oh I see.  Okay.  But m4general.m4sh messes with CONFIGSITE too...  
that's where
I copied that line from.

> > By self-correcting, I mean that the code in my patch needs no more
> > maintenance... it just stops shipping extra copies of libobj sources
> > as soon as people start bootstrapping with new enough autotools.
>
> And I'm trying to tell you that it's not true, and that making it true
> is *not* worth the additional effort.

I realise that it is not *completely* true.  But I still think it is  
considerably
less effort to fire and forget with this patch, than have a long  
drawn out discussion
about how to get rid of the duplicated files next year, while still  
keeping some
kind of backwards compatibility.

Don't forget that the new test is only for the benefit of people who  
are bootstrapping
libtool, it has no bearing on anything else.  It gives the  
bootstrapper the option of
building a tidier tarball (without extra sources in $top_srcdir) if  
they are running
new enough autotools... they don't have to fiddle with Makefile.am or  
mess with the
bootstrap script, it "just works".

> > > And you scribble around in the source tree should ${TMPDIR-/tmp} be
> > > full.
> >
> > I don't see it (apart from bootstrap itself creating the libobj.test
> > script).
>
> (taken from your first patch version)
>
> | +testdir="${TMPDIR-/tmp}/${1-libobj}-${RANDOM-0}$$"
> | +umask 0077
> *snip*
>
> | +${MKDIR} $testdir
> fails
>
> | +cd $testdir
> fails
>
> | +${MKDIR} src
> scribbles in source tree.  The "set -e" happens only later.

Okay.  Now that it uses autom4te, we can replace that with:

func_mkdir_p "$testdir/src" || func_fatal_error "Cannot create  
$testdir/src"

> > > Honestly, I think this is bloat.  All 2.59/1.9.6-induced workarounds
> > > are trivially found by a single grep.
> >
> > At the moment, yes.  But this is scalable incase we want to support
> > other suboptimal (future) releases of bootstrap utilities, and it
> > minimises  future maintenance -- once this is in (and debugged ;-)),
> > we can just  forget about it, until we need a model for doing
> > something similar in the future.
>
> We need a model to not rely so much on fancy new features, IMNSHO.
> Libtool "maintenance" takes up a relatively enormous amount of time,
> a lot of which would have been saved had we kept the directory  
> structure
> of branch-1-5.

ACK.

> Maybe a good software organization rule for new projects
> would be: don't split up the directory unless "ls" output doesn't  
> fit in
> the terminal scroll buffer (mutt is really good at this, for example).
> My opinion.


Might be good to come up with something, though we need to have a bit of
flexibility where the benefits outweigh the negatives.  The current  
source
tree reorganisation was because we were trying to speed up build  
times by
moving to a single toplevel Makefile... pity we tripped over some  
bugs in
automake/autoconf in so doing :-(

If you really hate this patch, then we can apply yours instead.  I'd  
still
like some method of being able to make the 2.0 release without the  
duplicate
files if we have the necessary autotool patches in place at bootstrap  
time
though.  Maybe an environment variable?

Cheers,
    Gary.
--
Gary V. Vaughan      ())_.  gary@ 
{lilith.warpmail.net,gnu.org},address@hidden
Research Scientist   ( '/   http://www.tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/{libtool,m4}
Technical Author   `(_~)_   http://sources.redhat.com/autobook

PGP.sig
Description: This is a digitally signed message part