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@…

Boost.XML

I started a 'boost.xml' library (right now in ​https://svn.boost.org/svn/boost/sandbox/xml/) a long time ago, which I have never found enough time and energy to bring to a formal boost submission. Having a proper XML library as part of boost would be very useful, in particular if "proper XML" goes beyond the basics such as parsing. (There already are lots of half-baked XML parsers, but few fully conform to the spec, or yield well performing in-memory representations that can be traversed via XML-specific tools such as XPath.)

Prerequisites

The student needs to have at least a basic understanding of the XML and related spec, as well as some exposure to existing XML APIs (such as DOM, SAX, XMLReader) to understand the problem domain.

Boost.Python

There are a couple of independent improvements that may be done:

• Add (better) support for NumPy bindings.
• Improve the converter registry to avoid conflicts when multiple extension modules try to expose the same C++ types.
• Add bindings for other Python C API functions, such as exception handling.

Prerequisites

• Some basic Python knowledge (as well as NumPy in the first case above).
• Past experience with Boost.Python.

Summer of Code Policies

Forthcoming...