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

[David Boyce]

At 09:31 AM 6/4/2004, Paul D. Smith wrote:
> %% Boris Kolpackov <address@hidden> writes:
>
>   bk> "Paul D. Smith" <address@hidden> writes:
>
>   >> In general it's not a good idea (IMO) to depend on a directory
>   >> anyway: it will cause your code to rebuild in many situations where
>   >> it's not necessary.
>
>   bk> I think using order-only dependency on a directory is not such a bad
>   bk> idea.
>
> Yes, that's true.  Of course then he has the original problem of
> obtaining the directory name in the prerequisite list.  I realize you
> have a solution for that in your patches as well :-).

This whole conversation seems to be conflating the concept of "having a 
directory as a prerequisite" with that of "having a directory as a target". 
Paul says that depending on a directory isn't a good idea, and maybe that's 
true where the goal is to create dirs automatically, but there's a 
different situation where depending on a directory is always (IMO of 
course) a good idea: when a (non-target) directory appears on a searched path.

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.

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.

-David Boyce