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

Subject: Re: [boost] RFC: Separating Boost.Python from Boost
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-05-30 14:15:42

On 5/30/2015 1:41 PM, Robert Ramey wrote:
> 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?

It works for me as far as my library's tests and doc, so I really don't 
understand anyone who think it does 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.

What do you mean by "build my new library as well" ? Are you positing 
that your theoretical library is a non-header only library ? In which 
case how does b2 know which jam file to execute to do that ?

>
> 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.