Re: [Boost-build] bjam 4.0.. in C++

Subject: Re: [Boost-build] bjam 4.0.. in C++
From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2010-06-14 14:38:12

On Sun, May 23, 2010 at 12:55 PM, Rene Rivera <grafikrobot_at_[hidden]> wrote:
> On 5/23/2010 1:00 AM, Spencer E. Olson wrote:
>>

[snip]

>> I have absolutely nothing against C++, I certainly prefer it over c, but
>> we've
>> found many difficulties compiling all of boost already.  If bjam went with
>> a c++
>> underneath, I would prefer it to be portable, allowing me to continue
>> using
>> Boost.Build even where Boost is not yet tractable.
>
> Hm, I also worry about the portability issue as you do. And it would be the
> one item that makes me rethink depending on Boost for bjam. But I do have
> one question for you.. Doesn't having something like GCC on each of those
> platforms mitigate the problem? I know it's not an ideal solution, but it's
> not unprecedented to require a "better" compiler for tools. Or to put it
> another way; Is GCC available in all the platforms you might have problems
> with?

I am all for rewriting bjam with boost libraries as dependencies.
The newer GCCs are *very* good at conformance.
Also, even if bjam4 can't work everywhere, and a bjam implemented in C
has also to be around, this is still *a lot* better. Because at least
we can have boost.build with very good performance on 90% of the
targets.
Also, how many times I've wanted to fix or modify something in bjam to
a few hours later just give up.
A C++ bjam using boost libraries will be much easier to extend.

>> 2.  Issue with Boost.Spirit

[snip]

>> Before worrying about portability issues, I had only one beef with Spirit:
>>  it
>> took forever to compile.  I ended up trying to isolate the parser in its
>> own
>> object code as much as possible (I had parsing happening all over the
>> place)
>> because it took so long.
>
> Having done some minor Spirit grammars (1.0 though) isolation would be
> something I would do. Another one would be to use the Spirit.Lex component
> to minimize the compile complexity of the grammar parser itself.

Please use spirit v2. It is a work of art.
And the compilation times can be mitigated with compilation firewalls.
Also, as Stefan has already mentioned. Separating the front-end from
the back-end could allow someone to write a front-end that didn't use
spirit v2 and would be more portable. But using spirit v2 will speed
your development *a lot*.
I rather have a C++ bjam working well first, and modular enough so we
can fix portability problems later.

[snip]

> --
> -- Grafik - Don't Assume Anything
> -- Redshift Software, Inc. - http://redshift-software.com
> -- rrivera/acm.org (msn) - grafik/redshift-software.com
> -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

Regards,
-- 
Felipe Magno de Almeida