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
> * 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
> 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
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