Contributing to libpll

We are always glad to receive suggestions and ideas on how to improve or extend libpll. We are also grateful for any code you contribute to the project, in case you decide to do so. When contributing code please make absolutely sure you follow the rules in the next couple of sections.

Coding style

Adopt the coding style of the project. We understand you may have your own coding style with which you are familiar and happy, but mixing coding styles in one project may turn the code into a large mess. Therefore, we require that a single coding style is used within the libpll project. Some rules that must be followed:

• Opening brackets always go to a new line, and are the only character on that new line. The same applies for closing brackets. For example:

for (i = 0; i < n; ++i)
{
  c[i] = a[i] * b[i];
  d[i] = a[i] + b[i];
}

• Indentation inside a scope is always two characters.
• Never ever ever use tabs! Set your editor to expand tabs to spaces. If you use vim, the command is set expandtab
• The length of a line should not surpass 80 characters.
• Variable declarations go to one line. Do not use line-breaks when declaring variables. The following is what you should avoid:

int
  a,b,c,
  d,e;

• Produce your code in a modular way. Each file is one module. Functions used only within the particular file/module, must be declared as static to hint other developers that they do not need to read that particular function if they do not intend to do anything with your module.

• Prefix all your 'public' (visible from outside of the file) function declarations with PLL_EXPORT which will add the export directive to the object files.

Pushing to the repository

We want libpll to be the holy grail of the likelihood function. Stable and correct code at all times. The only tool you can rely on that will compute your likelihood correctly. To be sure that the universe doesn't explode tomorrow. Therefore, the level of pedantism is maximized. Commit only when you are absolutely sure that your changes fulfill the following:

• libpll is possible to compile
• the compiler gives no warnings when using the standard libpll Makefile (includes -Wall)
• your code follows the coding style
• you have tested the code and gives correct/meaningful results,
• you have run the test-scripts, and no errors/memory leaks were detected.

Once you pass the above requirements, create your own branch, and make a pull request to the dev branch. Tomas or Diego will go through the code and merge it into the dev branch. Never push to the master branch directly. The master should contain a stable version at all times. Once, your code is in the dev branch, Tomas will merge it to the master branch with the next libpll release.

IMPORTANT

Before working with the repository, make sure you have a clear understanding of the Git merge and rebase commands, their differences, and when to use one or the other.

Never use the commit command if you are working on the dev branch directly, unless you finish and properly test what you were working on. Anything on the dev branch is always double-checked by Tomas. Pushing incomplete code without testing means you are putting extra effort or wasting the time to someone else. Therefore, the easiest, especially when using more than one computer for code development, is to create your own branch e.g. featureX off dev, and use the Git rebase command to replay changes in dev to your own branch. Once the feature you were working on is finished, make a pull request for dev. Use the commit command only when necessary to avoid meaningless intermediate commits and keep the repository clean.

Programming Language

libpll is implemented fully in C with the use of Intel intrinsics for vector instructions, and occasionally parts in pure assembler.

License

libpll is licensed under the GNU Affero GPL. Make sure you agree with the terms of the license before pushing any code to the repository.