Subject: Re: [Boost-build] [future] Implementation language(s)..
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2016-10-18 10:21:23
thanks for writing this up. I have been following the project for many
years, and watched (mostly just as a bystander) discussions about
reimplementations of bjam in C++ and Boost.Build in Python.
Reading this mail as an invitation for feedback, I'd like to add my
* There is a tradeoff between using a single language to express all
layers of the build system, and using multiple languages. You seem to be
suggesting three languages (C++, Python, Jam), which I find a little
unwieldy. I'd stick with two.
* In particular, while most people won't touch the very lowest levels of
the build system (the implementation of the dependency graph and
associated task scheduler), the higher level layers are not very well
separated. There is a blurry line between extending the build system
with new tools and build logic and defining how to build a new project.
Thus, I think from a usability perspective, it would be best if those
two could be served by a single language.
* I believe Python is an excellent choice both for extending as well as
project definition. (I disagree with you that it's not well suited as a
declarative DSL, i.e. to define projects in. It should be straight
forward to come up with such a DSL that still leaves room to extend with
"normal" Python in case users need to extend it.)
So, I think no-one is surprised that I'm a strong advocate for C++ /
Python as the languages of choice for the next-generation Boost.Build.
Add to that David's insight that with a tool such as Boost.Python it's
easy to incrementally shift the language boundary as you trade
development efficiency (productivity) against runtime efficiency
(performance), which is another quite convincing argument.
-- ...ich hab' noch einen Koffer in Berlin...
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