$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2007-03-03 04:50:17
Jeff Garland wrote:
> Michael Marcin wrote:
>  >
>   
>> Speaking of tools...
>>
>> I like Boost.Build a lot but a major stumbling block for integrating it 
>> into our company is that our programmers are mostly familiar with IDE 
>> environments like CodeWarrior, Visual Studio, XCode, etc.  A program 
>> that could transform a bbv2 project into IDE projects would make the 
>> barrier to adoption much smaller.  Especially if that tool was 
>> extensible so new modules could be added to support different IDEs.
>>     
>
> You could use MPC (make project creator).  It's a set of perl scripts that 
> generate native makefiles for various platforms -- various solution files for 
> VC*, nmake, borland make, Makefiles for *nix, etc.  This is the system used to 
> maintain makefiles for ACE/TAO which is ported to tons of platforms.  You can 
> download the tool from:
>
> info     --> http://www.ociweb.com/products/mpc
> download --> http://www.ociweb.com/products/mpc/down.html
>
>   
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.
By the way, http://www.trolltech.com has a similar solution called qmake 
which is used in Qt.  This may or may not be more appropriate in an 
optional add-on to Boost.Build.  This highlights another nice feature of 
such tools, which I have met.  If you have an opensource project in 
which you do not expect users to be familiar with your build system.  
You can provide pre-built IDE projects for libraries, executables and/or 
example and tutorial code. 
> 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.
> Note, I haven't tried the Boost files, but I've used MPC on cross-platform 
> projects -- it's a nifty solution.
>
>   
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.
> As for SoC maybe we could tranlate bbv2 into MPC and use MPC to generate 
> native files -- essentially using it as the 'compiler backend'.  Not sure if 
> there would be too much overlap there with bbv2, but it would be worth looking 
> at as an approach.
>   
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. 
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
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.
-- Bjørn Roald