Documentation for Developers
This page offers an overview of the ProteoWizard project. It provides a layout of the files included in the ProteoWizard download and an outline of the various ProteoWizard projects. Please visit our FAQ and Support pages if you have any questions.
For full code documentation, please visit the Source Code pages.
Below are a couple of documents you might find useful when starting to develop with ProteoWizard.
- build [everything is built here]
- doc [documentation]
- example_data [some example data files]
- libraries [3rd party library archives]
- pwiz [main source tree -- all Apache licensed]
- pwiz_aux [non-Apache licensed contributed code]
- pwiz_tools [source code for tools]
Here is an outline of the various ProteoWizard projects, organized by dependency level. There may be dependencies within a given level, but there should never be any up-level dependencies. Unless otherwise noted, all projects are cross-platform. Each project's source files are contained in the subdirectory of pwiz of the same name.
level 0 (pwiz/utility)
- math: Mathematics classes (linear algebra, statistics, special mathematical functions)
- misc: Miscellaneous standalone utility classes (Base64, SHA-1, 2D drawing, unit testing)
- minimxml: XML parsing and writing
- proteome: Chemical formula, peptide, and isotope calculations.
- vendor_api: Vendor-specific API wrappers (Windows only)
level 1 (pwiz/data)
- msdata: Mass spec file format abstraction layer.
- misc: Library containing classes for handling FT transient data, complex frequency data, MS1 peak data.
- vendor_readers: Vendor-specific Reader implementations
level 2 (pwiz/analysis)
- chromatogram_processing: Chromatogram analysis
- frequency: Library of routines for frequency-domain peak detection.
- passive: Event-driven analysis modules
- peakdetect: General interface for peak detection
- peptideid: Modules handling peptide id info abstraction and parsing
- spectrum_processing: Spectrum analysis
level 3 (pwiz_tools)
- commandline: Command-line tools
- SeeMS: Graphic data visualization program (Windows only)
A code module consists of an interface (Foo.hpp), implementation (Foo.cpp), and a unit test (FooTest.cpp). The interface should be self-documenting, with optional inclusion of comment markup for automated documentation tools (e.g. Doxygen). The unit test serves two purposes:
- To exercise the module's interface and validate its behavior independent of other modules.
- To document the intended usage of the code module.
Clients of a code module should never need to look at the implementation for questions about usage.