Proposals for SummerOfCode2006

Applications:


Submitted Improve the APR build system

Name: Walter Mundt
Email: emage@spamcop.net
Cell Phone: 1-407-782-3491
Apache SoC Subject ID: apr-build-system
Title: Improve the APR build system

General Experience

I am a good generalist programmer with knowledge of many programming languages and techniques. I competed in the ACM International Collegiate Programming Contest finals this year. Languages with which I am very familiar include C/C++, Python, Java, Perl, and sh script. I've also dabbled in Lisp, C#, VB, among others. I also understand Linux system administration - I have RHCE certification. I also have a bit of OSS experience: I acted as a "core team" development person for the TWiki project (twiki.org) for a while, and have submitted patches here and there wherever I ended up fixing/improving something open source.

Motivation/Interest

Ever since learning Python I find it very pleasant to develop in. Additionally, this task seems well-defined and will benefit from my contest experience, where text manipulation/generation problems are fairly common. Finally, as a user of both Apache and Subversion, it appeals to me to do work on improving a component used by both.

Deliverables

The primary deliverable should be a patch to add Win32 and Netware build support to the build/gen-build.py. Support for additional build systems may be added as time and available test environments allow for the duration of the SummerOfCode. Documentation of any new options/usage scenarios for the gen-build.py script will also be included. Note that I do NOT have access to a Netware development environment, so others will have to test the Netware build system changes.

New Features

Once the enhanced build-gen is working for selecting the source files to compile, some new features should be added for making the builds on the newly-supported platforms as configurable as Unix builds. Primarily, this will involve reimplementing the linkage-level choices made by autoconf within the gen-build.py script, or (where support exists) into the actual generated build files.

Approach

The first step will be to attempt to have the script generate results as close as possible to the current, working build files for the new platforms it will support. The resulting build files should be tested on as many variants of the target platform as possible, and it should be shown that they will remain correct when source files are added/removed/renamed in the gen-build-managed directories.

Once that's working, add and document additional options in gen-build for enabling and diabling optional libraries; these options and their effects might be configured in build.conf. On Windows, consider adding a third option for each library that generates duplicate "configuration" entries in the DSP for an option, one set w/the library in and one set without.

Open Questions

As I understand things, the gen-build.py script is currently run pre-distribution by the library developers. If this is the case, being able to use the script to change linkage options would add a new build dependency for Python on Windows platforms. Is this an issue for anyone? If it is, should the "third option" discussed above be prioritized more, since it partially alleviates this issue by allowing library users to make the most common linkage choices within the IDE without having to re-run gen-build?

Post-SoC Intentions

Should I be selected to work on this during the SoC, I will also, at the least, commit to maintaining my changes over the 6-8 months following, or until any major issues are resolved, whichever is longer. If I really enjoy working with this, or if there is a lot of demand, I may go further and keep adding features.


Add basic logging capabilities to APR

Subject ID: apr-logging

Design

Notes

Types

Contstants

Functions

Deliverables

All code is to be documented inline according to APR standard practice.

Approach

First, the header file should be written according to the design. Then, start with the test suite and basic "write to a log file"/"write to console" logger implementations. Once those are working fine, add the Unix syslog implementation and Windows Event Logger implementations.

Development will occur on Linux and Windows to begin with. On the Linux side, GCC 3.2 and 4.0 are planned as during-development targets; on Windows, cygwin's GCC, Dev-C++'s mingw runtime, and VS6 are all planned targets. Once development reaches a usable alpha state, patches will be distributed so that anyone running other platforms can test for portability issues; distribution method(s) to be negotiated -- manual mailing-list posts, daily snapshots on the Web, and svn branch commits are all (non-mutually exclusive) options.

Post-SoC Intentions

Should I be selected to work on this during the SoC, I will also, at the least, commit to maintaining my changes over the 6-8 months following, or until any major issues are resolved, whichever is longer. If new features are widely demanded by the community, I will very likely implement them. Aside from that, if I really like working with APR I may go on to work on other parts of it, as I don't think a logging API as basic as what I have described here will need much work after the summer is over. I also don't think a more elaborate system (think "log4c") would be a good fit for being part of APR itself.

WalterMundt/SummerOfCodeProposals (last edited 2009-09-20 23:35:36 by localhost)