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

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 
else fails.
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.

Cheers
>
> 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
>     <https://github.com/grafikrobot/clion-boost-build
>     <https://github.com/grafikrobot/clion-boost-build>>.
>
>     -- 
>     -- 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:
>     http://lists.boost.org/mailman/listinfo.cgi/boost-build
>     <http://lists.boost.org/mailman/listinfo.cgi/boost-build>
>
>
>
>
> -- 
> Ryan
> [ERROR]: Your autotools build scripts are 200 lines longer than your 
> program. Something’s wrong.
> http://kirbyfan64.github.io/
>
>
> _______________________________________________
> 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