About Boost Patches
- Are The Patches Required?
- Process for submitting a patch to Boost
- How are Boost updates handled
- Descriptions of Current Patches
The question has come up as to what the purpose of the Boost patches are, when they are needed and how to go about adding a patch. I’ll try to answer these questions here.
The Boost library patches are currently made for one of the following reasons:
- To silence a benign warning (such as a function parameter which isn’t used). Often this is in response to a compiler not supported by Boost.
- To fix an actual bug discovered in Boost. This may have surfaced in ASL or it may be a bug that was discovered by a team using Boost at Adobe. Inside Adobe STLab is responsible for distributing the Boost libraries. The patches will reflect this usage.
- To support a compiler which is not currently supported by Boost. This will typically be to support CodeWarrior 9.6 on the Macintosh (a configuration not officially supported by ASL, but many teams at Adobe have not yet moved to XCode) or to support a release of either GCC or Visual C++ which is more recent than that supported by Boost (this may include seed release at Adobe which are not yet public).
Are The Patches Required?
If you aren’t seeing problems with ASL with an unpatched Boost than probably not. We currently haven’t been good about adding regression tests for the patches (mostly because the problems encountered have appeared by simply building ASL). In the future we will be better about this. Our tests and builds will always assume a patched Boost library. If ASL works for you without patching Boost, great, but if you encounter an issue, please look over the patches before reporting a bug.
Process for submitting a patch to Boost
If you aren’t sure of the issue, discuss it on the developer list. Once you have isolated the problem, report the bug to Boost using the Boost bug tracking facility.
Send an e-mail to the [mailto:firstname.lastname@example.org developer list] or directly to Sean Parent including:
- A complete description of the problem.
- The Boost bug number assigned from source forge.
- The complete path to the file(s) to be patched.
- The complete text of the patched files (please ZIP the files to avoid having mail mangle them).
- The patched portion of the file should include comments denoting the begin and end of the patched section, your e-mail address, and the Boost bug number, and the description of the problem being fixed. In C++ code this should look like:
/* ADOBE (sparent(a)adobe.com) : Boost bug #12345. Removed unused parameter names to silence warnings. */ void function(int); /* END ADOBE */
- A .cpp test file to regress the bug (if it doesn’t happen in the normal course of building ASL or running existing ASL tests.)
How are Boost updates handled
We will assume that the Boost bugs have been fixed and will always start with a fresh release of Boost. If the regression tests show no problems then it is assumed that the patch is no longer necessary. One implication of this is that fixes for unsupported compilers will have to be resubmitted (this is one way to encourage developers to prioritize updating tools before libraries).