Re: [boost] [Ann] Boost and Google Summer of Code 2007

From: Bjørn Roald (bjorn_at_[hidden])
Date: 2007-03-04 17:55:12

Kevin Heifner wrote:
> Bjørn Roald wrote:
>   
>> Jeff Garland wrote:
>> MPC is nice and could be part of a solution if the requirements only 
>> where to produce IDE project and solution files from Jamfiles.  
>> Boost.Build and/or bjam could be extended to produce a <sub-project>.mpc 
>> file for each Jamfile and a <tool>.mpt file per tool(-set) used and then 
>> invoke mpc to generate the buildfiles.  This should be recursive for a 
>> full project source tree.
>>     
>
> We have thought about extending MPC to generate Jamfiles, but it 
> has never risen to the top of things to do.
>
>   
Understood.  I guess from the MPC perspective Boost.Build is just 
another build tool that need to be supported.  I do however not think 
.mpc files are likely to replace Jamfiles in boost as long as developers 
here are happy with bbv2.  So from the Boost perspective, MPC is a tool 
that could bring the boost build configurations into most IDEs.

>>> Someone of the folks at OCI previously put together a set of boost project 
>>> files.  Those are in the vault at:
>>>
>>> http://www.boost-consulting.com/vault/index.php?PHPSESSID=kk5srbfv8nefn8mhg7h7v8qan5&direction=0&order=&directory=Miscellaneous
>>>
>>>   
>>>       
>> These seems to be hand crafted.  Is that correct? In that case I do not 
>> think this is the way to go.
>>     
>
> Yes, these particular files were hand crafted.  One of the nice 
> things about MPC, however, is how easy it is to maintain the MPC 
> files.  Its inheritance feature of common base projects makes it 
> very easy to make project wide changes to a build system.  It is 
> also very nice that source files do not have to be listed 
> explicitly.  To add a new file to a project is just a matter of 
> running MPC, no modification to the build files are needed.
>
>   
I was not aware of this.  Is this similar to file-set feature in Ant.  I 
guess you soon need some 'exclude' feature to support ignoring specific 
files.

>>> Note, I haven't tried the Boost files, but I've used MPC on cross-platform 
>>> projects -- it's a nifty solution.
>>>       
>
> On behalf of Chad Elliott, Justin Michel, and OCI, Thanks.
>
>   
>> Agree, Many developers prefer their native IDE project- , build-, and 
>> debug-management .  The challenges do however soon become clear.  Sooner 
>> or later changes to the native build files must go back to the .mpc or 
>> jam files.  That becomes annoying, error prone, or outright neglected.
>>     
>
> There are many reasons to prefer the native IDEs build/debug 
> systems.  One goal of MPC is to allow each developer to choose 
> what they want to use.  On the same project one developer can use 
> Visual Studio 7.1 another 8 another NMake another gmake on Linux etc.
>
>   
That is nice, the question is if it is needed.   Boost need support for 
compilers, not make tools.  Hence Boost.Build has focus compiler 
support, not build tool support.  It is a build tool itself, and with a 
set of Jamfiles it becomes a build system.   It is however a fact that 
there are many features in the typical IDE which are useful for 
developers.  So the features of MPC is most likely on the wish list for 
many Boost users, and probably some of the library authors and 
maintainers as well.
>> The MPC .mpt template files for the tools should be generated as well.  
>> This would be based on bbv2 so most redundant overlap should be avoidable. 
>>     
>
> Many template files are already available.  New template files 
> are needed only for new build systems.
>
>   
How would compiler options be controlled, I envisioned that a different 
template was needed to set different defaults for the compiler.  But I 
am probably wrong.

>> Even if the mpc and qmake have their shiny aspects, I would be much more 
>> interested in good plug-in support for bbv2/bjam in IDEs such as 
>> Eclipse/CDE, VisualStudio, etc.  In the IDE this should have the look 
>> and feel of the native build system if possible.  This involves:
>>
>> - adding and removing source files from projects in the IDE
>> - creating new projects
>> - starting bbv2 builds which reports errors into the IDE interface
>> - execute or debug sessions should invoke build with bbv2 and offer to 
>> rebuild first if required 
>> - saving files could start background builds like in Eclipse managed C++ 
>> projects
>>     
>
> This would seem much more difficult to produce/maintain and would 
> likely never be as complete as using the native build system 
> directly.
>
>   
Depend on who you think this is difficult for.  My experience is that 
most developers do not pay much attentions to details in their build 
settings.  That is also why all sorts of IDEs with wizards setting up 
projects this and that is so popular.  When the individual project is 
set up, there is a set of inviting dialog boxes with a zillion option 
and check boxes to play with for each projects compiler options.  When 
the projects become large, this approach does not scale.  Someone has to 
start clean up and insert some control and discipline.  So plain native 
build system does not work in real projects.  The MPC approach fixes 
most problems, but it require developers to maintain the simpler 
configuration files manually.  Well, they will not start using it until 
somebody forces them to do it.  The create project menu in the IDE is 
too tempting.  So to me it become clear that adding and removing files 
from projects in the build system should be integrated in the IDE.  The 
MPC/qmake approach just make this a little tricky since the 
project/solution would need to be reloaded.  I guess some sort of 
file-level synchronization is possible, but that would also be tricky.
>> The funny thing is that I don't care that much myself for these 
>> features, I am more than happy with emacs + Boost.Build or whatever 
>> other _real_ build system is I use.   What frustrates me is that so many 
>> developers use build systems that come with their IDE without any regard 
>> to the possible downsides they bring with them.  Also, I believe real 
>> IDE plug-in support could be a boost in the popularity of bjam and 
>> Boost.Build.
>>     
>
> With MPC you get the best of both worlds.  I simply generate the 
> native build files that I choose to use.  Unfortunately, Jamfiles 
> is not one of the supported output formats.
>   
Or input file formats ;-)  Most people her at Boost would probably like 
that a lot.  Thanks for a great tool anyway.

-- 
Bjørn Roald