4 ms·

> [...] treated some of the code used for various feature checks invalid and the end result was checks failing even though they should have passed - often with

by boris 4y ago

> [...] treated some of the code used for various feature checks invalid and the end result was checks failing even though they should have passed - often with barely any notification to the user (the user would see a "no" instead of a "yes" in some check) This is a perfect illustration of conceptual bankruptcy of the autoconf approach. Using compile/link tests and basing a decision on whether they succeeded or failed without distinguishing the reasons for failure will inevitably lead to silent false negatives. If you are wondering what to do and what are the alternatives, here is one approach: https://github.com/build2/libbuild2-autoconf https://github.com/build2/libbuild2-autoconf

badsectoracula 4y ago
> This is a perfect illustration of conceptual bankruptcy of the autoconf approach. Using compile/link tests and basing a decision on whether they succeeded or failed without distinguishing the reasons for failure will inevitably lead to silent false negatives. The tests are actually fine as an idea, it is much better to perform tests to see if something is there instead of trying to guess based on other means, like OS name or whatever. The problem isn't the idea of testing for the features you need (like checking if a header file or function is there), it is that the code generated for some of the tests was pre-C89. This was accepted by pretty much all C compilers from the 80s to today, until Clang 16 decided not to accept it anymore. Technically they could have taken a different approach like checking the libraries themselves directly (for the case of libraries), but that'd require knowledge about the library formats and availability and i'm almost certain that the current approach gives the largest portability while requiring the least knowledge about that system. Even now it is Clang 16 specifically that has the issue and it was already been fixed upstream last year.

by boris 4y ago

badsectoracula 4y ago

> This is a perfect illustration of conceptual bankruptcy of the autoconf approach. Using compile/link tests and basing a decision on whether they succeeded or failed without distinguishing the reasons for failure will inevitably lead to silent false negatives. The tests are actually fine as an idea, it is much better to perform tests to see if something is there instead of trying to guess based on other means, like OS name or whatever. The problem isn't the idea of testing for the features you need (like checking if a header file or function is there), it is that the code generated for some of the tests was pre-C89. This was accepted by pretty much all C compilers from the 80s to today, until Clang 16 decided not to accept it anymore. Technically they could have taken a different approach like checking the libraries themselves directly (for the case of libraries), but that'd require knowledge about the library formats and availability and i'm almost certain that the current approach gives the largest portability while requiring the least knowledge about that system. Even now it is Clang 16 specifically that has the issue and it was already been fixed upstream last year.