For information about Google Summer of Code see the program ​home page. This site contains information about registration, submitting proposals, and ​mentoring information. A calendar of dates and deadlines can be found ​here.

This page will be used to document any Boost-specific policies regarding student acceptance and project management and also serves as a place to list project ideas.

Previous Summer of Code projects can be found here.

Project Ideas

Please list ideas for possible student projects.

Boost.Build

There are a few interesting improvements that can be done withing GSoC timeframe:

• Signature-based update engine. This means that a MD5 checksum of a command used to update each target is recorded, and if that changes on the next run, the target is rebuilt. This will considerably improve reliability.

• IDE integration. There's already initial plugin for Eclipse CDT plugin, which can be improved. Plugins for other IDEs, such as KDevelop or Visual Studio are also possible.

• Packaging support. It would be nice to automatically create packages in popular distribution formats.

• ​Python Port can offer many tasks, though it's relatively high challenge.

Boost.Process

A first version of Boost.Process was created in the SoC 2006 program (see ​http://code.google.com/soc/2006/boost/appinfo.html?csaid=7ADC016A60772A9C). Since then there have been several attempts to finish this library (one by myself in 2009). While there is considerable interest in this library noone had the time yet to do the job.

The status quo of the library (which is available at ​http://svn.boost.org/svn/boost/sandbox/process/) is documented at ​http://www.highscore.de/cpp/process/. There have been various discussions in the Boost mailing lists last year, too.

As far as I remember some problems are:

• As platforms are very different when it comes to supporting higher level features it's not entirely clear how the architecture should look like (there have been different implementations in the past).
• Some parts of the library could become libraries of their own or even be moved to other libraries like Boost.Interprocess (eg. pipes).
• Supporting asynchronous I/O works already but doesn't really follow Boost.Asio patterns.
• Unit tests are different than in other libraries (as processes have to be created) and have to be improved.

The goal would be to finish the library after 4 years that it can finally be reviewed. ;)

Boris, boris@…

Summer of Code Policies

Forthcoming...