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
>>> 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
>>> * 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
>>> 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:
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk