Boost-Build :

rymg19_at_[hidden]

--
Ryan (ãƒ©ã‚¤ã‚¢ãƒ³)
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Somethingâ€™s wrong.
http://kirbyfan64.github.io/
On Oct 18, 2016 8:59 AM, "Rene Rivera" <grafikrobot_at_[hidden]> wrote:
> Before we too far ahead of ourselves we have one particular decision to
> make.. What do we write the next Boost Build in? Starting with the rough
> modules.. It shows some possibilities:
> Project Descriptions DSL (i,e, Jam), Python, Lua
> Extensions C++, Python, Lua, Haskel
> Build System C++, Python, Lua, Haskel
> Target Graph C++
> Scheduler C++
> Executor C++
> And, of course, more than one answer is possible. I only listed the ones
> that seemed obvious to me. And the pros/cons are specific to each module.
> So going from top-to-bottom..
>
> == Project Descriptions ==
>
> * DSL/Jam
> Pros: It's known to devs and users; It's easy to script *small* tasks; We
> can fix & adjust warts as we see fit; It fits well the task of *declaring*
> build targets.
> Cons: It has all the warts we know about; Essentially no tool (ie
> IDE/editor) support.
>
> * 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.
> Cons: Not a good fit for declaring targets; Large temptation to put lots
> of logic at the project declaration layer; 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; Unknown if it would fit declaring
> targets.
>
> == 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.
>
> * 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.
>
> == Build System ==
>
> * C++
> Pros: We all know it well; Excellent tool support; Performance; 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 existing package distribution service.
>
> * 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.
>
> == Runtime ==
>
> Collecting all the rest of the modules into one runtime.
>
> * C++
> Pros: We all know it well; Excellent tool support; Performance; 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 existing package distribution service.
>
> * 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.
>
> 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++.
>
> 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
>
>
> --
> -- Rene Rivera
> -- Grafik - Don't Assume Anything
> -- Robot Dreams - http://robot-dreams.net
> -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost-build
>
>