Subject: Re: [boost] RFC: Separating Boost.Python from Boost
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-05-29 15:24:41
On 5/29/15 11:12 AM, Stefan Seefeld wrote:
> On 29/05/15 02:04 PM, Robert Ramey wrote:
>> On 5/29/15 9:31 AM, Stefan Seefeld wrote:
> As I mentioned, all I want is being able to build and release
> Boost.Python independently. No changes to the (C++) code are involved to
> achieve this.
>> How would you plan to do this? A fork of Boost.Python, or
>> unilaterally make changes in the current version of Boost.Python?
> I'm already experimenting on a fork
> (https://github.com/stefanseefeld/boost.python/tree/standalone). I'm
> proposing to push those changes (once stable) to the official
> Boost.Python. (Not sure what you mean by "unilaterally". The very reason
> I'm bringing
OK - I've looked at the fork and see what you want to do and I still
have a few questions;
a) I perused the python library source code and it includes only couple
of boost header files. So it's not really dependent on the rest of
boost at all. Not a good or bad thing - just an observation.
b) I see that your proposal just involves changes in the jamfiles
eliminating dependencies on some other jamfiles. Actually I didn't even
realize that a libraries jamfiles actually depended upon the root. Now
that I realize this I see the logic of it. If you can do this I don't
see any downside to it. It doesn't conflict with anything else.
>All I'm suggesting is to build and release Boost.Python
> stand-alone, against an external Boost installation.
c) It seems to me that you wouldn't even need boost installed to do
this. Again not a good or bad thing.
>>> For avoidance of doubt: my intent is not to remove Boost.Python out of
>>> the Boost organization.
d) regardless of your intent, that decision to include or exclude
boost python in a "release" would be a separate question. I don't
think you could prevent any boost library from being included in the
>> Does this mean the ability to "release (distribute ?)
>> Boost.Python without waiting for a boost release?
Actually, this what we want to be able to do for all boost libraries.
See the related initiative proposed in the steering committee mailing
list. This has been proposed as a long term goal. But it seems (as
usual) that current events out flank long term plans.
While you're at it, Why not include CMake files so that the build/test
of Boost python be totally decoupled from from the boost build system.
I did this for the boost serialization library so in your world this
would look like the ability to deliver the latest master version of the
boost serialization library independently of the next release. In fact,
that is exactly what I recommend to users who have detected errors in a
couple of corner cases of the library which have since been fixed.
Basically, you should think bigger.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk