[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using the target of a pattern rule as a prerequisite
From: |
Noel Yap |
Subject: |
Re: Using the target of a pattern rule as a prerequisite |
Date: |
Fri, 04 Jun 2004 10:51:23 -0400 |
User-agent: |
Mozilla Thunderbird 0.5 (Windows/20040212) |
David Boyce wrote:
Well, obviously it's a bad idea. But "don't do that" is a fine solution
for an individual, less so for an enterprise. And when given a choice
between code that runs fast and is "usually" correct, and code which
takes some extra cycles to get it right every time, most
managers/architects/users would choose the latter.
Strange, I think it's not so bad for an individual to do since he knows what's
happenning. When it tries to scale to the enterprise, though, strange things
start happenning and noone knows what's going on.
Look, I don't want to hijack an already drifting thread. Just to point
out that the statement "depending on a directory is bad" is overly general.
Granted. I'll also add that every rule of thumb is overly general which is why
I prefer having rationale attached to the rules of thumb.
If I could add an anecdote, though ... I ran into this nearly ten years
ago when I came into a large organization whose developers were in open
revolt. They used ClearCase - though that's not central to the story -
and were refusing to use clearmake with winkins because they had
incontrovertible evidence that it was broken; it had winked in a broken
old object when it shouldn't have. They'd started doing clean builds
constantly, with predictable pain and suffering. When I got to the
bottom of the problem it turned out to be this eclipsing behavior, which
applies to all make programs equally. The point of the story is that
adding the dependency actually saved huge numbers of cycles because the
alternative was an untrusted build that was redone from scratch many
times a day.
Interesting. Do you think this would've happened had they not included identically-named header files. I'm not saying not to have identically-named header files; when dealing with many projects, it's impossible to keep them all unique especially when
dealing with third-party code. But they should all be within their own directories such that the following is possible:
#include <bar/foo.h>
#include <baz/foo.h>
IOW, the problem arises when the include path allows the following:
#include <foo.h>
Noel
- Using the target of a pattern rule as a prerequisite, Bram, 2004/06/03
- Re: Using the target of a pattern rule as a prerequisite, Paul D. Smith, 2004/06/03
- Re: Using the target of a pattern rule as a prerequisite, Noel Yap, 2004/06/03
- Re: Using the target of a pattern rule as a prerequisite, Boris Kolpackov, 2004/06/03
- Re: Using the target of a pattern rule as a prerequisite, Paul D. Smith, 2004/06/04
- Re: Using the target of a pattern rule as a prerequisite, Noel Yap, 2004/06/04
- Re: Using the target of a pattern rule as a prerequisite, David Boyce, 2004/06/04
- Re: Using the target of a pattern rule as a prerequisite, Paul D. Smith, 2004/06/04
- Re: Using the target of a pattern rule as a prerequisite, Noel Yap, 2004/06/04
- Re: Using the target of a pattern rule as a prerequisite, David Boyce, 2004/06/04
- Re: Using the target of a pattern rule as a prerequisite,
Noel Yap <=
- Re: Using the target of a pattern rule as a prerequisite, Paul D. Smith, 2004/06/04
- Re: Using the target of a pattern rule as a prerequisite, Noel Yap, 2004/06/04
- Re: Using the target of a pattern rule as a prerequisite, David Boyce, 2004/06/04
- Re: Using the target of a pattern rule as a prerequisite, Noel Yap, 2004/06/04
Re: Using the target of a pattern rule as a prerequisite, Boris Kolpackov, 2004/06/03