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? _______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev