libtool-patches
[Top][All Lists]
Advanced

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

Re: HEAD: workaround for released autotools


From: Ralf Wildenhues
Subject: Re: HEAD: workaround for released autotools
Date: Mon, 29 Aug 2005 08:25:19 +0200
User-agent: Mutt/1.4.1i

Hi Gary,

* 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.

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

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

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

> >Have you tested with CVS version of one, and released of the other?
> 
> No, but libobj.test can only succeed when everything required to build
> subdir libobjs correctly works, so there is no need... it is
> functionally equivalent of unpatched 1.9.6/2.59.

OK.

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


> Besides, if $TMPDIR is full, the user has bigger problems
> that not  being to install libtool!!

Oh, lots of software installs work just fine without TMPDIR.  But OK.

> >It'd been easier to leverage AS_VERSION_COMPARE, but that wouldn't  
> >have > >worked on Solaris till last week, either.
> 
> And it can't detect patched tools, such as the ones I'm using at the  
> moment.

ACK.

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

Cheers,
Ralf




reply via email to

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