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
> - 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).
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk