[Top][All Lists]
[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 13:53:06 +0200 |
User-agent: |
Mutt/1.4.1i |
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
- HEAD: workaround for released autotools, Ralf Wildenhues, 2005/08/27
- Re: HEAD: workaround for released autotools, Gary V. Vaughan, 2005/08/28
- Re: HEAD: workaround for released autotools, Ralf Wildenhues, 2005/08/28
- Re: HEAD: workaround for released autotools, Gary V. Vaughan, 2005/08/28
- Re: HEAD: workaround for released autotools, Ralf Wildenhues, 2005/08/29
- Re: HEAD: workaround for released autotools, Gary V. Vaughan, 2005/08/29
- Re: HEAD: workaround for released autotools,
Ralf Wildenhues <=
- Re: HEAD: workaround for released autotools, Gary V. Vaughan, 2005/08/29
- Re: HEAD: workaround for released autotools, Ralf Wildenhues, 2005/08/29
- Re: HEAD: workaround for released autotools, Gary V. Vaughan, 2005/08/29
- FYI: HEAD: workaround for released autotools, Ralf Wildenhues, 2005/08/29
- Re: FYI: HEAD: workaround for released autotools, Gary V. Vaughan, 2005/08/29