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

Subject: Re: [Boost-build] The future of B2?
From: Chambers, Matthew (matt.chambers42_at_[hidden])
Date: 2016-10-06 11:03:26

On 10/6/2016 9:46 AM, Raffi Enficiaud wrote:
> Le 04/10/16 à 01:27, Rene Rivera a écrit :
>> What matters to me is that a user be able to install b2 support for
>> their IDE and be able to interact with the IDE in then normal way to
>> build their projects. The specifics will vary depending on how
>> extensible the particular IDE is though. For example CLion is likely, I
>> say likely because their build system support is still in its infancy,
>> to support very tight integration. But for something like VS it might be
>> less tight. And VS might require that we support reading/importing the
>> VS project XML files. But most will likely require presenting a custom
>> UI to configure the b2 integration. But to answer your top question..
>>
>> I think that b2 needs to build *within* the IDE, with varied levels of
>> within. And not generate project files. As that's a flawed design that
>> leads to countless problems and limitations.
>
> Maybe I got it wrong ... but are you advocating using b2 inside the IDE?
>
> I really think the opposite way there, and I am ok with the choice made by cmake: as soon as you integrate into an IDE, you *should* talk 
> IDE language and let the IDE do what it can do.
>
> Hiding b2 inside the IDE is to me a much worse design. I believe (indirectly meaning "I am not sure") that this is done by cmake on rare 
> occasions when cmake cannot express some features with the functionalities offered by the IDE (basically creating .bat / .sh files called 
> by the IDE).
>
> This offers a bunch of features and integrations:
> - some VS plugins are using builds distributed on several machines (same for *nix userlands): it would mean that running b2 under the 
> carpet results in a loss of functionality
> - this is beneficial from the IDE competition perspective: all IDEs are actively working on their build backend just because this is 
> critical part for developers (and indirectly for the value of the IDE), and I would rather rely on them than to expect b2 to stay in close 
> competition in something like this (without certainly having the bandwidth).
> - the build itself is usually tightly coupled with the IDE. Running b2 instead of the native build system with result in a loss of 
> functionality.
> - same for the debugger: how would for instance the IDE understand that a project is of a specific type and run the appropriate debugger?
>
> (and many more bullets that I lost track of)
>
> 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).

-Matt