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

From: williamkempf_at_[hidden]
Date: 2001-07-13 16:44:23

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> ----- Original Message -----
> From: <williamkempf_at_h...>
> > 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 don't think this is true.  The "parent directory" policy discussed 
here is a classic example.  Some compilers base it off the source 
files directory and some base it off the file that does the 
#include.  These policies are not compatible, and I know of no 
compiler that lets you tweak this behavior in any way.
 
> > > 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!

Yes, I understand the theoretical fragility.  My point is that in 
practice you never have problems with this.  The "..." form is 
reserved for files in the same directory, while the <...> is used for 
all other files, and the physical directory lay out shall thus 
prevent any theoretical fragility.

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

This will likely be true for most systems, but I can definately 
imagine an embedded system for which this won't hold true.
 
> > 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.

I assume by this you meant that (#include "boost/config.hpp") is not 
a portable include directive because of the designation to look in 
the boost subdirectory.  Seems to me that this is a different subject 
all together, though a subject worth discussing.

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

I don't think you can ignore the build tools entirely.  Yes, the 
compiler behavior is more important, but why make things more 
difficult for people who rely on some build tool?  It's easier to 
ignore this when we have a Boost.Build system, but not everyone will 
(can?) use this build sytem.
 
> > 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.

You can't look at all compilers, unfortunately.  However, the rules I 
gave should be more portable then anything else, even with our known 
set of compilers supported by Boost.  In other words, the rules I 
gave will work with all the supported compilers, will probably work 
with any other compilers (excepting the relative path includes), and 
will work nicer with the policies of more build tools when it comes 
to determining dependencies.

Bill Kempf