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

From: Bjørn Roald (bjorn_at_[hidden])
Date: 2007-03-05 15:23:45

Kevin Heifner wrote:
> 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.
>   

I think this is mainly a benefit to those who have selected .mpc files 
as method to specify projects.  This is not the case for the boost 
libraries.  I can not speak for the authors, but I do not think there 
are compelling reasons to switch.

> 2. Something is created that can generate MPC files from Jamfiles.
>   

This would be useful.  MPC itself does not need to be in the boost 
distro for this scheme to work.  All that is needed is that something 
can generate the .mpc files.  One natural choice would be an add-on to 
bbv2 since it already parses the Jamfiles.

> 3. Maintain two sets of files: MPC and Jamfiles.
>   

I prefer to ignore this option until other options are tried.

> 4. (added after reading the last section of the email)
>     Add Jamfile input file support to MPC.
>
>   
Yes, If the semantics of the information in .mpc files and Jamfiles are 
close, this may be feasible.  Would be fun to try it out anyway.  Think 
I need better understanding of the two file formats first.

<snipped a lot>

>> 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.
>
>   
I think I knew that was what you referred to ;-)  I do not contend that 
this may be challenging, but if it succeeds it would be the solution 
that added most value to users of the tool.

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

Then reload the solution/project in your IDE.

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

Maybe somebody around here would contribute an optional parser to MPC  ;-)

-- 
Bjørn Roald