Re: [boost] RFC: Separating Boost.Python from Boost

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 
library status...)

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.

Robert Ramey