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

Subject: Re: [boost] RFC: Separating Boost.Python from Boost
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2015-05-29 18:38:59

On 29/05/15 06:32 PM, Andrey Semashev wrote:
> On Friday 29 May 2015 18:08:26 Stefan Seefeld wrote:
>> On 29/05/15 06:03 PM, Rob Stewart wrote:
>>> If your changes have the effect of removing Boost.Python from Boost
>>> releases, then they have broader implications than the convenience or
>>> wishes of the maintainers.
>> Sure, I didn't say they don't have implications for anyone. (I wouldn't
>> have started the discussion if they hadn't.)
>> However, only the people doing the actual work can chose where they put
>> their effort. So you shouldn't discount them when talking about
>> decisions to be made (or not).
> Although I agree with you that it is the library maintainers who choose where 
> to put their effort, I would still like to ask you to provide means of 
> distributing your library as part of monolithic Boost (as long as it is the 
> current distribution model). That includes supporting distributing and 
> building/testing your library as a part of the Boost tree, as well as probably 
> communicating with the release managers in case if their release/docs building 
> scripts need updating. You have to understand that not everyone is going to 
> switch to the modularized distribution model right away, especially since it 
> is only Boost.Python that gets modularized for now. Ideally, I would suggest 
> making the "standalone" build scripts more or less separate, without affecting 
> the current integration into Boost infrastructure.

That's a fair concern, and my initial plans were indeed to support both,
and in-tree as well as a stand-alone build. I'll see how hard this is to
achieve.

> If your plan is to remove support for building your library as a part of 
> monolithic Boost then, at this point, this would basically mean removing the 
> library from Boost distribution. I'm sure this would be a painful change for 
> users, so forking the library may be more preferable in this case.

Right, understood. The problem I expect is that, as long as both modes
are enabled, nothing will ever change, so a little bit of coercion is a
Good Thing. ;-)

The ultimate goal I have is for Boost to become an umbrella organization
of individual projects (typically one per library), which all prepare
their releases independently and autonomously. Some common
infrastructure would allow to validate their inter-operability, and thus
make it easier to establish a "boost distribution", where users can
choose the components from they really need.

Of course that's not a decision I (or anyone else for that matter) can
take on alone. It's something to enable in each individual library,
though, and eventually to agree upon as a community.

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...