Vladimir Prus wrote:
We probably can ignore doc builds for first step. But still, it appears there should be some way to mark a given library checkout as standalone, so that it does not depend on other parts of Boost checkout. But that's somewhat tricky -- in particular, that would mean that anything in top-levle Jamroot gets ignored, and any fixes or additions in tools/build/v2 will get ignored as well. And the same problem applies to CMake I believe -- since there's quite significant and growing set of local cmake definitions.
So, maybe, it's better to do it otherwise: don't allow a standalone checkout of a single library, but allow, given a full checkout of Boost, to redirect some, or all libraries to some installed locations. E.g.
--use-installed=python
or
--use-installed-except=serialization --install-root=/usr
which will cause build of serialization to use installed libraries.
Hm. Let's discuss. $our_projects = the libraries we're developing at the moment, say, serialization and mpi. $checkout = our development tree. Contains full boost. $install = an install of boost, say in /usr/local/boost/(lib|include) There is a buildsystem switch to enable the build in $checkout of only $our_projects. Headerfile paths: $our_projects would see e.g. the $install boost/version.hpp, and the $checkout serialization/export.hpp. For the --use-installed-except=... case, you could implement this without symlinks by simply deleting the non $our_projects headers from the $checkout when --use-installed-except is turned on, and putting $checkout/include first, $install/include second, in the include path. I think this may have certain advantages in practice... It is a little harder to get confused about which header files are the ones actually being used. For the --use-installed=... case, you'd need symlinks, you need to construct a 'forwarding' include/boost/<links>. But maybe you do anyway. (I'm not proposing any of this. Just thinking out loud.)
Then there is the 'middle' case: I have a 'big' boost tree sitting on disk, built, but not installed, and I want to hack on boost.process against that library. Are we having fun yet?
What problem is here? You just add libs/process and there you go. At least in Boost.Build land, you don't need to hack anything outside.
I meant putting the process checkout *outside* the build tree. Now I think this is a fake use case.... nevermind. -t