Re: [boost] [Modularization] A new approach to header modularization

Subject: Re: [boost] [Modularization] A new approach to header modularization
From: Beman Dawes (bdawes_at_[hidden])
Date: 2009-05-28 17:06:42

On Thu, May 28, 2009 at 10:53 AM, troy d. straszheim
<troy_at_[hidden]> wrote:
> In no particular order:
>
> - There is still the toplevel filesystem.hpp and friends to deal with.

The way to deal with that is to migrate those to within the library's
header directory.

As boost grows, filling the boost/ with headers becomes less and less
attractive. Of course we have to leave the current headers there for
compatibiltiy, but that location could be deprecated and eventually
only <boost/filesystem/filesystem.hpp> supported.

> You can't move libraries around as a unit (which is the desired
> capability, right?).

You can except for the current boost/ .hpp files. Whether that's a
problem or not depends on whether we are willing to move to all
headers in the library's home. That may well be an eventual need
regardless of the modularization approach.

> - You can't tell what headers don't belong to any 'project'.

Same as now. The headers in boost/ are a problem.

> - It is a lot harder to recursively search for function 'foo' in the
> headers; you're going to get hits from examples, tests, docs, etc.

The command gets a bit more complicated. But "a lot harder":-?

> - It makes it possible to include things you're not supposed to, e.g.
> private headers from other projects.

That's true already. If you know what the overall directory structure
is, you can always include files not meant for public use.

>  There is also the potential for name
> collisions between directories under libs/X and boost/X, You would want some
> naming convention:
>
> boost/
>  filesystem.hpp
>  filesystem/
>     O_o/         <----
>        build/
>        test/
>        doc/

Yes, you could do that. But we can also reserve certan names
(doc/src/test/example/build). That would go a long way.

>
> or maybe something pythonic like __src__/.
>
> - Users expect headers under include/ and source under src/, this will
> surprise them.

Yep. Just like it surprises them now that there is no include/.  They
get over it.

>
> - I'm not aware of any prior art.

Neither am I, except many years ago in some C projects I once worked on.

> - Will boost.build in fact be able to differentiate between headers, build
> products, and source files for the sake of installation?

Apparently.

>
> - I still like it more than svn:externals

The more I think about svn:externals, the more I think it is the wrong
tool for this particular job.

If there was a svn:hardlink, that would be a strong contender. Some
source control systems do support such functionality. I wonder how
hard it would be to add to Subversion?

--Beman