Re: [boost] experimental boost-1.34.0 rpms

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-01-26 10:54:19

Stefan Seefeld wrote:
> Jeff Garland wrote:
>> Stefan Seefeld wrote:
>>> Pedro Lamarão wrote:
>>>> Stefan Seefeld escreveu:
>>>>> Benjamin Kosnik wrote:
>>>>>>> Has any thought been put into releasing multiple split boost packages
>>>>>>> containing orthogonal functionality (boost.python, boost.wave, boost.serialization,
>>>>>>> etc.) ?
>>>>>> Some. There are some intra-dependencies, and the split would add more 
>>>>>> complications to an already too-complicated build process IMHO.
>>>>> Ah well. Unfortunately not everybody agrees that boost is not modular enough.
>>>> I've seen this discussion before, and never saw any proof of concept for 
>>>> this modular release approach.
>>> I'm not sure what you mean by 'proof of concept'. Use cases I have in mind
>>> include:
>>>
>>> * The ability to install individual components.
>>> * The ability to build a dependent component such that prerequisite components
>>>   may be preinstalled or part of the same tree (say, on my FC6 laptop, I have
>>>   'boost.core' and 'boost.graph' rpms installed, and want to compile 'boost.python'
>>>   from mainline).
>>> * The ability to run test suites for components, with all prerequisite components
>>>   already installed.
>>>
>>>
>>> I believe that having support for the above would make life for (almost)
>>> everyone much easier, since components could be developed, built, tested, and
>>> released (oh, and used ! :-) ) more independently.
>> There's all sorts of things that have already, and can be done.  Everyone that 
>> wants a smaller boost can use bcp: http://www.boost.org/tools/bcp/bcp.html.
> 
> The danger here is to let users (and individual packagers) decide where to draw
> the line(s). As a result, package layout differs between platforms / distributions,
> making life hard for users. I think there is great value in boost.org providing
> guidlines about how to split, so users get the same, no matter whether they
> install from source, binary packages, or whatever.

Personally, I think the ubuntu split makes sense.  Tools, docs in their own 
packages.  Each library with an actual lib on it's own.  The base headers on 
their own.  But setting a standard like this requires an enormous amount of 
effort.  Someone has to write it up in detail.  Then they have to get 
agreement.  As with most OSS projects we run on volunteer labor around here, 
but if you're volunteering ;-)

> (Example: I'm developing an application using some boost components, and I want
> it to be portable, using make / autotools if available. What should I check for ?
> Even among GNU/Linux distributions this may vary wildly !)

Sure, I agree, it's not totally automated.

Actually, now that I'm thinking about it isn't there another rpm setup in the 
source tree somewhere contributed by Dan Marsden or someone?

>> bjam can already run tests for individual libs as desired.
> 
> But can it run test on one component that is being built against preinstalled
> prerequisite components ? I still need a full source tree, no ?

Yes.

> And, it's not as easy as it could, so users refrain from doing it, so boost.org
> doesn't get as much help as it could.
 >
>> On other Linux systems boost is already 'split up'. On my ubuntu system Boost 
>>   has components for each 'built library', tools, docs, etc.  Here's the 
>> relevant output of 'apt-get search boost'
> 
> Right, but as this split isn't christened by boost.org, other distros will
> most likely reinvent their own way. RH / FC packages right now aren't split,
> which is the point of my original reply.

Well, again we'd need some sort of project / process to approve the layout. 
For that we'd need a concrete proposal, for which someone would need to do the 
work.

Sorry to be a bit skeptical here, but given that we can't even get 1.34 done 
it seems hard to imagine we have time to worry about packaging.

Jeff