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

[Noel Yap]

Paul D. Smith wrote:

> Sure, and if people never made mistakes in programming then programs
> would never have bugs :).

There's a difference between mistakes and not thinking about consequences.

> I think David's point is that the build system should be as robust and
> reliable as possible _IN THE FACE OF_ incorrect decisions made by the
> developers.  The tradeoff here is between safety and performance (as is
> so often the case).  I think each group will need to make that decision
> for themselves... and it may well change over time.

I think my point is completely being missed.  Let's say we have:

# bar/Foo.H

struct Foo
{
        char c;
};


# baz/Foo.H

struct Foo
{
        long c;
};


This is surely unsafe (ie will likely cause memory corruption somewhere) and only the decision 
not to allow "#include <Foo.H>" will resolve the situation.

> Sometimes this behavior is impossible to obtain with third-party code.
> Sure, you could ensure that all your uses of headers put in the extra
> directory, but you can't force the 3rd party headers to always use this
> format internally!  Unless, of course, you change all their headers.

IMHO, sometimes that's what's needed.  For example, we recently changed a third-party's header 
file from a #include <> to a #include "" so that it included the correct header 
file.

I agree, though, that sometimes it's not worth it.

> Nevertheless, I think this is a good setup and the one we use here: we
> have a rule that each component gets one entry in the global include
> directory.  If they export only one header file, they can use their
> entry for a file directly.  If they export >1 header, they have to use
> their one entry for a subdirectory to contain the headers, and follow
> the #include method you mention above.

This sounds like a good way to balance all the forces involved.

Noel