Re: [Boost-build] The future of B2?

Subject: Re: [Boost-build] The future of B2?
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2016-09-29 23:46:42

On Tue, Sep 27, 2016 at 12:53 PM, Chambers, Matthew <
matt.chambers42_at_[hidden]> wrote:

> First, thanks to all you fine folks who keep B2 going. It's not perfect,
> but I've never used a better build system for building cross-platform C++.
>
> On 9/27/2016 12:26 PM, Vladimir Prus wrote:
>>
>> On 27-Sep-16 3:32 AM, Rene Rivera wrote:
>>>
>>> * I want to be able to launch my IDE of choice and be able to build,
>>> debug, analyze, deploy, etc with b2 as my build system.. And to do that
>>> without the need to look at a command line.
>>> * I want to be able to use my IDE of choice to configure all aspects of
>>> my b2 based project with zero or minimal reading of documentation.. And
>>> especially zero reading of b2 code!
>>>
>>
>> These two goals are what I consider most important personally.
>>
> I agree that these are priorities but I like Rene's other suggestions too.
> But isn't the "IDE of choice" part going to make this an open-ended feature?

Yes. But that's OK. The idea when doing this is to evolve and refine what
it means to integrate to an IDE and what be needs to support to do that.

> In closed form we could probably specify some major IDEs to support and
> add new ones as they are contributed or they become more prevalent.

Right.

* I want all that to perform as expediently as possible when I hit the
>>> build (or whatever button) in my IDE.
>>>
>>> By no means is that the end of my possible wish list, but I'll stop
>>> there for the moment. But now for the really important part.. Do you
>>> agree that the above are features we should strive, and plan for? Do you
>>> have features that you think we should strive for in addition to, or
>>> instead of the above?
>>>
>>> And the really hard question.. What of the current b2 implementation,
>>> design, ecosystem, is getting in the way of reaching the above wishes?
>>> And if you dare.. What should we change to move forward?
>>>
>>
>> I am obviously biased; but I think the Jam language is holding us back.
>> Absolutely nobody know it, and anything not natively supported by the
>> language requires code in C, with awkward bridging.
>>
> Jam is obscure, but I've yet to see a better build system language. Are
> you proposing to get rid of all Jam code or just replace it in the backend
> with python?
>

I think the exact split is up for discussion.. We can start those
discussions soon enough though :-)

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail