Hi Erik--
It depends on what you really want. SCons does have all of the
dependencies, but it doesn't keep the #include tree.
Tangible example: if "foo.c" #includes "inc.h", and "inc.h" also #includes
both "a.h" and "b.h", the resulting dependency list actually looks like:
foo.o: foo.c inc.h a.h b.h
It's trivial to dump that sort of information from SCons' database (there's
a "sconsign" script that will do it).
It would not show you which files #included each other, which for this
example would look something like:
foo.o: foo.c
foo.c: inc.h
inc.h: a.h b.h
(SCons doesn't track those #include relationships are not actually
dependencies.)
Now that I think about it, I'm not sure how you'd use either set of
information to determine automatically that a dependency isn't needed. The
dependencies only exist because there's actually a #include line somewhere
in the chain that will (or might) suck it into the compile. Trying to
figure out if a given #include is somehow unnecessary for a given .o file
seems like a garbage-in-garbage-out problem; I don't see where you'd derive
the distinction that indicates one #include is necessary but another isn't.
But if someone does come up with a use for the dependency info (per the
first example above), it's easy enough to get.
--SK
On Thu, Feb 5, 2009 at 11:26 AM, Erik Kay <erik...@chromium.org> wrote:
>
> (arg. reposting again)
>
> One thing that scons is very good at is dependency analysis. Is it
> possible to get it to spit out a dependency report (which files depend
> on each file in the project)? I wonder if we might find that files
> like npapi.h don't actually need to touch everything, etc.
>
> Erik
>
>
> On Thu, Feb 5, 2009 at 10:48 AM, Evan Martin <e...@chromium.org> wrote:
> >
> > I fear we have a have a couple long threads of headers that touch
> > everything. At one point we had something like: v8 bindings -> stats
> > table -> process_util -> process, which meant if you touched any of
> > our process-management code we'd rebuild all of WebKit's SVG bindings.
> > :~(
> >
> > For an especially painful build, try touching npapi.h. Apparently
> > most of our project depends on that file.
> >
> > On Thu, Feb 5, 2009 at 10:29 AM, John Abd-El-Malek <j...@chromium.org>
> wrote:
> >>
> >> I've gone through the code and removed all such occurrences. This
> >> speeds up the build from 15 to 13 minutes (using /MP on quadcore with
> >> SSD). It also means that editing that file only rebuilds 36 files
> >> instead of 200.
> >>
> >> There shouldn't be any reason to include that file from a header. The
> >> reason this has happened is that people have ended up using structs
> >> that define the parameters of an IPC message with many parameters as
> >> member variables in classes. If this happens, then the struct should
> >> just be moved to its own file outside of render_messages.h.
> >>
> >> >
> >>
> >
> > >
> >
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
