Google Summer of Code


Project Ideas

C-based dependency scanner

The purpose is to write a dependency scanner for C-like languages with a focus on:

  • Performance: the current implementation is a Python module which can be slow on Boost-based c++ projects
  • Portability: the code should be useful for other build systems out of the scope of Waf

The outcomes must provide:

  • C, C++ and Fortran support for several language versions (c89, c99, c++-11)
  • Support for file encodings (utf-8 and iso8859-1 at least)
  • A python module usable by Waf, a standalone library and a binary application
  • A testsuite that can be run on Linux and Windows
  • Minimal instrumentation to show the performance benefits over the Python-based dependency scanner

Built-in Packaging

This project involves adding support to Waf for built-in packages:

  • OS X .pkg and .app
  • Windows .msi
  • Enhanced source tarballs
    • This involves adding support for distributing generated files with the tarball. A good example is including the .c and .h files from a Bison .y file. This would remove the dependency on Bison for tarballs and allow for better release testing.
  • Python .egg
    • Also include support for testing software within a virtualenv.

Unit Tests For waflib

Currently the core of Waf, waflib has no unit tests.

The goal of this project is to create a set of tests that can be shipped with waf built-in. When a user of waf wants to build they should be able to run waf test-internal and have it check the state of Waf on that platform.

This has the benefit of ensuring builds are repeatable and successful on the platform the developer or user is running on. Some projects may want to enable this by default when building from a tarball for enhanced security.

Profiling / Debug Support

This project involves adding built-in support for gprof, gcov, valgrind or other development tools. A general all-purpose library should be created to easily insert other tools as necessary.

Waf should collect build information during the build process for dumping and parsing later on.

A new command waf bug would be added to dump current build information in a format suitable for attaching and pasting into a bug report for an online bug tracker.

This would also involve creating a new internal JSON log format to dump compile commands, compiler output and internal state that can be captured raw or pretty-printed into HTML or Text for gleaning information about the build.

Your Own Project

You are more than welcome to suggest your own project. It is important to keep in mind several points before submitting a project:

  1. The project must be useful for waf and the community as a whole.
  2. Documentation for the Waf Book must be provided.
  3. Plan for the project to end at least 1.5 weeks for integration of code into Waf.
  4. Break the project into as many insular milestones as possible. After each of these is completed work will be integrated into Waf. It is OK if your project will only be usable at the end of GSoC. In this case make 1.5 weeks available at the end of the project.
  5. Demonstrated knowledge of the work you are trying to complete must exist prior to starting the project. For example if you wish to improve Haskell support you must have working knowledge of Haskell.

When in doubt please contact the project we will help guide you through this process.

Last modified on Feb 21, 2016 at 10:03:01 PM Last modified on Feb 21, 2016, 10:03:01 PM