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@gmail.com> 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>.

--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

_______________________________________________
Unsubscribe & other changes: 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.


_______________________________________________
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