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

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: 
> http://lists.boost.org/mailman/listinfo.cgi/boost-build