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

Subject: Re: [Boost-build] [future] Implementation language(s)..
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-10-18 10:28:44

> == Extensions (ie toolsets, external lib config, etc.) ==
>
> I'm not going to include DSL/Jam in the choices here, because I think 
> we all agree that this is one of the key pain points in the current 
> design.
>
> * C++
> Pros: We all know it well; Excellent tool support; Performance; If 
> build system is in C++ would provide direct access to it; Likely 
> easier to integrate with project descriptions layer (if needed).
> Cons: Rarely built-in OS tools (but required for at least C++ projects 
> anyway); No common existing package distribution service.
>
I'd definitely support that, boost.dll could be used to import complex 
modules. Even though I'd like to see b3 support more than C++, I think 
it's fair to assume, that a user will have a C++ Compiler, so plugins 
maybe could be build on the fly.
> * Python
> Pros: Full language; Many built-in utilities; It's known to many; 
> There are many tools to support it; Built-in many OSs, easy to install 
> in others; Existing package distribution (pip); We can likely leverage 
> some of the b2 Python port code; Packages support both native C/C++ 
> and Python.
> Cons: Too big to embed (needs external install and linking); 
> Heavyweight run-time, and hence slower startups.
>
> * Lua
> Pros: Full language; It's known to many; Easy to embed (ie no external 
> install needed); Good tool support (syntax coloring in most editors); 
> Lightweight run-time, hence fast startups;
> Cons: Not well known in this group; Not a lot of built-in libraries; 
> No existing packaging system.
>
I would also add here, that I think there's another factor. If we have a 
class system, where you can overload operations like "update", I would 
expect a python user to actually implement that in python with "popen". 
Or at least that's what he would want to do. If you use a pure scripting 
language you'd have a design, where every operation is based on a 
function imported from C++.
I'd also like to throw ChaiScript into the ring, because the way I 
understand it, it is meant to only be a pure scripting language only 
using what you provide from C++. And it's small enough so that it could 
be forked for this project. But maybe Lua is sufficient here, too.
> First, if there are other languages you think we should consider 
> please speak up. Note, I've not included Haskel here, even though I 
> listed in the wiki. As I think, after some research, that it's not 
> worth seriously considering.
>
> Second, what I recommend.. Given the above what I'm thinking we should 
> do it is:
>
> Project Description: DSL/Jam. It's served well for this task before 
> and we know its characteristics.
> Extensions: Python. It's flexibility and packaging system would be ideal.
> Build System: C++.
> Runtime: C++.
>
I'd provide both C++ and Python extensions, otherwise I do agree. I'll 
see if I can come up wiht a way to build a plugin-system that may 
understand more than one language, but with one interface; if that works 
providing more than one language for extensions shouldn't be a problem 
at all.

> This essentially means that most of the system would be in C++. In 
> particular I would suggest that we write the "Build System" and lower 
> modules/components as a shared library that can be used from Python, 
> or any other language that has an FFI. That way we make it easier to 
> integrate into IDEs, thinking of them as front-ends to the build 
> system. Also one major advantage is that we can publish the entire 
> thing, ie with the CLI front-end, as a Python pip installable package.
>
>
> -- 
> -- Rene Rivera
> -- Grafik - Don't Assume Anything
> -- Robot Dreams - http://robot-dreams.net <http://robot-dreams.net/>
> -- rrivera/acm.org 
> <http://acm.org/> (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
>
>