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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf