Boost logo

Boost-Build :

Subject: Re: [Boost-build] [future] Implementation language(s)..
From: Chambers, Matthew (matt.chambers42_at_[hidden])
Date: 2016-10-18 13:53:37

Aaron, could you send us a sample of your YAML/JSON target declarations? Does it support defining the rules that are referenced by

I'm concerned that we are discussing the implementation language without firming up the requirements of the downstream components, e.g. IDE
integration. If we have a better idea how we want IDE integration to be possible, that may influence our choice(s) of implementation
language. I develop with VS as a code editor, but I don't see an obvious way to leverage the power of B2's declarative DSL files from the
GUI. Does a VS solution or project file act as an alternative to Jam/YAML/JSON? If so, how will it take advantage of B2's declarative
approach in a way that makes it preferable to just using the IDE's built-in build system. If not, then the user still has to write
Jam/YAML/JSON by hand, right? I can see IDE integration being very useful for seamlessly debugging the build system, though.

I share Vladimir's concern about needing to leverage the existing code due to the lack of available contributors to the core build engine.


On 10/18/2016 11:21 AM, aaron_at_[hidden] wrote:
> I think I can agree with most of the language choices here.
> A few thoughts:
> Project Descriptions:
> I do agree that Jam is much easier for declaring targets. As an avid user of the Python port, I have toyed around with different ways of
> declaring targets. The most obvious way was to skip Jam and declare all targets in a Python script. With the current API, this was fairly
> tedious having to put quotes around all target names, brackets around lists, etc. Since we declare the same types of targets over and over
> here, as an experiment, I ended up bypassing the Jam code altogether and read the target declarations from a YAML/XML/JSON file. This
> actually worked fairly well (albeit, the YAML/JSON looked weird with <feature>value requirements). As I think has been mentioned before, I
> think whatever is done for target declarations, the logic should be far removed from (or maybe not even allowed with) the declarations. If
> Jam is still used, will rule calls still be allowed? If so, I think Steven's debugger will definitely be necessary. Perhaps data formats
> such as YAML/XML/JSON could be explored since they don't allow logic. This kind of supports Stefan's concern with having more than two
> languages in that a data format is not technically a new language.
> Extensions and Build System:
> As an avid user of B2's Python port, I think one of the most important things to the port's success within our company was having a strong
> debugger. For this phase of the build, I think this should still hold true. I spent only a minute or so searching both Lua and ChaiScript.
> It looks like Lua has support for debuggers and ChaiScript does not. So, I would argue against ChaiScript at this point for that reason.
> Additionally, having a strong standard library is valuable: it means there is less need for additional 3rd party dependencies.

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