Re: [Boost-build] [future] Implementation language(s)..

Subject: Re: [Boost-build] [future] Implementation language(s)..
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2016-10-25 11:20:39

On 25.10.2016 10:54, Klemens Morgenstern wrote:
> I'm sorry it this was ambiguous: I wouldn't use python for the core
> modules, but precisely for the small stuff. That is, if something like
> gcc or qt is a plugin, I would prefer that to be in C++, while your
> local solution should be in python.

Oh, sorry for my misunderstanding. I thought you were advocating for
supporting additional languages, which is what I'm strongly opposing. :-)

I think for a prototype of "boost.build 3" (for lack of a better name)
I'd like to see a pure-python implementation first, excluding the engine
itself, so scheduling is implemented in C++ right from the start. I
suppose the engine is quite stable, i.e. the internal representation of
dependency graph and task scheduling wouldn't change much from the
current implementation. What should change is the language in which
"boost.build" is written (and by extension, which "makefiles" /
"jamfiles" are written in). And by "language" I include both syntax and
semantics.
Syntax might be simply Python (we may think about a suitable subset of
the language that makes a good DSL for representing the declarative
aspects of a build system). Semantics is the hard part, and is where we
may want to preserve all the accumulated knowledge that went into
boost.build 2 (i.e., the current system), including the relationship
between projects and sub-projects, scoping of variables (build
attributes, features, etc.), and so forth.

Only once all that is carved out, should we look at performance, e.g. by
studying a heat map of a profiled build, to see what functions might
benefit most from a reimplementation in C++. David Abrahams has outlined
a good approach in
http://boostorg.github.io/python/doc/html/article.html#thinking-hybrid

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...