Re: [boost] Re: Boost.Build - #include <> vs. ""

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-13 14:19:26

----- Original Message -----
From: <williamkempf_at_[hidden]>

> It will be nice to get this working again, but the main point of my
> post was to discuss the policy on which form to use in source.  Some
> tools do act precisely in the manner that I though Boost.Build was
> working here.

And at least one point of my post was to mention that Jam has no way to
distinguish "..." from <...> includes, so without a core change, we will at
best have the following problem:

    When a header is included by #include <xxxx> and a different
    header can be found via #include "xxxx", Jam will pick up dependencies
    on the incorrect (2nd) header and miss all those generated by the
    correct one [xxxx may be a filename or a relative path in this case].

This has a bearing on our #include policy, I think.

Since FTJam supports regular expression replacement, I think a simple
extension to fix this should be possible. Here is my proposal...

<SNIP>

!!! COOL !!!

I'm pretty sure that FTJam's regular expression replacement facilities give
us what's needed to distinguish <...> from "..." #includes. I just need to
change the HDRPATTERN to pass the quote/angle-bracket characters.

I will try making this change. To do so, I need to settle on an #include
search policy for the build system. Although I think it is possible to
support different #include searching strategies for different toolsets, it
would be best if we could make all toolsets behave the same in this regard.
Otherwise, we aren't really getting cross-platform behavior, are we?

AFAIK, the VC6 policy is a lowest-common denominator policy which all
toolsets can support. Hmm, now that I look at it, I'm a little worried. The
documentation for #include "..." says:

    This form instructs the preprocessor to look for include files
    in the same directory of the file that contains the #include
    statement, and then in the directories of whatever files that
    include (#include) that file. The preprocessor then searches
    along the path specified by the /I compiler option, then along
    paths specified by the INCLUDE environment variable

I worry about that parent file search feature. Hmm, isn't that /very/
fragile? It seems to mean that the file selected by #include "xxxx" may
depend on some "random" chain of #include parents.

So, maybe that should have some bearing on our #include policy (use <...>?)

-Dave