On Fri, Nov 26, 2004 at 08:05:53AM +0100, Andr Malo wrote: > oops. (Who the hell named that tool aclocal?!)
It was probably named that way to promote confusion. Sane people would have called it amlocal instead. *shrug* > > No, it's not. I purposely don't install automake. > > I'd be really interested in the reasons. automake corrupts the build process by forcing us to give up control without solving any fundamental problems and introduce a lot of needless complexity and bugs into the build system. I wouldn't let any project that I hate use it. It's awful. Greg and I and others have posted to [EMAIL PROTECTED] in the past as to the problems introduced by automake. One of the many concerns is that it has logic to sporadically invoke autoconf and configure from the build process, which really can put a dent in one's life. Following capricious rules that are rather illogical can reduce the chance of that happening (but not eliminate), but it's easy to fall into the trap. It'd add no value and would probably make our lives hell. GNU autoconf and libtool add some value, but every once in a while, I'd like to toss those out, too. (In a way, I already did so for GNU libtool...see APR's --enable-experimental-libtool.) > > -1 as we can't (won't) make httpd depend on automake. > > Just to be fair, we would make developers depend on automake, not httpd. There are very, very, very few things that cause me to say '-1' off the bat. automake just happens to be one of them. > > Please find some other way to address this problem. -- justin > > I'd guess, something like apr-util/xml/expat/buildconf.sh does? As you refuse > to install aclocal, it could be your favorite task >:-> If we import a new PCRE tree and we need to tweak their build system, then we can do that. But, introducing a dependency on automake isn't an acceptable solution. -- justin
