troy d. straszheim wrote:
Vladimir Prus wrote:
troy d. straszheim wrote:
Vladimir Prus wrote:
FWIW, I expect Boost.Build mechanisms to be implemented shortly. However, to be fully sensible, it will require change of layout of libraries in SVN -- otherwise we'll end up in a situation currently with CMake -- where there's 'modularize' command which changes directory layout to be different from that in SVN -- which is not a good idea in general.
But we can easily agree on what that layout should look like, and switch both build systems simultaneously, right? Then we can do away with the 'modularize' business. Let's do it!
Hm, wait:
1. those who develop against checkouts of boost (not installed versions) will need to define just what boost components they need. It could get messy, but it has to be done.
I am sure that folks who use either boost.build or cmake can be provided an easy way to get all components and their includes. However, we have 91 libraries at present. Adding 91 includes path to command line seems like extremely bad idea -- it will overflow windows command line limit easily, and gcc only recently got response files support, so probably does not have it in mingw and cygwin.
I'm worried about the include paths too. Pondering modularization: It isn't clear to me that e.g. 'flyweight' and 'util' need to be entirely modularized. Maybe we could go coarser. But I'm not sure where I'm going with this.
Maybe we should review the goals of modularization? For me, its value is mostly that: 1. You can switch to a different version of a given library using single command. 2. It is possible to easily grab a subset of libraries.
I agree with these.... here's some specific cases:
- be able to play with proposed/sandbox projects without downloading a zip file from the vault (crucial -- special case of 1.).
- be able to assemble a boost piecemeal... say you need serialization and python.
That's subset of (2) above -- I think :-)
Maybe, we can still have single include directory while achieving the above goal if we make build process create symlinks to directories? That works on Linux, and I believe modern windows has some way to create links too. I am worried about other operating systems, though.
I share your worry. Probably some scm mechanism should take care of it. I'm out of ideas for the moment.
svn:externals in SVN allow you to have master copies of headers say in libs/thread/include and have a copy checked out into boost/thread while making commits in boost/thread work, and commit into the master copy. Disk requirements are a question, though.
3. We've said nothing about defining version-specific dependencies (boost.spirit v.X depends on boost.proto >= v.Y)
Do we even want to open this can of worms?
I'm not sure we do. Of course we are implicitly assembling these dependency graphs as we do releases. It may actually be possible to ferret out the details automatically by trawling through version control. A nice project for a saturday night...
There are different issues of: 1. Permitting to create Boost 1.Frankenstein release including random versions of all libraries, while somehow checking the requirements above. 2. Permitting to have different version of the same library in such combined package. Probably some of those can be good for like boost.serialization needing spirit 1.6 -- but I am not sure that use case is still very important, and whether we have any other similar. - Volodya