Re: [boost] Boost building with CMake

From: David Abrahams (dave_at_[hidden])
Date: 2007-05-10 15:16:12

on Thu May 10 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:

> "David Abrahams" <dave_at_[hidden]> wrote in message 
> news:87bqgsu7hn.fsf_at_grogan.peloton...
>>
>> on Wed May 09 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> 
>> wrote:
>>
>>> Let me add my 2 cents on the topic.
>>>
>>> 1. I believe CMake proponents are simply kidding
>>> themselves. Changing boost make system with all it's unique and
>>> complicated requirements to anything else would require up to half a
>>> year of extensive development. Even based on existing facility.
>>
>> Yeah, but someone else is volunteering to do the work, so the risk to
>> us is minimal.
>
> I've got an impression that this someone do not really understand what he is 
> getting into. 

That's his risk.

> Could anyone familiar with both BBv2 and CMake estimate amount of
> initilal efforts required? And most probably we will need ongoing
> support.

Probably.  I'd rather rely on a whole other open-source project with a
company behind it for support, than on one guy who has another job to
do.

>>> 2. I - as build system user - do not want to know ANYTHING about native
>>> build tools. I need single command that results in library compilation
>>> wherever I am on.
>>
>> Agreed.  How is that relevant to the CMake question?
>
> On cursory look on this discussion I've got an impression that CMake is 
> native makefile generation system. IOW I will need to
> 1. run some kind of script to generate makefile
> 2. run native make command
>
> This is unacceptable for me on both counts.
>
> If we decide to build wrapper around CMake, who is going to develop and 
> maintain it?

I don't have answerse for this one.

>>> 3. Do we (boost developers) really have any problems with BBv2?
>>
>> Yes, I do.  I started that project, so I have a vested interest in it.
>> Still, I'm just about ready to stop sinking any more time into it.
>> Just off the top of my head:
>>
>> - bjam appears to still be buggy
>
> In my personal expirience with BBv1, most of day to day activities
> worked fine. I never touched BBv2 yet.

By "bjam" I mean the executable build system driver.  You apparently
haven't seen the many, many posts from windows users having trouble
with inscrutable error messages each time bjam tries to launch a build
command.  I've forgotten the exact message, but AFAIK we keep tweaking
things but still don't have a handle on the problem.

>> - bjam consumes memory without bound (a design feature)
>
> Do you mean it leaks memory?

Sort of.  It stores every string permanently in a hash table, so
they're not exactly leaked, but the effect is similar for the user.

>> - the build process part of bjam is inscrutable even to experts
>
> Again. Couple times I had build bjam, I had no problems.

I'm talking about the 'C' code in the bjam sources that deals with the
dependency graph, etc.

>> - only one person understands how to work on the core of BBv2
>
> Ummm. How many do you think it should be? 

Ummm?  It was always supposed to be a multi-person project.  It
certainly is too big a project to be handled entirely by one person.

> How many peoples know details of most boost libraries
> implementation?

Irrelevant.  All of Boost depends on BBv2 and Volodya doesn't have
time to do all the work that needs to be done without making people
wait.

>> - the code is inscrutable and under-documented
>
> Which code you mean? 

The .jam code.

> My understanding is that we got application and scripts 
> around it.

??

> Does implementation of any of Boost libraries is documented?

Yes, several.  I mean, there are comments that will allow someone to
grasp what the code is doing, and they are reasonably complete and
free of ambiguity.

>
>> - that person is not writing documentation that would allow others to
>>  understand it
>
> I remember there were several people volontiring to help with with making 
> docs clear and "english friendly" ;)

Yeah, I was one of them.  Where did that lead?

>> - the language in which it is written is used in no other tool or
>>  project, thus presenting a barrier-to-entry for volunteers.
>> - that person can't handle the volume of feature requests, help
>>  requests, and bug reports he gets.
>> - there appear to be unresolvable philosophical differences about the
>>  design future of BBv2: http://tinyurl.com/34fqko
>
> All in all the problems you are descripbing are real, but they primarily 
> from development/support prospective, not usage.

Yes.  My biggest argument is that Boost is having a hard time bearing
the costs of this situation.

>>> If more docs are required, wouldn't it be easier to write them
>>> instead of wasting time jumping from one build system to another?
>>
>> Apparently only one person understands the system well enough to write
>> them, but he is unable to keep up with the pace of development.  I
>> think maybe you can relate to that predicament ;-)
>
> Oh. Yes. This one hits close to home. But I still think working on
> docs is easier and more realistic than all around switch to the
> different make system.

it doesn't matter that it's easier if nobody is going to actually do
it.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
Don't Miss BoostCon 2007! ==> http://www.boostcon.com