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

Subject: Re: [Boost-build] [future] Implementation language(s)..
From: PJB (darthpjb_at_[hidden])
Date: 2016-10-18 10:52:17

​​
I would recommend using C++ and Python, exclusively, for everything.

Logically, C++ as the core development language is a sane standard - so I
won't over-explain what's already been said.

Now, I don't personally like Python - even with my opinion of it however,
I'd say it is a defacto standard for a scripting language - easy to learn,
easy to use, fully featured, and reliable.
bjam / DSL, or any other custom solution is a step backwards - it adds more
for a developer to learn, comes with complications beyond usage, arguments
regarding syntax, etc.
Python is easy to pick up for experienced developers, and a simple language
for non developers to edit.

In short,
C++ as a core means speed and reliability.
Python as an extension means the User-facing component is reliable and
simple.

If the user needs to parse XML files to generate build targets, Python
allows that to be implemented and keeps such clutter away from the core
build system.
Further, as many have asked for IDE integration, such integration can be
written by users familiar with the IDE as extensions in python - meaning
that more collaborative effort can be done without needing to be a robust
expert in the Build-systems core development.

I agree with Stefan in that we should avoid the nightmare of "supporting
more than one language" - with a small caveat. One I think should be
discussed here.

It's my opinion that the future boost-build should have a C++-API, such
that with minimal inclusion of a header, a C++ plugin can be presented with
access to the equivalent functionality of the python-bindings - This would
allow for *vastly* more powerful extensions to be created leveraging
inter-process communication as well as integration into other mediums.
Examples of such exposure would be direct-communication with webservers,
IDEs, and other build systems. (Imagine a Apache-plugin that provided
real-time build-status for large projects for example). On windows
especially this would allow tight-integration with Visual-Studio via
.Net/COM.

On 18 October 2016 at 15:31, Stefan Seefeld <stefan_at_[hidden]> wrote:

> On 18.10.2016 10:28, Klemens Morgenstern wrote:
> > 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.
>
> I'd caution against that. A build system consisting of plugins written
> in many different languages is just begging for trouble for maintenance.
>
>         Stefan
>
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost-build
>