Re: [boost] CORBA iimplementation for Boost interest?

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2008-04-04 11:35:41

Jeff Garland wrote:
> On Fri, Apr 4, 2008 at 8:03 AM, Stefan Seefeld <seefeld_at_[hidden]> wrote:
> 
>> Stefano Delli Ponti wrote:
>>
>> Yes, understood. However, there is much more effort going into a project
>> than development. What about maintenance (adapting to new compilers,
>> say), compiling all the new code and running all the new regression
>> tests that such a project would surely add ? This impacts the whole
>> boost project. (Again, with a modular boost where components would be
>> built / tested / released all this would be mood.)
>>
> 
> I don't see why this project is any different than any other boost library
> project.

Right, it isn't.

> It adds one more library to an aleady large collection.  I suspect
> the only way to solve this problem would be to move toward a 'pull as you
> need it' solution (more like cpan) where there's a core boost install and
> then an easy way to get the other libriaries one at a time or in batches.

Yes.

> But we still have to test them, etc.  And it's still important for us to
> have major releases because there's some folks that simply won't look at
> libraries that aren't part of a major release.

So what ? If I wouldn't look at a library just because it isn't part of 
the 'core' release, it might just be because I have no need for it. 
What's the deal ?

>> Also, as boost right now is released as a single entity, another concern
>> is the perception from users. Boost already is huge.
>> The boost developers not actively supporting modularization or even
>> simple (platform-neutral) packaging really doesn't help.
>>
> 
> I'm not sure how we "aren't supporting" modularization.  Boost actually is
> quite modular -- you can use bcp to snip out subparts for your needs -- or
> do it by hand.  I've certainly done it -- "rm -rf" is a handy tool for the
> parts I don't need.

Yeah, I have heard that argument a lot, and I have to admit that I think 
it's a phony one.
Sure, "I can use bcp", if I'm willing to compile and package boost 
myself. What if I'm an end user of another program that happens to 
depend on some boost component ? In that case, I need to pull in boost 
as a prerequisite for the software I'm interested in, and I don't care 
how boost got built in the first place. All I see is a huge package.

And, again, there is this development / maintenance overhead. The other 
night I was considering offering to become a tester for x86-64 / Linux / 
GCC 4.3. But as there (apparently) is no way to offer compiling / 
testing for individual components, you just push the barrier of entry 
higher with each addition to boost, as the testing cycle becomes ever 
more resource intensive.
Why is this so hard to understand ?

>> Again, would boost not be a single entity, all these arguments would be
>> void.
>>
> 
> I'm all for alternative releases, modularization, etc but I think we still
> need a simple way to get the whole enchilada at once.

I don't understand the issue. Once you have modularized your enchilada, 
you are free to release the whole thing in a batch, if you so choose, 
but users can still pick whatever component they really need (plus their 
prerequisites, obviously).

Regards,
                Stefan

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