Date: 2001-07-13 15:05:35
--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> ----- Original Message -----
> From: <williamkempf_at_h...>
> > It will be nice to get this working again, but the main point of
> > post was to discuss the policy on which form to use in source.
> > 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
> distinguish "..." from <...> includes, so without a core change, we
> 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
> on the incorrect (2nd) header and miss all those generated by
> correct one [xxxx may be a filename or a relative path in this
> This has a bearing on our #include policy, I think.
Possibly, but I think all it does is further muddy the waters of what
each include form does. Now we've got possible conflicts between the
build tools and the compiler in how they interpret each.
> Since FTJam supports regular expression replacement, I think a
> extension to fix this should be possible. Here is my proposal...
> !!! COOL !!!
> I'm pretty sure that FTJam's regular expression replacement
> us what's needed to distinguish <...> from "..." #includes. I just
> 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
> search policy for the build system. Although I think it is possible
> support different #include searching strategies for different
> would be best if we could make all toolsets behave the same in this
> Otherwise, we aren't really getting cross-platform behavior, are we?
I don't see how you can make toolsets behave the same in this
regard. If toolset A uses policy A' and toolset B uses policy B' and
we want Boost.Build to use policy A' how do you expect to be able to
make B use A' as well? The behavior of the two include forms is
unspecified, so it's not really possible to make them behave the same
> AFAIK, the VC6 policy is a lowest-common denominator policy which
> toolsets can support. Hmm, now that I look at it, I'm a little
> 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
> fragile? It seems to mean that the file selected by #include "xxxx"
> depend on some "random" chain of #include parents.
Depends on what your definition of 'is' is! ;) This behavior can be
put to very effective use, and in practice isn't fragile in the sense
that most people think (i.e. you aren't likely to include the wrong
header by mistake) since the directory structures are as fixed as the
code is. However, this illustrates very effectively how different
toolsets can use different policies and how we can't dictate the
policies in any sort of portable manner.
> So, maybe that should have some bearing on our #include policy (use
Yes, I think it should, but I come to a different conclusion than I
think you just did (if I read the above correctly). I think Boost
should use "" exclusively for all headers not part of the standard
1) <...> is the only form gauranteed to work for standard headers
(which may not be files).
2) <...> may not work for non-standard headers (which will be files).
3) "" is gauranteed to work for all non-standard headers (providing
the right platform-specific plumbing has been errected, such as PATH
or INCLUDE environment variables).
4) <...> headers are ignored as dependencies by some build tools,
such as VC++ projects.
These are not the rules I'd pick for my own environment (VC), but
they seem to be the only logical rules for a portable implementation.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk