The following contains answers to typical questions from contributors about OpenMS.
The following section provides general information to new contributors.
- Check out the development version of OpenMS (see OpenMS releases and installers).
- Build OpenMS according to the installation instructions.
- Read the OpenMS Coding Conventions.
- Read the OpenMS User Tutorial.
- Create a GitHub account.
- Subscribe to the open-ms-general or contact us.
A tool starts its lifecycle in UTILS and may exist without being thoroughly tested. Tools may be promoted from UTILS
to TOOLS if they are stable enough, are fully tested, fully documented, and a test workflow exists.
Follow the OpenMS coding conventions.
Coding style (brackets, variable names, etc.) must conform to the conventions.
- The class and all the members must be documented thoroughly.
- Check your code with the tool
tools/checker.php. Callphp tools/checker.phpfor detailed instructions.
Please open a pull request and follow the pull request guidelines.
The following section provides information about how to troubleshoot common OpenMS issues.
CMake got confused. Set up a new build directory and try again. Build from source, deleting the CMakeCache.txt
and cmake directory might help.
The following questions are related to the build system.
CMake builds BuildSystems for different platforms, e.g. VisualStudio Solutions on Windows, Makefiles on Linux etc.
This allows us to define in one central location (namely CMakeLists.txt) how OpenMS is build and have the platform
specific stuff handled by CMake. View the cmake website for more information.
See Installation instructions for your platform.
In general, call CMake(.exe) with some parameters to create the native build-system.
Afterwards, (but usually) don't have to edit the current configuration using a GUI named ccmake
(or CMake-GUI in Windows), which ships with CMake).
Whenever `ccmake` is mentioned in this document, substitute this by `CMake-GUI` if your OS is Windows. Edit
the `CMakeCache.txt` file directly.
Type cmake into a console. This will list the available code generators available on your platform,
pass them to CMake using the -G option.
- Create the new class in the corresponding sub-folder of the sub-project. The header has to be created in
src/<sub-project>/include/OpenMSand the cpp file insrc/<sub-project>/source, e.g.,src/openms/include/OpenMS/FORMAT/NewFileFormat.handsrc/openms/source/FORMAT/NewFileFormat.cpp. - Add both to the respective
sources.cmakefile in the same directory (e.g.,src/openms/source/FORMAT/andsrc/openms/include/OpenMS/FORMAT/). - Add the corresponding class test to
src/tests/class_tests/<sub-project>/(e.g.,src/tests/class_tests/openms/source/NewFileFormat_test.cpp). - Add the test to the
executables.cmakefile in the test folder (e.g.,src/tests/class_tests/openms/executables.cmake). - Add them to git by using the command
git add.
- Create two new
sources.cmakefiles (one forsrc/<sub-project>/include/OpenMS/MYDIR, one forsrc/<sub-project>/source/MYDIR), using existingsources.cmakefiles as template. - Add the new
sources.cmakefiles tosrc/<sub-project>/includes.cmake - If you created a new directory directly under
src/openms/source, then have a look atsrc/tests/class_tests/openms/executables.cmake. - Add a new section that makes the unit testing system aware of the new (upcoming) tests.
- Look at the very bottom and augment
TEST_executables. - Add a new group target to
src/tests/class_tests/openms/CMakeLists.txt.
The following section provides information about how to debug your code.
Execute an OpenMS class test using the CTest regular expressions:
$ ctest -V -R "^<class>_test"
# To build a class test, call the respective make target in ./source/TEST:
$ make <class>_testTo run a TOPP test, use:
$ ctest -V -R "TOPP_<tool>"To build the tool, use:
$ make <tool>Dump a core if an uncaught exception occurs, by setting the environment variable OPENMS_DUMP_CORE.
Each time an uncaught exception occurs, the OPENMS_DUMP_CORE variable is checked and a segmentation fault is caused,
if it is set.
Debug the TOPPView application to stop at line 341 of SpectrumMDIWindow.C.
- Enter the following in your terminal:
Run gdb:
shell> gdb TOPPView- Start the application (and close it):
gdb> run [arguments]- Set the breakpoint:
gdb> break SpectrumMDIWindow.C:341- Start the application again (with the same arguments):
gdb> runFind a definition of the main page here.
Add a new module here.
The program OpenMS/doc/doxygen/parameters/TOPPDocumenter.cpp creates the command line documentation for all classes
that are included in the static ToolHandler.cpp tools list. It can be included in the documentation using
the following doxygen command:
@verbinclude TOPP_<tool name>.cli
Test if everything worked by calling make doc_param_internal. The command line documentation is written to
OpenMS/doc/doxygen/parameters/output/.
View the following OpenMS tutorials:
OpenMS/doc/OpenMS_tutorial/refman_overwrite.tex.in(for PDF tutorials)OpenMS/doc/doxygen/public/OpenMS_Tutorial_html.doxygen(for html tutorials)
View the following TOPP and TOPPView tutorials:
OpenMS/doc/TOPP_tutorial/refman_overwrite.tex.in(for PDF tutorials)OpenMS/doc/doxygen/public/TOPP_Tutorial_html.doxygen(for html tutorials)
To contribute to a bug fix:
- Submit the bug as a GitHub issue.
- Create a feature branch (e.g.
feature/fix_missing_filename_issue_615) from your (up-to-date) develop branch in your fork of OpenMS. - Fix the bug and add a test.
- Create a pull request for your branch.
- After approval and merge make sure the issue is closed.