On Thu, Apr 29, 2010 at 3:59 AM, Edward Welbourne wrote:
>> Delete a "clean-depend" rule on sight,
>
> I cannot agree.
> If I write a rule to make something, I also write a rule to get rid of
> it. It's just basic hygiene ...
I propose the following guideline: If you have a target that generates
On 4/29/10, Edward Welbourne wrote:
> > If an update to new source code, that would compile just fine in a clean
> > checkout, breaks the incremental build, the build system is errornuous.
>
>
> I would like to agree with you, but this constraint is, in general,
> incompatible with incremental b
>> If an update to new source code, that would compile just fine in a clean
>> checkout, breaks the incremental build, the build system is errornuous.
> I would like to agree with you, but this constraint is, in general,
> incompatible with incremental building
That's a entertainingly provocativ
> If an update to new source code, that would compile just fine in a clean
> checkout, breaks the incremental build, the build system is errornuous.
I would like to agree with you, but this constraint is, in general,
incompatible with incremental building, which is too good a benefit to
throw awa
Edward Welbourne wrote on 29-04-2010 12:59:13:
> > Delete a "clean-depend" rule on sight,
>
> I cannot agree.
> If I write a rule to make something, I also write a rule to get rid of
> it. It's just basic hygiene ...
>
> > or rename it to the more accurate "break-future-builds".
>
> If you ha
> Delete a "clean-depend" rule on sight,
I cannot agree.
If I write a rule to make something, I also write a rule to get rid of
it. It's just basic hygiene ...
> or rename it to the more accurate "break-future-builds".
If you have a sensible rule to generate .d files when needed, you
haven't br
