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.