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'
> > we want Boost.Build to use policy A' how do you expect to be able
> > 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
> > 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
> Many compilers have options which control the #include policy. I
think it is
> possible to find a common #include policy subset which is supported
> 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
> > may
> > > depend on some "random" chain of #include parents.
> > Depends on what your definition of 'is' is! ;) This behavior can
> > put to very effective use, and in practice isn't fragile in the
> > that most people think (i.e. you aren't likely to include the
> > header by mistake) since the directory structures are as fixed as
> > code is.
> Yes, but a header file may be #included via a different parent
> 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
> In theory, that's true. In practice, I think that's never going to
> People have too much invested in an ability to replace standard and
> headers. Still, some deference to theory can turn out to be useful
> 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
> > the right platform-specific plumbing has been errected, such as
> > or INCLUDE environment variables).
> Yeah, sort of. If you have to use relative #include paths as
> boost you're back to practice. How those paths are specified is
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
> 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
> Hmm. I guess I'm saying that portability to a theoretical
> standard-conforming compiler is impossible, so it pays to look at
> compilers actually do and try to do something that they can all
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk