On 06 Jul 2001 12:25:27 -0700, Mo DeJong wrote:
> 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.
Well, I don't really know if autoconf can refuse *all* of the blame
here. The topic of switching to autoconf 2.50 has come up a few times
over at the GNOME project, but the problem is that it breaks pretty much
*ALL* of our builds. If not every single one, it is the vast majority
of them. Fixing them all will be a *big* job, particularly since
autoconf doesn't provide a "migrating from 2.13 to 2.50" doc.[1]
I can understand why the autoconf people would want to get rid of the
need for crufty hacks, but I can't understand why the autoconf 2.50
release announcement didn't say, in big letters, "Autoconf 2.50 will, in
all probability, break your builds. To fix it, do X, Y and Z".
The autotools have a (IMO pretty much deserved) opinion for being
obscure... I personally like 'em a great deal, but there is no denying
that in the past it has taken a lot of black magic to get certain things
to work properly. And I'm all for sets to reduce the amount of black
magic... but breaking 90% of the builds[2] out there is not a recipe for
rapid acceptance of the new version.
-JT
[1] To the best of my knowledge, that is.
[2] 90% is an estimate. However, of the four or five things
that I've tried to build w/ autoconf 2.50, *none* have worked.
So I think that it is a generous estimate. :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:33 2006