You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A preprocessor identifier __has_include was added to the C standard in the 2023 edition; the same identifier has appeared in the C++ standard since the 2017 edition (one of the justifications for adding to C was to keep the preprocessors relatively aligned). The identifier allows coding conditional inclusion of a header file, and thus affects SCons dependency scanning. Since most C compilers are also C++ compilers, this identifier is widely implemented already.
Don't have any clear idea how to teach the scanner to handle this case, where a system header is used if it exists, if not an experimental header is used, and if neither, some inline code is used. We don't usually generate dependencies for "system headers", but the algorithm is unsophisticated - if it's not found, assume it's a system header and don't generate the dep, which has the potential to miss headers which will be generated by the build. There's of course no rule that says this check-for-include-file functionality has to be limited to system headers.
They use the same base class which does recognize ifdef and friends, but doesn't evaluate them; the conditional scanner is "smarter" and adds extra stuff.
A preprocessor identifier
__has_include
was added to the C standard in the 2023 edition; the same identifier has appeared in the C++ standard since the 2017 edition (one of the justifications for adding to C was to keep the preprocessors relatively aligned). The identifier allows coding conditional inclusion of a header file, and thus affects SCons dependency scanning. Since most C compilers are also C++ compilers, this identifier is widely implemented already.From the standard, here is example usage:
As a shorter write-up than going through the entire standard, here is the accepted proposal which added it to C:
https://open-std.org/JTC1/SC22/WG14/www/docs/n2799.pdf
The text was updated successfully, but these errors were encountered: