== 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
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail