Subject: Re: [Boost-build] [future] Implementation language(s)..
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2016-10-25 12:59:57
On 25.10.2016 12:36, Paul A. Bristow wrote:
> I've been watching this conversation with interest (and am impressed by your enthusiasm).
> Before you go too far down the using Python route, may I be so bold as to ask if are you quite sure that you can't do the whole task
> in C++?
I'm sure it's possible (especially for some Boost enthusiast ;-) ) to
write an entire build system (including makefiles) in C++. But I'm also
sure that I don't want makefiles that are C++ source code. :-)
Unless of course you were thinking of using one of the Boost parsers
(spirit, proto, etc.) to define a new language to be used for makefiles,
which would put us back to square one, and which I'd be violently
opposed to (please no new language !!).
> Every extra tool and plugin adds complexity - and loses you users, some before they start, and potentially many more when it doesn't
> 'just work'.
I think you are making up a false dichotomy here: While "extra tool"
sounds intuitive, the question is what the real alternative to using
such extra tools would be. Please don't let the Not Invented Here
syndrome strike yet again.
> Do you *really, really* need Python? Are you quite sure that because that is your favorite tool, the task isn't a nail ;-) There
> are a lot more C++ (including Boost) tools for writing DSL languages than were available when bjam was conceived and created.
> Just asking...
It's a good question. I think a key point is what we mean by "DSL
languages". To what degree are we talking about an entirely new language
here (including new syntax an new semantics) ? I'm really opposed to
defining a new language (as would be necessary when using C++ only).
When I talk about an embedded DSL inside Python I'm talking about
something really minimal that can be picked up easily by anyone, which
still reuses most of the semantics of the "host" language.
-- ...ich hab' noch einen Koffer in Berlin...
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