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

[David Boyce]

At 10:18 AM 6/4/2004, Noel Yap wrote:
> David Boyce wrote:
>
> > The canonical example is where you compile with a series of -I flags:
> >         % cc -I/dir1 -I/dir2 -I/dir3 -I/dir4 ...
> > Say the first time you built, the file foo.h was found in /dir3. But then 
> > you - or someone else - subsequently adds a foo.h to /dir2. Now the 
> > target is out of date just as surely as if the source file was modified, 
> > but there's no way for make to know it. Even if you generate dependencies 
> > such that it sees an explicit dependency on /dir3/foo.h, it cannot know 
> > that the path search would find /dir2/foo.h instead if rebuilt.
>
> First, I think the above is a really bad idea -- you have two files named 
> foo.h and, depending upon the order of the include path, either can be 
> included.

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.

> > The only solution to this is to treat the directories searched (in any 
> > path, -I or -L or potentially even $PATH) as prerequisites. It's not hard 
> > to use standard GNU make functions to grab the -I or -L flags from CFLAGS 
> > or LDFLAGS or wherever and list them as explicit dependencies. If there's 
> > an argument for why that's a bad idea, I haven't heard it.
>
> Directory timestamps are usually updated each time a file is added or 
> removed from the directory.

Not usually, always. And that's the point.

> This can potentially lead to things being built /all/ the time (eg if an 
> object file depended upon its directory, after the object file is built, 
> the directory's timestamp may be later than the object file's timestamp).

I didn't recommend that an object file depend on its directory, I 
recommended that directories *in searched paths* be treated as 
dependencies. Of course Paul is right that the great majority of changes to 
such dirs don't result in eclipses; on the other hand, those dirs don't 
tend to get changed much. And for the occasional case where directories are 
both generated and searched, I guess you could leave out the dir dependence 
on the theory that "direct" dependencies on the generated files themselves 
will catch the updates.

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.

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.

-David Boyce