Yes. One of many mistakes it can helpfully make for you (along with including
impl headers instead of the API ones, only being correct for the current build,
etc.).
I believe you can setup rules to stop it doing this particular thing. But in
general, IWYU is a semi-automatic process and require
Nicholas Nethercote wrote:
On Wed, Aug 8, 2012 at 12:36 PM, Nicolas Silva wrote:
I have an ugly script that goes through the dependency files generated by make
to collect informations about dependencies. I'll clean it up if you are
interested (and rewrite it in python because I suppose pe
On 08/08/2012 04:32 PM, Justin Lebar wrote:
So I have this scripts that gives for each header the number of translation
units that use it, here is part of the output (i skipped the headers
included in less than 9 TUs) from a week ago (after dzbarsky's patch):
http://pastebin.mozilla.org/1745141
On 09/08/12 13:03, Nicholas Nethercote wrote:
IME, this is one those things that seems easy and worthwhile but
usually ends up being a real pain, and doesn't seem worth it. Getting
it 90% right isn't too bad but there's often some trouble in the last
10% that torpedoes it.
Over-inclusion can c
On Wed, Aug 8, 2012 at 12:36 PM, Nicolas Silva wrote:
>
> I have an ugly script that goes through the dependency files generated by
> make to collect informations about dependencies. I'll clean it up if you are
> interested (and rewrite it in python because I suppose people in here don't
> want to
On Wed, Aug 8, 2012 at 10:32 PM, Justin Lebar wrote:
> > So I have this scripts that gives for each header the number of
> translation
> > units that use it, here is part of the output (i skipped the headers
> > included in less than 9 TUs) from a week ago (after dzbarsky's patch):
> > http://past
> So I have this scripts that gives for each header the number of translation
> units that use it, here is part of the output (i skipped the headers
> included in less than 9 TUs) from a week ago (after dzbarsky's patch):
> http://pastebin.mozilla.org/1745141
>
> It is an approximation because it u
On 08/08/2012 03:46 PM, Justin Lebar wrote:
That's the thing, it is hard to measure the impact of bad dependencies unless
you compare the same code with bad and good dependencies (which would
mean spending the time to fix existing code), or have already experienced it
in another project, or even
On 8/8/12 12:36 PM, Nicolas Silva wrote:
On 08/08/2012 02:27 PM, Benjamin Smedberg wrote:
On 8/8/2012 2:09 PM, Nicolas Silva wrote:
Hi dev-platform,
I spent some time looking at include dependencies lately, and I think
it is an area where we can improve our code without too much effort.
Bad in
> That's the thing, it is hard to measure the impact of bad dependencies unless
> you compare the same code with bad and good dependencies (which would
> mean spending the time to fix existing code), or have already experienced it
> in another project, or even trust what people say on the internet
On 08/08/2012 02:27 PM, Benjamin Smedberg wrote:
On 8/8/2012 2:09 PM, Nicolas Silva wrote:
Hi dev-platform,
I spent some time looking at include dependencies lately, and I think
it is an area where we can improve our code without too much effort.
Bad include dependencies lead to slower builds
On 8/8/2012 2:09 PM, Nicolas Silva wrote:
Hi dev-platform,
I spent some time looking at include dependencies lately, and I think
it is an area where we can improve our code without too much effort.
Bad include dependencies lead to slower builds.
What kind of evidence do we have for this? Befor
12 matches
Mail list logo
