Boost logo

Boost :

Subject: Re: [boost] [Modularization] A new approach to header modularization
From: troy d. straszheim (troy_at_[hidden])
Date: 2009-05-28 10:53:18


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?

- I still like it more than svn:externals

-t


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