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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-13 17:15:01

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

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

CodeWarrior is one example.

> 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

In that case #include "boost/iterator_adaptors.hpp" would be unacceptable,
right?

> while the <...> is used for
> all other files, and the physical directory lay out shall thus
> prevent any theoretical fragility.

Ignoring the relative #include issue above for a moment, couldn't we then
rely on a combination of the in-practice directory layout conventions and
the in-practice compiler #include policies? If not, how do people /begin/ to
write portable C++?

I think I have done it in the past by getting lucky ;-)

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

Yes, an imaginary one. In practice developing C++ cross-compilers for
embedded systems is incredibly expensive. Nobody serious enough to finish
the job is wasting their time with native embedded compilers tailored for
the embedded environment.

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

Yes.

> Seems to me that this is a different subject
> all together, though a subject worth discussing.

I think it's closely related, and just more evidence that we're completely
out of the territory of theoretical portable C++, so we might as well look
closely at practice.

> > 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 makes sense for me if it makes my life very much easier. In this case,
I'm not sure that it does.

> It's easier to
> ignore this when we have a Boost.Build system, but not everyone will
> (can?) use this build sytem.

In theory, everyone can. But now we're back to theory ;-)

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

Okay; I will assume you've done a quick survey and accept your assertions
about portability and supported compilers without question. It seems to me
that the last point (other build tools) is the only one that has a real
bearing on "..." vs. <...>, though. Am I correct? If so, I would like to
focus the discussion on that, since other people have made strong arguments
in the other direction. We need a good clear list of the pros and cons. Any
volunteers?

-Dave