From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-13 14:19:26
----- Original Message -----
> 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...
!!! 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 <...>?)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk