Niall Douglas wrote:
On 30 May 2015 at 11:43, Bjorn Reese wrote:
I do not know why anyone want to do that for Boost.Python, but this problem is of a general nature.
Every author of a new Boost library has to go through the "birth-pain" of getting their library to build with Boost.Build while it is not part of monolithic Boost yet.
Currently, the easiest way is to checkout the Boost codebase and then copy your library in there. A more involved alternative is to cheat Boost.Build into believing that your library is part of the Boost code base by adding lots of symbolic links all around. Neither solution is feasible if you want other projects to use your library.
I'm a bit surprised you say this. AFIO requires exactly one symlink into libs/. Modular Boost takes care of all the rest if your Boost library has the right directory structure.
Suppose you have Boost in C:\boost-1.58.0, and your proposed Boost.Pumpkin is in C:\projects\pumpkin. If you symlink C:\boost-1.58.0\libs\pumpkin to C:\projects\pumpkin, you'll be able to do this: C:\boost-1.58.0\libs\pumpkin\test>b2 and it will run the tests. But what I think Bjorn wants is this: C:\projects\pumpkin\test>b2 This presumably would involve a Jamroot either at C:\projects\pumpkin or at C:\projects that would point to C:\boost-1.58.0.
On Windows, enabling normal users to create symlinks also gets rid of any weird build failure problems. Or you simply copy afio into libs/afio and be done with it.
For directories, you can use junctions on Windows, mklink/j.