On Thu, Oct 6, 2016 at 5:03 PM, Chambers, Matthew <matt.chambers42@gmail.com> 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).

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