autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_C_LONG_DOUBLE is obsolescent.


From: Harlan Stenn
Subject: Re: AC_C_LONG_DOUBLE is obsolescent.
Date: Wed, 09 Apr 2008 19:27:50 +0000

Eric Blake wrote:
> According to Bob Friesenhahn on 4/9/2008 12:35 PM:
> | I am confused since I don't see how the usefullness of this test can be
> | obsolescent.
> 
> 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?

> On the other hand, the properties of long double are still very much a
> portability nightmare, and many libm lack long double support even though
> the compiler supports a long double type.  Gnulib has some macros that do
> much more extensive testing of long double's properies; you are better off
> using those macros than trying to make AC_C_LONG_DOUBLE learn all of these
> properties of the type.

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

> | I am also confused by the use of the term "current systems" since
> | perhaps it means some specific version of Linux/glibc rather than the
> | set of still running systems on which an autoconf configure script may
> | be executed.  If autoconf is targeted toward "current systems" then a
> | definition of what this means (i.e. the criteria for which systems are
> | no longer supported) should be documented.
> 
> 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.

> At any rate, I am not opposed to re-adding AC_C_LONG_DOUBLE as a
> non-obsolescent macro if gnulib's approach is inadequate and if using the
> macro provides enough useful other properties that are still relevant in
> modern porting targets.

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.

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.

H




reply via email to

[Prev in Thread] Current Thread [Next in Thread]