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

From: williamkempf_at_[hidden]
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 
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.

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 
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?

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 
across platforms.

> 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.

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 
library.  Reasonings:

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.

Bill Kempf