Disabling warnings for headers in subprojects.

[andre-caldas]

I love warning_level=everything. But I do not want to see the warnings for stuff in a subproject (pybind11 to be specific). It would be nice if I could disable warnings in dependency().

For example, being able to pass is_system to dependency() would be nice.

Actually, I do think dependency() could make things as is_system: true by default. But I do not have an opinion on which is more appropriate.

[eli-schwartz]

is_system marks the headers as being a stdlib implementation such that gcc should apply its #include_next processing for it. It doesn't have anything to do with warnings.

GCC doesn't implement -iexternal, unfortunately.

[andre-caldas]

Sorry! :-)

I am very ashamed to say that I was told by chatgpt that is_system would have the effect of including as -isystem, which would disable the warnings.

But then, I would like to withdraw my is_system idea and simply focus on the real problem:

I get tons of warnings from CGAL and pybind11. I would like my dependency() stuff to not show warnings. For example (example!) by using -isystem instead of -I.

How do I do that? :-)

[eli-schwartz]

Sorry! :-)

I am very ashamed to say that I was told by chatgpt that is_system would have the effect of including as -isystem, which would disable the warnings.

The -isystem compiler flag marks the headers as being a stdlib implementation such that gcc should apply its #include_next processing for it. It doesn't have anything to do with warnings.

But then, I would like to withdraw my is_system idea and simply focus on the real problem:

I get tons of warnings from CGAL and pybind11. I would like my dependency() stuff to not show warnings. For example (example!) by using -isystem instead of -I.

How do I do that? :-)

Petition GCC to invent a mechanism for doing it. :)

It is supported by MSVC: https://devblogs.microsoft.com/cppblog/customized-warning-levels-and-code-analysis-for-external-headers/

(Meson doesn't have an option to do this for MSVC either, though we should really add it. There's an existing open ticket requesting it.)

[andre-caldas]

It might be a side effect... it might even be incorrect... but indeed, using -isystem did got me rid of the warnings.

The hack I used to solve my problem was:

CXXFLAGS="-isystem /home/andre/.local/include -isystem ../../subprojects/pybind11-2.13.5/include"

CGAL is installed in ~/.local/include. And pybind is a subproject. Of course, I will have to adapt when I upgrade the subprojects.

If this is incorrect... anyone, please, let me know! :-)

Also, the gcc documentation on -isystem does not mention anything about stdlib. It says:

Search dir for header files, after all directories specified by -I but before the standard system directories. Mark it as a system directory, so that it gets the same special treatment as is applied to the standard system directories. If dir begins with "=", then the "=" will be replaced by the sysroot prefix; see --sysroot and -isysroot.

No #include_next and no stdlib. Maybe by #include_next you mean the first sentence: "after all directories specified by -I".

Source: https://manpages.org/gcc/

[eli-schwartz]

https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html

You can use -I to override a system header file, substituting your own version, since these directories are searched before the standard system header file directories. However, you should not use this option to add directories that contain vendor-supplied system header files; use -isystem for that.

The -isystem and -idirafter options also mark the directory as a system directory, so that it gets the same special treatment that is applied to the standard system directories.

If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option is ignored. The directory is still searched but as a system directory at its normal position in the system include chain. This is to ensure that GCC’s procedure to fix buggy system headers and the ordering for the #include_next directive are not inadvertently changed. If you really need to change the search order for system directories, use the -nostdinc and/or -isystem options.

A common source of miscompilation and compiler errors is using -isystem for Boost, which is 1) well known to have lots of warnings, and also 2) well known to be installed in /usr/include, which results in people using it for hacky undocumented side effects for the former and then breaking the latter completely by erroneously changing the precedence of directory ordering and causing headers to be mistranslated by the preprocessor.

Adding additional ways for people to break their system feels unfortunate. It should be balanced by whether it adds additional ways for people doing advanced concepts such as building a freestanding custom standard C library. changing the defaults for dependency() certainly doesn't help out people building a freestanding C stdlib, which means that my personal opinion is we absolutely should not be doing it... All it will do is make many projects start failing to compile and generating a very large number of complaints and bug reports.

[andre-caldas]

A common source of miscompilation and compiler errors is using -isystem for Boost, which is 1) well known to have lots of warnings, and also 2) well known to be installed in /usr/include, which results in people using it for hacky undocumented side effects for the former and then breaking the latter completely by erroneously changing the precedence of directory ordering and causing headers to be mistranslated by the preprocessor.

Adding additional ways for people to break their system feels unfortunate. It should be balanced by whether it adds additional ways for people doing advanced concepts such as building a freestanding custom standard C library. changing the defaults for dependency() certainly doesn't help out people building a freestanding C stdlib, which means that my personal opinion is we absolutely should not be doing it... All it will do is make many projects start failing to compile and generating a very large number of complaints and bug reports.

Good. So you are against "changing the defaults". I still do not have an opinion on this. And this is not what I have proposed, although I did comment on it.