Re: AC_C_LONG_DOUBLE is obsolescent.

[Eric Blake]

Harlan Stenn <stenn <at> ntp.org> writes:

> > The test was merely whether compilers support the type 'long double'; as
> > all modern compilers obey this part of the C standard, it is no longer
> > worth checking whether long double is syntactically valid, and rather just
> > assuming that it is.
> 
> Are you *sure* that autoconf will not support any machine with a less
> modern compiler?

No, nor did I claim this.  Rather, I am stating that for projects that only 
care about reasonably modern porting targets (and this includes any project 
that uses gnulib, since gnulib will not bend over backwards to cater to 
obsolete targets), then using AC_C_LONG_DOUBLE is not recommended.  Part of the 
problem was that the interface provided by AC_C_LONG_DOUBLE defines 
HAVE_LONG_DOUBLE, which is a confusing macro name - there are platforms that do 
indeed have 'long double', but where it is not wider than 'double' - should 
HAVE_LONG_DOUBLE be defined or not?

What you should do instead is use AC_TYPE_LONG_DOUBLE (which will probably 
succeed and define HAVE_LONG_DOUBLE, since most compilers support a long double 
type), or more likely, AC_TYPE_LONG_DOUBLE_WIDER (which is actually useful 
information on modern targets and conditionally define HAVE_LONG_DOUBLE_WIDER - 
in other words, a test that is more accurately named for what AC_C_LONG_DOUBLE 
is currently testing).

> 
> Are you saying autoconf has a primary target audience of systems that
> use gnulib?

No, that's not the intent either.  Autoconf intends to remain portable to a 
much wider audience (both projects and platforms) than what gnulib targets (in 
part, because gnulib is tied to (L)GPL licensing while autoconf can be used 
with other license models, and in part because some people like porting 
software to platforms where gnulib has declared that the maintenance-to-benefit 
ratio is not worth it).

> > Yes, current systems is intended to mean any system that an autoconf
> > configure script will run on.  It excludes platforms like Solaris 4, which
> > are no longer supported by the vendor.
> 
> There are more older systems out there than  SunOS4.

True.  But not really relevant to the decision to obsolete AC_C_LONG_DOUBLE, 
when there are two replacement macros that provide a more consistent interface 
into the two separate questions that the original macro was asking.

> When you say "... and if using the macro provides ..." you mean
> AC_C_LONG_DOUBLE then I feel a bit better.  If you still intend that
> autoconf should only care about systems that have gnulib then I am
> concerned.

Autoconf MUST continue to care about projects that do not use gnulib.  I'm only 
stating that IF you use gnulib, then AC_C_LONG_DOUBLE buys you nothing, and you 
are better off using modern macros like AC_TYPE_LONG_DOUBLE_WIDER instead.

> 
> And I have not looked into this matter very deeply.
> 
> I do care very much that the packages I have autoconfiscated will
> support the widest possible range of running systems.

As do I.

-- 
Eric Blake