Calling autoconf in a spec.

[Sam Varshavchik]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110704/805ba804/attachment.bin