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

Subject: Re: [Boost-build] The future of B2?
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-09-27 14:48:06

On 9/27/2016 1:26 PM, Vladimir Prus wrote:
>
> Hi Rene,
>
> On 27-Sep-16 3:32 AM, Rene Rivera wrote:
>> Recently I've been doing some cmake, yes I said cmake, for work. And
>> this recent experience, and a quick survey of other current build
>> systems, has convinced me that there's still nothing like b2. And by
>> that I mean nothing that solves the same set of problems with a good set
>> of abstractions. Although there are one or two that are moving in our
>> direction. But alas, b2 is not widely used. And I can name many reasons
>> as to why that might be. But I'd rather discuss where I want b2 to be in
>> the future. And hopefully get us moving in a direction that will make b2
>> widely used.
>>
>> Let me start with something rather simple sounding.. What I want to be
>> able to do with b2 in my day to day work & play-work (note that this is
>> a royal "I" as I'm projecting what others have expressed over the years):
>>
>> * 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 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.
>
> 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.

I have made this point before so I hope you will forgive me from making 
it again. I think the main thing that is holding back better use of 
Boost Build is the fact that it is very difficult, if not impossible, 
for an end-user of Boost Build to understand how the final command line 
parameters are generated for a particular rule. In other words, given 
the plethora of ways in which options for a rule, such as 'compile' or 
'link', are specified, whether via a toolset, a project, a rule, or the 
command line itself ( did I miss anything ? ),  I think it is important 
for the end-user to understand how he can change things to add, 
subtract, or replace a given command line option for commands generated 
from a rule. Clearly merely adding some Boost Build feature to the 
command line does not always work as one suspects it should. Since the 
process for generating command lines for rules in a jam file is pretty 
complicated end-users of Boost Build become completely lost in trying to 
understand how to change the way Boost Build creates commands, and this 
means that Boost Build is much less "usable" then it could be.

>
> - Volodya