[Scons-users] Extracting "-I" paths in a complex tree

[Gary Oberbrunner]

On Fri, Jan 17, 2014 at 11:03 AM,
<andreas.ames at de.transport.bombardier.com> wrote:

>> I agree, that would be perfect.  I don't know of any such

>> implementation though.

>>

>> That said, Scanners are more-or-less pluggable, so if you wrote one

>> you could pretty easily plug it in.

>

> I've actually thought about that but I'm stuck with two doubts because of

> my lack of knowledge about SCons internals.  Maybe you (or someone else)

> can help me with this:


I think what you're hoping for is to somehow do the scanning as part
of the build process -- but of course it's too late then.  If foo.c
depends on foo.h which is a generated header, by the time you compile
foo.c and discover it needs foo.h it's too late to go back and
generate it.  Scanning for deps has to be done before building.  If
you're going to run the compiler (or at least preprocessor) you'll
have to do it an extra time in the scanner.


> 1. AFAIK, source scanners are executed *before* the actual build.  In case

> of using compiler outputs for dependency generation this is not possible.

> OTOH, implementing this as a target scanner wouldn't be desirable in this

> case because in my understanding this requires a complete rebuild after

> the initial build as all implicit dependencies will be new on the second

> build.  So, do you know of a simple possibility to 'postpone' the

> execution of a source scanner to combine it with the actual build?


[Here I'm quoting an old mailing list post by Greg Noel; he says it well.]

A target scanner is run when the explicit dependencies are up-to-date
and it would be otherwise possible for the step to be executed to
build the file.  It can add additional implicit dependencies that must
exist before the step can be run.  For example, the Program() builder
uses one to add the LIBS as implicit dependencies to cause any
libraries to be (re)built before the program is linked.

A source scanner is run when the file is about to be used as a source
(and hence the file exists) to nominate any other files that will be
implicitly needed when the step is run.  For example, the C source
scanner finds #include files, since they will be read when the
compiler is run.  This will cause any implicit dependency to be
(re)built if it is out of date.


>

> 2. To implement such a scanner the output of the compiler must be

> filtered; in the case of gcc it's the stderr that is relevant.  Is there

> any hook available in SCons to filter the build command's output?


No, but since you can't use the output of the actual build command
anyway, you'll just be parsing the output of whatever you run as part
of the scanner (whether it's gcc or cpp or some llvm thing).

-- 
Gary