[Scons-dev] compiler options that have a potential impact on scons

[Mats Wichmann]

I'm sure I've written about this before, though I can't find the message
in the archives. Anyway, I'll word this a little differently anyway.
This message is an attempt to follow the rules about not filing an issue
before there's some sort of agreement on a mailing list.  :)

There are a variety of compiler options that have grouping effects, or
otherwise affect things scons might need to know about the build. I'm
not sure how we should approach handling those - some might require some
general work, others can perhaps be handled as one-offs when they come
up for someone.  Work I've been doing has hit several of these.

One example:

-isystem is a gcc flag which says the following path specification
should be searched for header files, and any found should be given
special treatment, as if they were system headers.  The special
treatment at the moment is to be a little more liberal on warnings, on
the understanding that since those are not in your control you don't
want to change them to eliminate warnings, and otherwise you might be
unable to use the  warnings-as-errors behavior on compiling your
project. The flag is typically used when you're including an external
project in your build, as opposed to having the headers and libs
"installed" in the system.

Specifying the sequence in your CCFLAGS works fine, and some years ago a
change to scons enabled it to recognize this combination in ParseFlags
as well, and sort the option and following arg into CCFLAGS.  (I've made
up a PR to add two similar gcc flags which also have to do with header
search/behavior to ParseFlags).

BUT: scons doesn't know anything about this behavior. I'm not sure it
needs to know about the "system header" behavior, but I suspect it needs
to know that header files can be found in the specified path, and
without that the scanner will never operate on any headers found in
directories specified by such alternate means, because those never get
added into CPPPATHS, only into CCFLAGS.


Second example:

The linker on Linux has a bunch of options that toggle behavior, and
thus need to be grouped together with the objects they are going to
affect.  Examples are -Bstatic, -Bsymbolic, -Wl,--as-needed,
-Wl,--no-as-needed, -Wl,--whole-archive, -Wl,--no-whole-archive  and a
bunch more (those are ones I've run into problems with personally).

As far as I know the only way to handle these now is just to put them
together with the affected libraries into the appropriate flags
variable, because they need to be kept together with their libs; you
can't put the libraries into LIBS because those will be sorted
separately and the binding lost.  And that, again, means scons doesn't
really know that those specific libraries are part of the story in
building the program.  Here's a specific example of how one of our
developers set up one of these:

env.AppendUnique(LINKFLAGS=[
    '-Wl,--allow-shlib-undefined',
    '-Wl,--whole-archive', libmpm,
    '-Wl,-no-whole-archive',
])

env.AppendUnique(LIBS=[
    'm',
    'octbstack',
    'ocsrm',
    'connectivity_abstraction',
    'coap',
    'curl',
])

so the libmpm (symbol defined elsewhere) isn't really included in the
build computations as it's not in LIBS.


Ideas on these?