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