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

[Gary Oberbrunner]

On Fri, Jan 17, 2014 at 1:06 PM,
<andreas.ames at de.transport.bombardier.com> wrote:

>> 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.

>

> You are right regarding of what I'm hoping for.  I should have explained

> the general idea before asking questions about it, sorry.  I'll try to

> make good for my omission, sticking with gcc as an example.

>

> I would like to 'smuggle' an additional '-H' command line option into the

> command line associated with StaticObject (and SharedObject etc.) and

> filter the stderr for indications of include files being used by the

> preprocessor.  IIRC, gcc prints the absolute path of the include files, so

> these could be used without further ado.  Calling the

> compiler/preprocessor onece more time StaticObject seems wasteful to me

> (performance-wise).  Besides the performance gain the suggested approach

> would also ensure that the compiler configuration is implicitly the same

> for both target creation and computation of dependencies.

>

> To be honest I can't see a principal problem with such an approach.  On

> the first scons run (let's say after VCS checkout or so) the target is not

> there yet, so a build is necessary anyway.  As part of this build the

> implicit dependencies are computed, which are used as inputs for the

> out-of-date analysis of the next run.  But it's well possible that I'm

> just missing something important here.


Yup. Let's say foo.c depends on foo.h, which is _generated_ (not part
of the source, but created as a target by some builder).  Your first
build will fail in this case, since SCons doesn't know about the
dependency until it's too late.

And also, even without generated headers, you'll always get a rebuild
on the second build since the dependency list has changed (foo.c now
depends on foo.h, but didn't on the first run.)

-- 
Gary