an update to automake-1.11?

[Sam Varshavchik]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090706/bd4f64ff/attachment.sig>