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
>> on Wed May 09 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com>
>>> 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
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
>>> 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
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
>> - 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
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk