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

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 
<conditional>s?

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.

-Matt

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.