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.714sYeah, 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 sysBloat 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 toget 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 structureof branch-1-5.
ACK.
Maybe a good software organization rule for new projectswould be: don't split up the directory unless "ls" output doesn't fit inthe 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 offlexibility 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},[EMAIL PROTECTED]
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