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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-13 16:03:18

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

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

yep.

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

Yes, it's the difference between theory and practice (in theory it's
impossible to do threading in C++ because the standard doesn't support it
;-)).

Many compilers have options which control the #include policy. I think it is
possible to find a common #include policy subset which is supported by all
or nearly all compilers.

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

Yes, but a header file may be #included via a different parent chain in
different translation units. So:

--- x/a.hpp ---
#include "b.hpp"
--- y/b.hpp ---
int f();
--- y/c.cpp ---
#include "x/a.hpp"
--- z/b.hpp ---
void f();
--- z/c.cpp ---
#include "x/a.hpp" <= ODR violation!

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

OK

> 2) <...> may not work for non-standard headers (which will be files).

In theory, that's true. In practice, I think that's never going to happen.
People have too much invested in an ability to replace standard and system
headers. Still, some deference to theory can turn out to be useful in
practice ;-)

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

Yeah, sort of. If you have to use relative #include paths as required by
boost you're back to practice. How those paths are specified is
platform-specific.

> 4) <...> headers are ignored as dependencies by some build tools,
> such as VC++ projects.

I am inclined not to worry as much about the in-practice behaviors of
arbitrary build tools as about those of the compilers.

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

Hmm. I guess I'm saying that portability to a theoretical
standard-conforming compiler is impossible, so it pays to look at what
compilers actually do and try to do something that they can all support.

-Dave