READMEDEV.org



README for developers
This page is dedicated to rules and conventions that Chameleon’s
  developers must follow and that should be read by contributors.

1 Gitlab flow: how to contribute to Chameleon
Please read and follow guidelines given in the CONTRIBUTING file.

1.1 Update submodules
Chameleon git project depends on a “submodule” git, located in
  cmake_modules/morse_cmake and hosted here
  https://gitlab.inria.fr/solverstack/morse_cmake.
To update this submodule to the last development state, follow
  these steps:
git submodule update --remote cmake_modules/morse_cmake
git commit cmake_modules/morse_cmake -m "update morse_cmake submodule"
git push --recurse-submodules=check


2 Documentation
<sec:doc>

2.1 Generate the documentation

2.1.1 Prerequisites
To generate the documentation you need to have Doxygen and
  org-mode installed on your system.
For example, on Debian systems:
sudo apt install doxygen org-mode texlive texlive-latex-extra emacs


2.1.2 configure + make documentation
Enter into the Chameleon’s source root directory and configure
  with CHAMELEON_ENABLE_DOC=ON, then generate the documentation
  with make doc
cd chameleon
mkdir build && cd build
cmake .. -DCHAMELEON_ENABLE_DOC=ON
make doc


2.2 Rules about source code documentation
Please refer to this file for the documentation guidelines README.

3 Naming and writting conventions
Chameleon library started as an extension of the PLASMA library so
  that code naming and writting conventions should follow PLASMA ones.

4 Releasing
A Chameleon’s release is a source package, of the form
  chameleon-major.minor.patch.tar.gz, which:

  has been properly tested,
  has an up-to-date ChangeLog file,
  is published on internet as a GitLab release plus an associated
    git tag.


4.1 Test Chameleon before packaging
TODO - Write the way we could systematically test Chameleon before
  packaging, for example writting a script (generated from this
  org-mode file) to be used on PlaFRIM plus some specific ctest
  tests.

4.2 Release generation and publication
Releases are published on GitLab automatically through the gitlab-ci
  job release.
To create a release the workflow is:

  ensure chameleon is ready for this release, i.e.
    
      all required features are well integrated
      all tests succeed
      the ChangeLog file is up-to-date
      the version number is up-to-date in all source files
    
  
  create and push a branch release-major.minor.patch,
    major.minor.patch being the version number for the release
  the gitlab-ci job should produce a new release and tag according
    to the version number
    
      releases: https://gitlab.inria.fr/solverstack/chameleon/releases
      tags: https://gitlab.inria.fr/solverstack/chameleon/tags
    
  
  delete the branch


5 CDash tests dashboard
To see details about the tests performed during the pipelines visit
  CDash. It has been stopped for now because the CDash server is somehow
  slow and our jobs may fail because of that.

6 Static and dynamic analysis
To see details about the analysis job performed during the
  pipelines visit Sonarqube.
  See also the coverage of unitary tests here : LCOV coverage.