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 tools
  • SeeMS:  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:

1. To exercise the module's interface and validate its behavior independent of other modules.
2. 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.