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

Subject: Re: [Boost-build] The future of B2?
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-09-28 08:11:12

Am 28.09.2016 um 13:41 schrieb PJB:
> 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_at_[hidden] 
> <mailto:ddevienne_at_[hidden]>> 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.
>
I don't think so. From my experience there are a lot of applications 
that are not supported by an IDE, really. That is, if you go into 
embedded development you either have a very narrow project config (e.g. 
eclipse makefiles) or you don't have any whatsoever. I've seen companies 
writing only custom makefiles for their code and I think that is what 
happens when you get to do something (or have a tool) that is not 
supported by the IDE.

> 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.
I think the place to start is to write a solid build system - 
boost.build has nice features, but I don't think it's as solid as it 
needs to be; there are a lot of workarounds needed etc. If we have a 
clear system, I can easily imagine, that it outputs all targets 
including configuration so the IDE can interact with it.
As for other build systems and IDEs - I think your wrong in assuming, 
that the IDE does anything different. Visual Studio uses MSBuild as 
build system, QtCreator QMake or Qbs, CLion Cmake, Eclipse supports ANT 
(I think). That is you can "just click build" but you have a build 
system beneath which you can also configure manually.
I think the way to go is to build a build system for all the console 
guys and have a good enough syntax & logic so it can later on be 
integrated into an IDE, such as Visual Studio. I think visual studio has 
started to allow makefile projects, so there might be some 
possibilities, but this will be a long way.

The problem with boost.build is: it does it's job, but it is hard to use 
outside of boost (especially the setup) and his has basically NO 
IDE/Editor support. But I think, if we had a boost-build3 which would 
not have those limitations but the concepts of bb and would provide a 
way for an IDE to know what the major targets and there properties will 
be, we might be able to make it more widely used and provide IDE (e.g. 
eclipse) plugins and even get one for Visual Studio. But it would be the 
second step; the first would be to get a more solid build system.