Boost logo

Boost-Build :

Subject: Re: [Boost-build] B2 C++ engine development.
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2018-10-25 17:57:41

On Thu, Oct 25, 2018 at 12:55 PM Rene Rivera <grafikrobot_at_[hidden]> wrote:

> On Thu, Oct 25, 2018 at 12:41 PM Steven Watanabe via Boost-build <
> boost-build_at_[hidden]> wrote:
>> On 10/24/2018 09:58 PM, Rene Rivera via Boost-build wrote:
>> > One of my goals in the future of B2 is to move the engine to something
>> > easier to maintain and improve. As such it's my goal to incrementally
>> > rewrite the engine component of B2 in C++. Yesterday I completed an
>> initial
>> > step in that by having B2 compile as C++ instead of ANSI C. The code
>> > changes are in the "feature/cxx" branch and from outward appearances
>> it's
>> > exactly the same as before except that the build scripts now invoke the
>> C++
>> > compiler (only lightly tested for the compilers I have available). First
>> > con of this is that the executable is slightly fatter (about 20K on
>> OSX).
>> > But also the first pro, it's about 4% faster.
>> >
>> Any explanation for this? Are the build options
>> exactly the same other than -x c++? The code
>> changes don't look significant, so is it just
>> that the stricter rules of C++ allow the optimizer
>> more freedom? It looks like you're not linking
>> the C++ runtime (which was my first guess about
>> the binary size increase).
> I think the speedup is from the stricter type rules of C++, probably
> constness and aliasing. But it would take way more investigation and
> looking at assembly to truly figure that out. And I'm not going to bother
> doing that :-) I don't prevent linking of the C++ runtime. But since it's
> not used yet I suspect it's just linked away anyway. My suspicion for size
> increase would be of the slightly different optimization behavior. In that
> it might prefer slightly larger code that performs better in many small
> instances.
>> > The idea is to merge this to develop, and eventually master, and
>> continue
>> > the C++ work based from those (as PRs).
>> >
>> - Is there a reason that you eliminated the two stage
>> bootstrap process? Among other issues, you've made it
>> impossible to create a debug build of b2.
> I got tired of watching the double builds when it's just as easy to do it
> once. And I do intend to put in an option for a debug build (and the python
> build). Although technically you can still do it if you use the basic cxx
> toolset with CXX and CXXFLAGS. There's almost no benefit to having the
> build.jam as a large chunk of what it does is packaging. And we can do that
> many other ways that are less painful (like a python script). I.e. I'm
> trying to reduce complexity in the bootstrap building.
>> - While I support removing bjam, it's an entirely
>> separate change.
> I can easily add a copy in there again.
>> - Before this goes live, I'd like to see the files
>> renamed to *.cpp.
> Sure. I didn't want to rename things yet as I wanted to see the diffs
> clearly for verification.
>> - What language standard are we targeting? filesystem
>> is C++17.
> C++11. As much as I would like to use the latest and greatest using the
> latest means we would have to immediately move to binary distribution.
> Maybe in the future we can move further, once we figure out what aspects of
> newer C++ are essential.

PS. One of the first items to think about is writing a new bjam language
parser. It's about time we stop relying on bison/yacc + the tokenizer :-)

-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams -

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at