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-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 
"boost release"

>> Does this mean the ability to "release (distribute ?)
>> Boost.Python without waiting for a boost release?
>
> Yes.

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.

Robert Ramey