Boost logo

Boost-Build :

Subject: Re: [Boost-build] The future of B2?
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-10-06 11:38:07

Am 06.10.2016 um 17:22 schrieb Raffi Enficiaud:
> Le 06/10/16 à 17:03, Chambers, Matthew a écrit :
>> [snip]
>> 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 would go for a better use of the configuration manager in VS (debug,
> release, runtime-debug=off etc) obviously driven by b2. Then I can
> think of something like
> b2 runtime-debugging=on,off arch=x86,x64 ...
> or inside a file declaring the matrix of configurations.
> that would generate several configurations in VS directly. There
> should be something similar in Xcode and QtCreator.
> I suppose if VS exposed common C++ properties
I think you can have two solutions: either setting some properties
possible through the command line as you proposed or reflecting the
entire build settings in the IDE. The latter one would require a lot of
work, but you could write an Eclipse Plugin which does that. So I think
providing both as an interface would be the way to go.
Eclipse actually has similar things for Ant or Maven.
>> (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.
> This I think will be just painful, and this is why you also would like
> to use a tool like b2 or cmake to do this job for you. Most of the
> time, those configuration files are overkill in functionality and
> buried very deep so that this is hard to manage properly.
True, but would be an issue for the IDE. I'm currently using eclipse
sort of like that, in that I setup build variants with different calls
to b2.
> 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
> Well, maybe we cannot avoid being completely orthogonal to cmake. b2
> integrates its own build system (which cmake obviously does not) and
> in that sense makes the tool as a potential replacement for many
> things. But if the user choose to use an IDE, then again it honour
> this usage fully rather than faking :) .
I actually don't like the project-generate approach. But: if the project
itself (i.e. the content of the Jamfile) is a target we could provide
that functionality and one could write a module to implement the
specific project settings. I would however see this as a feature not as
the core functionality.
> Raffi
> _______________________________________________
> Unsubscribe & other changes:

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at