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

Subject: Re: [Boost-build] [future] Implementation language(s)..
From: aaron_at_[hidden]
Date: 2016-10-18 12:21:32

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.
 
All Phases:
In both the Jam and Python side of B2, I think the biggest slow down is all of the string comparison that is being performed for properties. No matter what language is chosen, the underlying implementation of the relationships between properties and targets needs to be reconsidered.
 
I mostly agree with Rene's recommended approach. I'm somewhat on the fence about the suggestion to only use C++ for the Build System phase. Again, I really liked having access to the debugger during the metatarget and virtualtarget phase. Using Python for these two phases makes it much easier to see the internal choices being made (throwing in print statements or using the debugger). However, I am also concerned with speed, so I like the idea of C++ for that. The final solution needs to have rock-solid information dumping support whether that be a debugger/print statements with Python or simply better logging with C++.
 
Question:
Rene, you've mentioned that Python would have "slower startups" and that Lua would have "fast startups". Do you mean that the total runtime of the Extensions and Build System phases would be faster in Lua? Or that the initialization of the Lua interpreter itself is faster? Or Both? Just curious. I haven't ever compared the two before.
 
Just a view from our use of Boost.Build.
Aaron