Re: Using the target of a pattern rule as a prerequisite

[Noel Yap]

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