(sorry for repost, gmail sucks and I have a short memory)
On Thu, Feb 5, 2009 at 2:51 PM, Steven Knight <s...@chromium.org> wrote:
> 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.)
Right, I figured all of the info was there. I guess the question was
whether it was easy to do something like this:
$ scons_deps a.h
foo.c
$ scons_deps -v a.h
foo.c:inc.h:a.h
$ scons_deps -v <target>
foo.c:inc.h:a.h
foo.c:inc.h:b.h
bar.c:bar.h
etc.
Does such a script (or something similar) exist? From what you're
saying, I'm assuming it's easy to write.
> 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.
Right, I wasn't assuming you'd be able to figure out if a given
dependency was necessary in an automated way. The point of this would
be to emit a report that then could be examined by a human. We could
easily munge the data and answer questions like "which header is most
depended on in the source?", or "which header file adds the most bytes
to a build?" (size in bytes * number of files included)
Erik
> 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
-~----------~----~----~----~------~----~------~--~---
