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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk