From: Kevin Heifner (heifner_k_at_[hidden])
Date: 2007-03-04 19:32:23
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