Cheetah - SKA - PSS - Prototype Time Domain Search Pipeline
developers_guide

Developers Guide

Dependencies

Do not introduce any new dependencies on any other product without consultation

Build Products

The project will build the pipeline executable, two c++ libraries, and their associated header files. One library will support the main product and the second a library is a set of utilitites to aid in unit testing code that uses the main library.

Repository

Workflow and Branches

Repository Structure

cmake : project specific files for configuring the build system tools : useful things to aid the developer such as a class template generator doc : documentation & doc templates, with the exception of the API doc of the classess. Also see module doc directoy. cheetah : this is the src code for the cheetah library. It is organised as a set of modules with the following minimal structure (following the boost conventions for templates)

cheetah +

cheetah/test : the location of tests and any public headers for the cheetah integration tests cheetah/test/src : the location of all test implementation coded

The Build System

This project uses cmake as is build system. See the notes in the CMakeLists.txt file in the top directory

Adding a src file/class

Adding a submodule

Including a dependency in the build system

Coding Conventions

Coding conventions are used in this project to ensure conformity in style and to help reduce any of the very many pitfalls c++ programming can introduce, Remember that these are just general guidelines. Try and stick to them as much as possible, but there will always be cases where doing it differently is justified. Document these exceptions with comments in the code.

Namespaces

Naming Conventions

Indendation & CRLF of source files

C++ Files

Each class shall have its own separate cpp and header file. The name of the file should be the same as the class with the .h or .cpp extension Do not mix two classes together in the same file. An exception to this rule can be made where there is a private Internal Implementation class unique to the class being implemented AND it is not confusing to do so.

Constructors

Inheritance

Class Declarations

Exceptions

Unit Tests

Using CUDA

If CUDA is available and it has been explicitly activated in the build system, the ENABLE_CUDA flag will be set. Use this flag to ensure your code compiles and your unit tests run with or without CUDA availability.

Setting specific compile flags for subpackage products shall be done through the cuda_subpackage_compile macro: e.g.

cuda_subpackage_compile(${lib_src_cuda} OPTIONS "-arch compute\_35")

Extending std classes

While this style guide requests CamelCase typedefs, there are cases where the standard convention is to use lower_case names for typedefs. This is true in the case of classes that extend or can be used in place of classes from the standard library (or as in the case of thrust, boost, etc. libraries that follow conventions from the standard library) that conform to specific concepts. Places where this is done should be clearly documented.