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

Subject: Re: [Boost-build] [future] Implementation language(s)..
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2016-10-25 12:36:44

> -----Original Message-----
> From: Stefan Seefeld [mailto:stefan_at_[hidden]]
> Sent: 25 October 2016 16:21
> To: boost-build_at_[hidden]
> Subject: Re: [Boost-build] [future] Implementation language(s)..
> 
> 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

I've been watching this conversation with interest (and am impressed by your enthusiasm).

Before you go too far down the using Python route, may I be so bold as to ask if are you quite sure that you can't do the whole task
in C++?

Every extra tool and plugin adds complexity - and loses you users, some before they start, and potentially many more when it doesn't
'just work'.

Do you *really, really* need Python?  Are you quite sure that because that is your favorite tool, the task isn't a nail ;-)  There
are a lot more C++ (including Boost) tools for writing DSL languages than were available when bjam was conceived and created.

Just asking...

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]