As a long term user of boost and C++ developer in industry - I feel like I should offer my two cents.

Most corporate application development does not occur under Unix/Linux - even when developing for Mac or Linux, most software houses using C++ use Visual-Studio to write code then make appropriate changes to run under a 'Nix system.
This is relevant - as the perspective of how a tool "should" work to a low level developer is dramatically different - Espeically given most younger-developers today spent their youth writing javascript/php/C#/or Visual Basic.

The 'Nix developer coming to windows is often confused about how to "use the toolchain", I've often heard such lines as "Windows developers seem to Jerry rig something", in the Inverse scenario of a Windows developer moving to 'Nix, the very idea of a makefile is alien, surely you just need to "press build". Using command-line invocation directly to the windows user appears to be backward.

This is unfortunately very great in impact when it comes to boost-build.

As a developer versed in windows and unix development for many years, using the command line to compile was second nature to me - and while I had difficulty finding the correct options to simply use b2 to compile boost itself, doing so took me only a few hours.

As a developer working with other windows-based C++ developers, I've often found myself having to explain the principals of how to complete such a simple operation repeatedly (to the point of distributing our own in-house documentation).

On 28 September 2016 at 09:19, Dominique Devienne <ddevienne@gmail.com> wrote:

It's not clear to me whether Rene's and your point is about using b2 *within* the IDE,

or using b2 to generate a b2-independent IDE-specific project/config. Or a mix, like CMake.

​This comment (without any insult intended) is a clear example of this disconnect.

The windows developer expects to open Visual Studio, click "Create new Boost-Build project"​, then click "Build", or "Run With Debugging" and said project "just-work", third party tools like Marmalade, Xanmarin, and others provide this functionality out of the box.
There is no need to write a make-file, or comprehend where in visual-studio the toolchain settings are.

​Please do not misunderstand, I do not wish to undermine any of the great work in Boost-Build, or the developers working therein, however the modern Windows programming environment has a ​de facto standard that boost does not meet, indeed, is very far from meeting currently.

Indeed, it is this reason why my company does not use boost-build, rather opting for writing our own makefiles instead (mostly due to the unfamiliarity of our developers with makefiles and command line compiling).


I wish I could propose some mechanism though which this issue could be solved - however doing so is beyond my comprehension of Boost-Build's internal mechanics, what I can enforce however is a the simple requirement of working with Visual-Studio as naturally as possible.