[Scons-users] scons: quieting external ("third party") code warnings

[Abigail Bunyan]

We solve this exact issue in a project I work on. Our solution is to modify some
(documented) SCons internal environment variables.

Specifically, in the default SCons environment, $_CPPINCFLAGS is declared as so:

    '_CPPINCFLAGS' : '$( ${_concat(INCPREFIX, CPPPATH, INCSUFFIX, __env__, RDirs, TARGET, SOURCE)} $)',

And, quoth the SCons user manual:

> _concat: A function used to produce variables like $_CPPINCFLAGS. It takes
> four or five arguments: a prefix to concatenate onto each element, a list of
> elements, a suffix to concatenate onto each element, an environment for
> variable interpolation, and an optional function that will be called to
> transform the list before concatenation.

We use this optional function to apply the prefix and suffixes ourselves. For
example, here's a GCC-specific way of using `-isystem` where appropriate:

    def makecppincflags(paths):
        paths = env['RDirs'](paths) # this was applied by default in $_CPPINCFLAGS
        result = []
        for path in paths:
            if str(path).startswith("/") or str(path).startswith("../"):
                result += ["-isystem", path.abspath]
            else:
                result.append(env['INCPREFIX'] + path + env['INCSUFFIX'])
        return result

    env['_makecppincflags'] = makecppincflags
    env['_CPPINCFLAGS'] = "$( ${_concat('', CPPPATH, '', __env__, _makecppincflags, TARGET, SOURCE)} $)"

Then code elsewhere can just add paths to env['CPPPATH']. More flexible ways of
choosing whether a path is system or user, and support for more compilers, are
both left as an exercise to the reader. (And yes, it would be better for everybody if
this were part of SCons itself.)


________________________________
From: Scons-users <scons-users-bounces at scons.org> on behalf of Mats Wichmann <mats at wichmann.us>
Sent: 15 November 2018 19:10
To: SCons users mailing list
Subject: [Scons-users] 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
Scons-users at scons.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&data=02%7C01%7Cabigail.bunyan%40microsoft.com%7C41779fc6c9b04059dfa608d64b2eed41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636779062257834256&sdata=stjH2lZ7OK9rv7AnEBxPVgln%2FqQGMQvcumdV0xWchVw%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20181127/c61142eb/attachment.html>