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

Re: an update to automake-1.11?



Kevin Kofler writes:

Sam Varshavchik wrote:
Just because you can't read it, it's not gibberish.

It's not that *I* can't read it, it's that it is just plain hard to read, especially because it contains workarounds for bazillions of broken proprietary *nix shells (trying to use Bourne-style shell code as a portable language is a major design failure of its own, there are tons of subtly different dialects and megatons of plain bugs).

Try reading that 1.1 MB (!) shell script:
http://svn.calcforge.org/viewvc/emu-
tigcc/trunk/configure?revision=2861&root=emu-tigcc

It's generated from a 9.7 KB configure.ac:
http://svn.calcforge.org/viewvc/emu-
tigcc/trunk/configure.ac?revision=2847&root=emu-tigcc

Sure, why not. It just so happens that, not too long ago, I was in an analogous position where I had some other package that also built against zlib, for $dayjob$. At $dayjob$ we also package free software using a scripted reproducible build. Not RPMs, but an analogous process, and at $dayjob$, for reasons that are irrelevant, zlib was installed into a nonstandard location.

The fix for that, and the analogous fix here, were that to be the case, was to stick

CPPFLAGS="-I <path> $CPPFLAGS"

right after the following line in configure, grep for it:

# Check for zlib

I'm of course, skipping over some other details (similar thing needs to be done with LDFLAGS).

So, you see -- it's not really complicated. Not at all. And, this is a typical reason why one might need to fix up the configure script. In at least 99%+ of the time

Perhaps if it's necessary to do major surgery on some package's configure script, for some reason -- if wholesale changes are required -- one might have an argument for patching configure.ac (or configure.in, for us old-timers), and rebuilding configure. But for 99% of the actual use case situations out there, it's like driving in a 1" nail with a sledgehammer. Too much risk for collateral damage.

And in fact KDE did just that (they moved to CMake and nobody at KDE is missing the autotools, quite the opposite!) and several other projects followed suit.

Yes, well, that might be one of the reasons why KDE is sweeping over the Linux desktop, and Gnome is just a fading memory for most.


Attachment: pgpXFogFQeNYU.pgp
Description: PGP signature


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