RE: [boost] Form of inclusion directive

From: Gary Powell (Gary.Powell_at_[hidden])
Date: 2000-11-01 13:00:25

> Currently, when a boost files includes a boost header, it generally makes
> the reference via a directive of the form #include <boost/header.hpp>.
I got slammed by Bjarne S. for using "<>" on non system
include files.
We should be using
#include "boost/header.hpp"

And in fact I'd prefer that major libraries were in
boost/subdirectories.
boost/gccl
boost/utilities
boost/python

With each of these libraries having a subdirectory "details"
where files not part of the interface are placed. Then a user
mucking about can see what is the code interface vs what
is an implementation detail.

It's more work to type, but easier to maintain.

> I propose that instead we use directives of the form #include
> "header.hpp".
> 
> The downside of this directive form would be if it caused the wrong file
> to
> get included
> 
> Can anyone think of a reason to be
> concerned that an implementation might not do this?
> 
The biggest disadvantage is we reserve names from the
include directories in projects we don't own. This is
not a good idea. I'm sorry to be harsh about this, but
from long experience merging external libraries into my
projects, the more you can keep the external libraries
separate the better. 

By keeping everything in "boost" users of the project know
where the original source came from, and know who to complain
to about bugs. (Or alternatively are encouraged to go look it
up and discover a new community to which they also
contribute new stuff to.)

By having all "boost" files in one directory we encourage
users to continue this, which means that when they upgrade
to a new version of the library, its a drop in, not a sort
through. Otherwise mid project you won't upgrade.

Also the subdirectory of boost also allows a partial upgrade,
new python code, same graph library code. You can chose to take
upgrades at your leisure.

  -gary-

gary.powell_at_[hidden]