ProteoWizard Project Overview
Directory Layout
[root]
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]
Projects
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 toolsSeeMS: Graphic data visualization program (Windows only)
Code Conventions
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.
Technical documentation home