[Top][All Lists]

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


From: Jacob Meuser
Subject: Re: TODO
Date: Mon, 15 Nov 2004 20:33:55 -0800
User-agent: Mutt/1.4.2i

On Mon, Nov 15, 2004 at 07:36:21PM -0500, Daniel Reed wrote:
> On 2004-11-15T17:19-0600, Bob Friesenhahn wrote:
> ) system incrementally.  There is also the point that the libtool which
> ) comes with a Linux distribution has likely already been hacked to be
> ) more lenient.  If FSF libtool becomes more lenient by default, then
> ) there likely little actual impact.
> Just to address that last comment: Red Hat has shipped patch-free Autoconf
> since Red Hat Linux 8.0, patch-free Automake since Fedora Core 1, and will
> hopefully be shipping a patch-free Libtool in Fedora Core 4.

now perhaps, but in the past?  not everyone updates the autotools in
their packages as soon as possible.  besides, it is arguable that
libtool should be fairly well adapted to RedHat by default, the
1.5 branch has been around for a while now, and you are still
shipping patches?

now think about that in the context of a non-Linux system that
the autotools developers don't regularly use.

> We do not modify these tools to work more effectively on Linux at the
> expense of their support for other systems because, well, developers might
> end up using them! And shipping software based on them. And, if and when
> that software breaks, it would be the developer and/or the various
> lists that get to figure out why (we would have been long disconnected from
> the chain by that point). Time that could go into developing new features
> and fixing real bugs would be wasted, so we lose.

yes, that is how it should be, but history proves otherwise.

> (For that to make sense, keep in mind that, outside of the GNOME world, the
> autotools are used primarily at packaging time, not build time. Having a

huh?  how can autoconf, or automake, or libtool be used at packaging
time, and not build time?  and even if you could, why?

besides, the biggest problem (assuming that OS/distros understand the
reasons for not hacking autotools) is original distributors modifying
libtool parts that are distributed with their software.  look and
you will find changes to make libtool act like it does on linux
on other systems.  does RedHat scrutinize all the autotool stuff
in every SRPM and work to correct the issues?  why would it, the
changes don't affect RedHat.  I'm not trying to pick on RedHat
here, I wouldn't try to correct things that don't affect me either.


> Linux-optimized Libtool installed on a Linux machine is not likely to offer
> any benefit to people building software from source, just people who are
> packaging software to distribute.)
> We also do not modify these tools to work more effectively on Linux without
> affecting other systems because, well, such changes should be made upstream!
> This change should be made here! (Or not at all.)
> (Retooling all of the software we ship to take advantage of custom
> modifications to the build scripts really bogs down our build roots (and can
> waste developer time, causing us to lose again). We primarily do it (retool)
> now to take advantage of our multilib-aware Libtool.)
> -- 
> Daniel Reed <address@hidden>   
> The pursuit of pretty formulas and neat theorems can no doubt quickly
> degenerate into a silly vice, but so can the quest for austere
> generalities which are so very general indeed that they are incapable
> of application to any particular. -- Eric Temple Bell, Mathematician
> _______________________________________________
> Libtool mailing list
> address@hidden

reply via email to

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