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

From: williamkempf_at_[hidden]
Date: 2001-07-13 17:46:28

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> ----- Original Message -----
> From: <williamkempf_at_h...>
> 
> > > 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?

If I were "playing nice with a specific compilers semantics" then 
yes.  I guess I see your point, though.  It's theoretically possible 
that by not following these precise rules the Boost headers may cause 
ODR violations unintentionally.

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

When it comes to this specific issue, I have no idea ;).  It really 
seems that we'll be damned no matter which we decide to use.  
Frankly, I don't understand why there's two forms of include to begin 
with, but if there must be why they aren't more precisely defined.  
As it is it seems like the only portable means of doing #includes is 
to use a macro to fix the style at compile time.  Of course this 
leaves you with the problem of how you manage to define the macro, 
which can just lead to a circular problem.
 
> I think I have done it in the past by getting lucky ;-)

*laughs*  Yes, I'd agree.
 
> > > 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.

I didn't do a survey, but the standard strictly states that the "..." 
form will behave as the <...> form if it fails to find the header 
with the alternate policy.  So the "..." form should simply always 
work, making the rules I laid out about as portable as you can get 
(excepting your point about relative includes and possible ODR 
violations from various "parent" rules).

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

I'm only familiar with one build tool for which this applies, so I 
can't volunteer to define pros and cons.  I also guess that so long 
as Boost.Build works with the <...> form currently used by Boost that 
given the other arguments this may be "good enough" since we simply 
can't have a portable solution. :(  I don't think anyone's had real 
problems with it in practice, so worrying about the theory may be 
unwarranted iif we can't resolve all theoretical portability problems 
any way.

Bill Kempf