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

Subject: Re: [Boost-build] The future of B2?
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2016-10-06 10:46:25

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.

My 2 cents,
Raffi