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