Ralf Corsepius writes:
On 07/04/2011 01:18 PM, Sam Varshavchik wrote: > Both gcc and binutils are extensively regression-tested. Stuff that was > compiled years ago, still works. To some extend, yes, Nevertheless we all are permanently fixing gcc/binutils-compatibilities, aren't we?
Right. But the same cannot be said for autotools. The macros change, and configure scripts are expected to be updated to reflect the changes.
> The same cannot be said of autotools. Well, check the sources - autoconf+automake have similar testsuites.
Perhaps, but they would not be testing that ten-year old code still gets processed, without warnings.
I've got C++ code that's more than ten years old. Still builds just fine, without any diagnostics.
Try feeding an average ten-year old configure.in script to autoconf, and see what happens.
It's the same problem as with binutils/gcc: languages change, standards change, incompatibilities are being introduced deliberately, bugs find their ways in, old features get abandoned/new ones introduced etc. The real difference between the autotools and gcc is: Many people are permanently modernizing their c/c++-code, but are expecting modern autotools to support the bugs/non-documented features the autotools did 10-15 years ago.
Not really. Like I said, I have lots of code that, so far, didn't need any modernizing.
But I do recall an update to autoconf, a few releases ago, that I had to respond to, with some fixes to my configure scripts. I'm fairly certain I remember one or two occasions where an initial autoconf package had an update to a newer release of autoconf, and some changes to configure scripts were needed, if you were using autoconf.
Attachment:
pgpaYGwV7CWJH.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
