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