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

Subject: Re: [Boost-build] The future of B2?
From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2016-10-06 11:17:18

On Thu, Oct 6, 2016 at 5:03 PM, Chambers, Matthew <matt.chambers42_at_[hidden]
> wrote:

> I really believe that if b2 goes the way you advocate, it will de facto be
>> a bottleneck. I would rather suggest creating project files as artefacts
>> (instead of building exes and libs), and try to think hard on how to
>> integrate the b2 specifics to the IDEs.
>>
>> One core aspect of an IDE is about "presentation" of a project.
>> And for instance for meta-targets: a possible idea would be to have a
>> folder in a "solution", containing all the variations of a meta-target
>> instantiation. But then, how would you differentiate between those? Maybe a
>> naming convention can be adopted containing the name of the first consumer?
>> At this point I would say the added value of having an IDE would be not
>> negligible as it would show some backtrace and the number of times a
>> meta-target has been instantiated.
>>
> The point about the build being tightly coupled to the IDE is sensible. I
> also have trouble imagining using b2 effectively from within many IDEs. I
> use Visual Studio as a code editor but I can't stomach using it as a build
> system for C++ for anything serious. It's too painful to have to go into
> the project dialog to change build settings, or a priori come up with all
> the combinations of build configurations that I may want to use and make
> them into Project Configurations. If I want to build a debug build with
> runtime-debugging=off, that is a piece of cake with b2, but probably would
> require making a new project configuration or editing an existing config in
> VS. I suppose if VS exposed common C++ properties (link, runtime-link,
> runtime-debugging, debug-symbols, optimization, inlining,
> asynch-exceptions) as easily accessible checkboxes in the IDE, then I would
> find it a lot easier to use. I'm curious how Rene plans to overcome that
> without following the CMake route (which I'm not very fond of either, but I
> suppose if b2 could do what CMake does and make VC project files, that
> might be useful).
>

Since we're tangentially referencing VS and CMake, this is probably
relevant:
https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-support-in-visual-studio/

Stephen Kelly's daemon approach [1] is much closer to Klemens' JSON API
idea,
that my SQLlite-persistent-state one, and allows use cases not possible
with my
"pure data" proposal, like CMake-code completion. --DD

[1] https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/