Development guide

Source code management (GIT)

The source code of SDF3 is stored inside a GIT repository. This page outlines the rules that need to be followed when using this repository. This page does however not provide an introduction to GIT. Readers how want to familiarize themselves with this source code management system are adviced to study one of the many online GIT tutorials.

The main SDF3 repository is located at: ssh://shell.ics.ele.tue.nl/home/epicurus/git/sdf3.git

Releases will be made based on the source code on the HEAD of the master branch inside the main SDF3 repository.

Only source code that should be put into an official release should be placed on the master branch. Development should always be performed on a separate branch.

The source code used to create an official release will be tagged with a tag that used the following format: release-<version number>.

These rules enable a simple and clean release process in which all source code on the master branch can be released without any additional clean-up operation. This enables an automated release process. The required tagging of releases allows an easy rollback to a particular release.

The name of a branch names should clearly indicate the functionality that is developed on this branch.

Different software developments should be placed on different branches.

Consider as an example a software development process that adds a latency analysis algorithm to the FSMSADF MoC. This development could be placed on a branch called 'LatencyAnalsyisFSMSADF'. It should definitly not be placed on a branch that has a name like 'ExtensionsByDeveloperX'. When the same developer is working on a different type of algorithm (e.g. a buffersizing algorithm for FSMSADF), then this second development should take place on a seprate branch. This branch could for example be called ('BufferSizingFSMSADF'). The developer should not place both developments on a single branch as this makes it harder to separete the two algorithms from each other.

A branch may only be merged into the master branch once the source code in this branch adheres to all SDF3 coding guidelines as outlined in this development guide.

Obviously, all source code merged into the master branch should be properly tested. It should have been verified by the developer that the newly added source code does not break any of the existing algorithms. Furthermore, a set of proper unit tests should be provided for the newly added functionality.

Files that are automatically generated during the build process should not be placed under version control. All other files should be placed under version control.

After a clean checkout from the repository, it should be possible to compile the source code on the HEAD of the master branch on all supported platforms without having to make any changes to the files or directory structure. The compiled binaries should be able to pass all unit tests that have been defined for the software.

These rules enforce a clean repository in which only files are stored that can be altered by the developers. They also ensure that new developers can always start their development from a working copy of the source code without having to make all sorts of changes in files or the file structure.

The main SDF3 repository enforces the coding style outlined in this development guide.

This rule ensures a consistent coding style throughout all files that are part of the official SDF3 releases. Developers may use astyle (linux, windows) in combination with this options file to automatically format their source code. Git users can automate this process by using a pre-commit hook. In order to use this hook, the user needs to make sure that astyle is available on the path.