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:40:21

On Tue, Sep 27, 2016 at 12:26 PM, Vladimir Prus <vladimir.prus_at_[hidden]>
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.

Check.

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.
>

Why would that make you biased? Only makes you honest :-) And I agree,
partially.. IMO Jam servers reasonably well for the project specification.
It's simple and direct. But that's about as good as it gets.. Implementing
the build system itself in Jam was expedient at the time. But man is it a
PITA even with all the extensions we've done to it.

> Absolutely nobody know it, and anything not natively supported by the
> language requires code in C, with awkward bridging.
>

I think the C engine implementation is also holding us back. Each time I
start looking at the engine it takes me roughly a week to get enough
knowledge back to understand enough to then do something.  There are
various ways to slice the system and choosing what each slice is written in
will require some discussion.

Also, it might sound bizarre, but some aspects of Boost C++ Libraries
> project are problematic. Say, Boost.Python library supports building with
> Visual Studio from Cygwin shell using who-knows-what Python library. It's
> hard to understand and to test, and very few people need
> this funcitonality.
>

Indeed. But it is what it is. And all we can hope for is to find ways to
make domain experts figure out how something needs to be configured is
something we need to keep in mind moving forward. We know a heck of a lot
more about the varied use cases now than when v2 was designed.. And
certainly v1 was barely a start in this area.

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