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 broken
Edward Welbourne e...@opera.com 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
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
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 provocative
On 4/29/10, Edward Welbourne e...@opera.com 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
On Thu, Apr 29, 2010 at 3:59 AM, Edward Welbourne e...@opera.com 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
