Subject: Re: [Boost-build] [future] Implementation language(s)..
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-10-25 10:54:55
Am 25.10.2016 um 16:39 schrieb Stefan Seefeld:
> On 25.10.2016 10:30, Klemens Morgenstern wrote:
>> The reason I proposed that, is that I think it would have several
>> 1. small, local extensions, e.g. some project-specific code generator
>> 2. complete toolsets, i.e. plugins that should be shipped with the
>> build system
>> I'd prefer to have the first stuff in a small scripting language and
>> the second C++. I would not be mixing the langauges in the shipped
>> plugins (pure C++ there), but provide the scripting language for
>> user-extensions if you will.
>> If we only used python, we'd have a slow build system; if we'd only
>> used C++, the extensions would be painful for the users.
> Please demonstrate that Python for "small, local extensions" would yield
> a slow build system. I think we can worry about that when we run into
> that. Anything else is premature optimization.
> (And I honestly have had enough of projects that use cryptic ad-hoc
> languages that only the original implementers really understood. We
> really need to focus on productivity, i.e. the time it takes for *other*
> people to solve *their* problem with a given tool, which is clearly
> helped by using a *common* and *well-understood* language.)
I'm sorry it this was ambiguous: I wouldn't use python for the core
modules, but precisely for the small stuff. That is, if something like
gcc or qt is a plugin, I would prefer that to be in C++, while your
local solution should be in python.
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