Re: [boost] #include <boost/...> to #include "boost/..." transition?

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-20 09:03:23

----- Original Message -----
From: "Beman Dawes" <bdawes_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, July 20, 2002 9:30 AM
Subject: [boost] #include <boost/...> to #include "boost/..." transition?

> As has been discussed many times in the past, the C++ standard provides
> #include <...> for "headers" (which are only well-defined in the standard
> for the standard library), and #include "..." for "source files" (which
> includes the Boost header files).  See section 16.2.
>
> For historical reasons relating to problem compilers, Boost code has
always
> used <boost/...> instead of "boost/...", and thus relies on
> implementation-defined behavior (16.2/2).
>
> The historical reasons no longer apply.  Should we being to transition
> Boost code to the more correct #include "boost/..." form?

I guess I really don't understand the issues here. Other libraries I know
about that get installed in central locations on users' systems use <> by
convention as well. For example,
http://www.python.org/dev/doc/devel/ext/simpleExample.html says:

The first line of our file can be:

    #include <Python.h>

What really determines whether a library header file is a "header" or a
"source file"?

What about other things outside the standard like threading support? Is it

    #include <pthreads.h>

or

    #include "pthreads.h"

?

I realize the standard has ideas about which is which, but existing
practice may be more-important than what the standard says in this case.

> My personal feeling is that, yes, we should begin a gradual transition.
New
> code should begin to use the  #include "boost/..." form. Existing code
> should be modified over time, particularly when other changes are being
> made that will force recompilation anyhow.
>
> Comments?

Making a gradual transition  might not be that simple. Toolset support (and
I don't mean Boost.Build, but the underlying toolsets here) for specifying
different search paths for "" and <> is inconsistent. Some of those
toolsets force you to make those paths completely separate; some don't
separate them at all. You can't always move something from <> to "" and
expect it to get picked up. Certainly we are currently using <sysinclude>
in Jamfiles to force (where possible) files to be found in the <> paths.
I've tried, as much as possible, to make the Boost.Build toolsets behave so
that "" searches <include> followed by <sysinclude>, while <> searches only
<sysinclude>, but as I've said underlying toolset support is inconsistent,
so it wasn't always possible.

-Dave