Subject: Re: [boost] RFC: Separating Boost.Python from Boost
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-05-30 13:41:47
On 5/30/15 2:43 AM, Bjorn Reese wrote:
> On 05/30/2015 05:11 AM, Robert Ramey wrote:
>> So you could build boost python with having the upper level bjam files.
>> Why would anyone want to use this? and for what?
> 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.
I had thought the the procedure for testing a new/proposed library would be:
a) clone the whole of boost on one's local machine
b) build b2 according to the "bootstrap" instructions
c) paste in my new/proposed library
d) run b2 headers
d) build all the libraries according to the "Getting Started"
instructions. This might not build my pasted in library which is fine
e) cd to mylibrary/test and run b2 toolset=... etc (or in my case run
Then one should have one's library built and tested.
Hmm I admit I haven't actually done exactly this. It just never occurred
to me that it wouldn't work. Can I assume that works or not?
In addition, I would expect that if I go to boost root and run b2 it
would build my new library as well. That is I would hope/assume that
b2 would build all the libraries in the lib subdirectory rather than
depending on some magic list inside of the the jamfile at the root. I
know I could investigate it on my own, but it's easier just to ask here
while making my point that this is the way it "should" work.
So in my world, the procededure is past in my new library, re-run b2
headers, and run the library tests - which build the library if
necessary. That seems very reasonable, understandable and easily doable
if it's not setup like that already. We absolutely have to have such a
facility to support the review process.
Finally, I would like to support the idea that a prospective library
could just support CMake. In this case the lack of a Build directory in
the library would mean that the global b2 ignores it. The CMake could
be run from the local library directory. There would be some other
issues but we'll leave that for another time.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk