On Tue, Sep 27, 2016 at 12:26 PM, Vladimir Prus <vladimir.prus@gmail.com> 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