On 3 Jul 2001, Karl Fogel wrote:
> Mo DeJong <email@example.com> writes:
> > What do folks think? This is both a technical and a political
> > question since every package that subversion depends on will
> > also need to be upgraded before we really see the benefits
> > of autoconf 2.50. I am willing to do much of the work, but
> > before the way comes the will.
> Can you first make Jon Trowbridge's patch (for libtool 1.4
> compatibility) work with autoconf 2.50? Currently we have to choose
> between being up-to-date with libtool vs up-to-date with autoconf. :-)
Ok, I have done that. I posted a patch to the apr dev list
that fixes apr so that it works with autoconf 2.50 and
libtool 1.4. I then built subversion (with the libtool
patch to remove the .libs hacks) and it worked just fine.
> By the way, I'd still like to know to know exactly what problems Jon
> Trowbridge was having with 2.50 before we start requiring it in
> Subversion. I got the impression from his mail that he didn't share
> your high opinion of 2.50, but don't know the specifics yet.
That seems to be an ongoing problem. People run something with
the new autoconf, it does not work, they don't bother to investigate,
then they tell other people that autoconf 2.50 has "issues".
Often, it is the project's incorrectly written macros that are
to blame. I had to track down a number of strange quoting
errors while upgrading another package. It was no fun, but
it was also not autoconf's fault.
> I don't think anyone feels a need to work with a wide range of
> versions of each tool. Working with the latest stable release of each
> tool is okay. But currently we have a conflict even there...
I don't see that there is any other option. Both autoconf 2.13
and libtool 1.3 have some serious bugs that are currently
worked around in the build system. These workarounds cause
other problems like static builds not working. By upgrading,
we are trading a known set of bugs for a unknown set of bugs.
My take on upgrading build components like this is, the
sooner the better. That gives people more time to build
on strango systems and report any problems they run into.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 21 14:36:33 2006