Subject: Re: [Boost-build] The future of B2?
From: alainm (alain.miniussi_at_[hidden])
Date: 2016-09-27 04:32:33
On 27/09/2016 02:53, Ryan Gonzalez wrote:
> IMO, the main issue with Boost.Build is just lack of documentation.
> There's a reference manual, but it leaves out a lot of stuff (like
> auto-configuration) that's pretty much necessary to use it. The home
> page also lacks any kind of convincing examples.
> Also, a lot of companies looking into C++ build systems want
> blazing-fast speed. Unfortunately, b2 isn't necessarily the fastest
> build system (although CMake's make generator isn't, either).
> And the error messages. Oh lord, the error messages.
> TL;DR: after a brief visit to the home page, there's no obvious reason
> to use it, the reference manual doesn't have anything to put
> everything it mentions together, and the only experiment with b2 the
> user ever does results in a 10-second wait before an error traceback
> referring to obscure terminology that they don't understand.
> I'm not saying Boost.Build is bad. I love it. It's just that it
> doesn't leave the best first impression, and lots of people give up
> after the first try.
I didn't, I gave up after many month of pain an suffering, debugging and
a fix that ended up in the trashcan. My two last attempts ended up in a
hanging b2 (the answer I got the first time went along the lines of
"well, Intel should fix it's mpi engine to fit our completely unknown
tool.", is not that useful in the world I live in. Second time, having a
background script sending appropriate signal to the build process ended
up qualifying as a convenient solution, didn't bother reporting the issue).
CMake might be (well, is) a piece of junk, but it's a documented ,
supported and widespread piece of junk. And I'd probably use AutoTool
over b2 anyway. At least I have a failsafe on scripting when everything
Not to mention I do not work in a C++ only universe, and support for
Fortran and most third party tools seems to be kind of limited.
But yes, documentation would be a nice improvement to consider if world
domination is under consideration.
Performances is not such an issue when you have parallel build, although
CMake seems to have a faster startup time for me.
> On Mon, Sep 26, 2016 at 7:32 PM, Rene Rivera <grafikrobot_at_[hidden]
> <mailto:grafikrobot_at_[hidden]>> 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 choice of library package manager
> and be able to consume packages directly in b2.
> * I want to be able to use b2 to produce, i.e. specify, build, and
> deploy packages for my choice of package manager entirely in b2.
> * 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!
> * I want to be able to use current language features as soon as
> they are available, or shortly thereafter, without having to did
> into toolset command flags.
> * I want to be able to easily consume and produce b2 extensions..
> It should be possible for me to browse on-line a collection of
> extensions and directly use them in my project. It should be
> possible to write my own extension and publish it for others to use.
> * I want to be able to consult the documentation and quickly find
> an answer for what I need to do with steps to follow. Preferably
> needing to only read *one* screen full of information.
> * I want to be able to manage my poly-language projects uniformly
> with b2.
> And I'm putting this one last intentionally..
> * 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?
> PS. Feel free to educate me as to the state of the Python port,
> deamon support, and anything else I may (or may not) be cognizant
> of that may be relevant. For both my enlightenment and that of others.
> PPS. For context, this post was also precipitated by my attempt to
> implement some b2 integration for Conan <https://www.conan.io> and
> CLion integration
> -- Rene Rivera
> -- Grafik - Don't Assume Anything
> -- Robot Dreams - http://robot-dreams.net <http://robot-dreams.net/>
> -- rrivera/acm.org
> <http://acm.org/> (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
> Unsubscribe & other changes:
> [ERROR]: Your autotools build scripts are 200 lines longer than your
> program. Somethings wrong.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
-- Alain Miniussi Pole Génie Logiciel Scientifique Observatoire de la Côte d'Azur Blv de l'Observatoire, Nice
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