Re: HEAD: workaround for released autotools

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Mon, Aug 29, 2005 at 12:29:29PM CEST:
> 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:

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

I tend to prefer the faster solution at times..

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

Nono, that's still not what I mean.  The line in m4general.m4sh is fine.
You call plain
  ./configure
but I have setups where that does not work.

To be pedantic: the GNU build system is just not designed to build
out-of-the-box everywhere.  The goal is to provide a consistent user
interface.  So, if I want to build 100 packages, all I may have to do
on machine X is
  ./configure CFLAGS=-foo && make && su -c "make install"
and on machine Y it is
  ./configure CFLAGS=-bar && make && su -c "make install"

But you can't expect plain "configure" without options to work.
And I test on real-world systems where this is true.

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

My point is: your patch requires maintenance *as well*.
So nothing is gained.

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

See above.

> >| +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"

Yep.

> >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 :-(

Well, there's also another good rule: if it works, don't change it.
So no, I would not vote for changing our source tree layout again
after 2.0.

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

That would be fine with me.  Or a commandline switch for `bootstrap',
FWIW.

Cheers,
Ralf