Re: AC_C_LONG_DOUBLE is obsolescent.

[Eric Blake]

Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:

> > platforms, my attitude is 'If it works, great!  If it doesn't work,
> > who cares?'
> 
> If there's someone to port Autoconf to them, why not?  Unless it's very
> difficult to go forward with those limited features ...

I still think my attitude accomodates that - if someone cares about an old 
platform enough to post patches to the autoconf list, and those patches aren't 
too much of a maintenance nightmare, then I'm inclined to include them, because 
someone has demonstrated that they cared about making things work for their 
platform (however, I won't be the one posting those patches).  And I hope we 
can all agree that the line at where a patch becomes a maintenance nightmare to 
work around the limited features of a fringe platform is fuzzy.  Or put in 
other words, I hope that the decision to reject a patch from someone who spent 
time on working around the quirks of an old platform is based on technical 
merits such as size and execution impact of the patch, and not the fact taken 
in isolation that it only helps an older platform.

[Either that, or I'm suffering from a severe case of double-speak today :)]

I guess my attempt at summarizing the thoughts in this thread about the 
direction of autoconf:

Autoconf continues to be used in a wide variety of projects (not all of which 
belong to the FSF, or are even [L]GPL), and targetting a wide variety of 
platforms (not all of which have current vendor support).  It is true that 
support for older platforms will probably break as new features are added, but 
it is also true that such breakage is unintentional (we aren't going out of our 
way to penalize people on old systems).  When such breakage occurs, anyone is 
still welcome to contribute patches, and if the patches look reasonable to 
maintain, they will probably be included, no matter how old the platform is 
that the patch was designed to help; it's just that the less used a platform 
is, the less likely that someone will propose a patch.  Since Autoconf is an 
FSF project, we will continue to mention Automake, Gnulib, and other FSF 
recommended practices; but it remains a recommendation and not a requirement, 
and the Autoconf testsuite tries to ensure that we do not regress when using 
Autoconf in isolation.

Meanwhile, Autoconf will continue to deprecate macros for two reasons: because 
it no longer makes sense in modern porting targets (AC_TYPE_LONG_DOUBLE 
probably falls in this category, even though it has not been marked obsolete 
yet, since C89 is a reasonable assumption these days); or because it has an 
inconsistent interface, with pointers to the better interface to use as part of 
the upgrade (AC_C_LONG_DOUBLE falls into this category; with 
AC_TYPE_LONG_DOUBLE_WIDER listed in the manual as the replacement that 
preserves semantics but has a more consistent name).  And even when a macro is 
deprecated, we will still try to keep it working; we are trying to do better 
about maintaining upgrade compatibility than what has been done historically in 
the past (or in other words, hopefully some lessons were learned from the 2.13 
to 2.50 transition).

> 
> Shells without function support predate even the above mentioned systems
> by quite a bit.
> 

I think you meant 'with function support'; and hopefully the problem is like 
you suspect that at least one shell with function support exists by default on 
old platforms, even if finding that shell is a bit difficult.

-- 
Eric Blake