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 zlibI'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:
pgpIC8rvWY6Vz.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
