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

Subject: Re: [Boost-build] The future of B2?
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-09-27 17:31:19

Am 27.09.2016 um 20:48 schrieb Edward Diener:
> 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.
>
I do agree. I use boost.build for my own projects, because the concepts 
are great and it's afaik the only build system that can do all that, 
i.e. meta-targets etc. Waht I would love to see is a b3, a solid build 
system-engine entirely plugin-based (be it in C++, Python or Chaiscript) 
completely written in C++ (we have boost.python, boost.dll and hopefully 
boost.process soon) which then is not limited to C/C++, but may be 
extended to support something like java via plugin.
I think if enough boost people are interested in that and are willing to 
spend there time on this, this could succeed. I've got a few ideas for 
that, so if enough people are interested (especially those maintaining 
b2) we could maybe come up with a solid concept.

Is there any interest in pursuing that? I really don't think CMake is 
the solution for this problem.
>>
>> - Volodya
>
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost-build