Subject: Re: [Boost-build] B2 C++ engine development.
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2018-10-25 17:55:31
On Thu, Oct 25, 2018 at 12:41 PM Steven Watanabe via Boost-build <
> 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
> > 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
> > 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
> > 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.
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk