Re: [boost] [Ann] Boost and Google Summer of Code 2007

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