Boost logo

Boost :

Subject: Re: [boost] [Modularization] A new approach to header modularization
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-05-28 11:42:13


troy d. straszheim wrote:

> In no particular order:
>
> - There is still the toplevel filesystem.hpp and friends to deal with.
> You can't move libraries around as a unit (which is the desired
> capability, right?).
>
> - You can't tell what headers don't belong to any 'project'.
>
> - 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.
>
> - It makes it possible to include things you're not supposed to, e.g.
> private headers from other projects. 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/
>
> or maybe something pythonic like __src__/.
>
> - Users expect headers under include/ and source under src/, this will
> surprise them.
>
> - I'm not aware of any prior art.
>
> - Will boost.build in fact be able to differentiate between headers,
> build products, and source files for the sake of installation?

Yes, of course. I don't see anything particular hard here. But I am also
concerned about this approach for other reasons you list above.

- Volodya


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk