On Thu, May 28, 2009 at 10:53 AM, troy d. straszheim <troy@resophonic.com> 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