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:
>> 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
>>> 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++
> This would seem much more difficult to produce/maintain and would
> likely never be as complete as using the native build system
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
> 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
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk