Information for Developers (incomplete)

1. Introduction

2. Source Code Managment

The revisions of the source code are manged with the stupid content tracker git. Read about HOW-I- use git or visit one of the external references.

Each package has two kinds of version numbers. One is specified with AC_INIT. This denotes the version number of the pacakge, i.e. the one that is added to the distribution (make dist). The second version number characterises the shared library. It is defind by three variables LIB_CURRENT,LIB_REVISION and LIB_AGE

3.1 The package version number

The package version number is composed of three numbers whose meaning is vaguely defined:

major version - should be increased after fundamendal changes.
minor version - should be increased after enhancements.
revision - should be increased after fixes.

The version number does not impact any functionality.

3.2 The library version number

The library version number is not directly related to the package version number. Such a relation can be established by encoding the package version in the library name.

There are three numbers which characterise a library:

LIB_CURRENT - characterises the interface version.
LIB_AGE - characterises the compatibility to previous interfaces.
LIB_REVISION - characterises the patch level for one interface version.

Increment LIB_CURRENT if the interface changes and reset LIB_REVISION back to zero. The interface is changed if if some code in the header file is changed e.g.:

function prototypes are changed,
data types are changed or
constants, enums are changed.

The number LIB_AGE is always smaller or equal to LIB_CURRENT. It should be set to zero if the current interface is not compatible with any previous interface version. LIB_AGE should be incremented if the last interface change only extends the previous interface i.e. functions, member functions, or classes were added. Increment LIB_REVISION if only the implementation is changed i.e. if only .cc were modified.

4. Adding Processors

(see Installation - Adding Your Own processors)

5. Debugging

To debug, recompile the source code in question in the following way:

touch [file.cc]
make CXXFLAGS="-g"

Then run marlin inside gdb. This is achieved by supplying the --debug option to the steering file creating scripts. This will generate a temporary steering file, start gdb and set the run argument to the steering file.

You can set break points at certain lines in the source code: file.cc:123. It rarely worked for me to set break points using function names. And then execute the processing: run. The signal emitted by CTRL-C is usually catched by the processor ProgressHandler. It catches the signal and throws an exception, such that marlin can end all processors, close the output file etc. Since gdb also catches this signal and has precedence, you cannot end the processing this way. However, you can sent the signal from the gdb command line: signal SIGINT.