Bjørn Roald wrote:
Kevin Heifner wrote:
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.
I understand. You are happy with bbv2 and see no reason to move away from it. So if MPC is going to be a part of Boost one of the following must happen: 1. New support to generate Jamfiles is added to MPC. 2. Something is created that can generate MPC files from Jamfiles. 3. Maintain two sets of files: MPC and Jamfiles. 4. (added after reading the last section of the email) Add Jamfile input file support to MPC.
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.
Yes MPC allows the following: Source_Files { ^something.cpp !other.cpp } Both of these exclude the file. I however do not like source files laying around if they are not used; it is very confusing.
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.
Compiler options are controlled by commands in MPC files. For example, if you want to pass a particular macro to the compiler: macros += _AFXEXT
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 difficultly I was referring to was the actual creation/maintenance of the plugins. Since MPC can pick up files automatically in most cases, normally all that is required is rerunning MPC. My daily activity on a project is to follow every cvs/svn update with a run of MPC. If I need to add/remove a file all that is likely needed is to rerun MPC.
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.
That is one option I had not considered. I don't think it very likely, but still something to think about. KevinH -- Kevin Heifner heifner @ ociweb.com http://heifner.blogspot.com Object Computing, Inc. (OCI) www.ociweb.com