scons: quieting external ("third party") code warnings

Wanted to bring this to the list in case anyone has more elegant ideas.
A bit of introduction:

These days it's pretty common for open source projects which are not
specifically just libraries for reuse to depend on other open source
projects.  Sometimes those projects can cause build problems.  It's
moderately common practice (certainly the policy in iotivity, the
project that brought me over to SCons) to say "unless it is completely
unavoidable, we don't want to apply patches to third-party code, instead
let's propose fixes to those projects and hope they accept them".

C++ warnings aren't in the "it is completely unavoidable" category, but
if you build with warnings-as-errors, a safety measure projects
sometimes choose to apply, they can break builds.

If the external project is a library that you build and link to, then it
may be possible to just turn off the warnings-as-errors flag, whatever
it may be for the compiler you're using, when building the library.  But
there's also the case of including headers from such projects, and some
projects are headers-only, and we don't want to turn off the errors when
building our own code, so it doesn't work there.

The gcc answer for this is to include header directories from code you
don't control using "-isystem path" instead of with "-Ipath" (see gcc
manpage). There are also "-iquote" and "-idirafter" to give finer
grained control over header search policy.  SCons does know about
-isystem (added for 2.3.5, according to the changelog), and documents
(in code) that it does not handle -iquote.. Environment.py:
SusbstitutionEnvironment.ParseFlags

I just did that for the two project directories that started breaking
when gcc8 landed (the upstreams for those have not yet released fixed
code, although they will eventually), and it seems to work as intended.


So here's the question for discussion:  doing it this way isn't terribly
elegant.  adding an include path via CPPFLAGS means the argument (the
path you want included) isn't handled by SCons' path handling stuff, so
for example a path like "#foo/bar/include" will just cause error. You
can work around that, but it ends up not looking like how the other
header directories are handled.  The -isystem flag is gcc-specific
(having not tested, I'm not even sure if clang accepts it), so if you're
trying to do multi-platform builds you have to do something conditional
by platform, perhaps by checking the compiler is gcc.

is there, or alternatively, can we invent, some way for header
directories to be marked for special handing, which scons then makes use
of when emitting the actual compiler command line?  So a gcc-using
system could use -isystem, and other compilers, if they have an
equivalent, could use what is right for them - without cluttering up
sconscripts with conditional stuff where it doesn't really seem necessary?

_______________________________________________
Scons-users mailing list
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users