Boost logo

Boost :

From: Kevin Heifner (heifner_k_at_[hidden])
Date: 2007-03-03 22:11:47


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.

>> 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.

>> 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.

> 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.

> 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.

> 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.

KevinH

-- 
Kevin Heifner  heifner @ ociweb.com  http://heifner.blogspot.com
           Object Computing, Inc. (OCI) www.ociweb.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk