Improve Continuous Integration

This MR improves the continuous integration (CI) with GitLab.

Upgrade docker to ubuntu 20.04

The docker images (rboman/waves-py3 and rboman/waves-py3-red) have been rebuilt on the basis of the latest LTS release of ubuntu (focal - 20.04). The version of gcc is now 9. The code has been built and tested successfully without any modification.

Python2 not tested

I have not rebuilt the python2 version of the docker image (rboman/waves) because we do not want to keep the compatibility with python2 and it is a LOT of work (more than 3 hours to build the image - thanks trilinos!).

In consequence, the builds and tests are not done with python2 anymore.

gmsh 4

gmsh 4 (including the gmsh SDK) is now installed in the docker containers.

I have installed gmsh 4.6.0 (the latest version) because it is used by Luc for his recent developments which rely on the newest gmsh API. As far as waves is concerned, any version of gmsh 4.x (and even the old 3.0.6) can still be used in practise.

Please note that the v4 mesh format is not used yet inside the code (meshes are still written/read in the "old" format using the -3 flag).

clang-format

I have added a new job to the pipeline which checks the format of the source code. This job uses clang format version 10.

The idea here is to use a unified C++ format throughout the whole source code. Thanks to this "unified format", we can expect that the number of "diffs", when someone commit some code, will significantly decrease. For example, extra spaces (or missing spaces) will be deleted (or added), indentation will be corrected, etc.

It also means that if 2 persons write the same piece of code, it will look exactly the same after automatic formatting (then we can expect no diffs in git!)

When clang-format is run, it reads a new configuration file which has been added by me in the root folder of the source tree (see waves/.clang-format). For the moment, this configuration file translates the default style of Visual Studio Code, which is very similar to the one of Visual Studio:

BasedOnStyle: LLVM
UseTab: Never
IndentWidth: 4
BreakBeforeBraces: Allman
AccessModifierOffset: -4
SortIncludes: false
ColumnLimit: 0

As you can see, the style is the default "LLVM style" (LLVM is the framework around the clang compiler) with a few exceptions:

• we do not use tabulations,
• we use 4 spaces for indentation,
• we put C++ braces { and } on a separate line (as Eric Allman),
• we do not indent public, private keywords,
• the number of columns is unlimited.

I think that it is a simple starting point. If, in the future, we think that some rules should be changed, we will modify this file accordingly.

How does it work in practise?

You can format your code using the shortcuts in your favourite editor ("Ctrl-Alt-f" in VSCode - or "Ctrl+K, Ctrl+D" in Visual Studio - cfr here)

If you want to format all files at once, just run the new python script called ./scripts/format_code.py from the root of waves. It will format (which means "modify"!) all your source files with an executable called clang-format-10 (you must install it - I guess that Luc will add it to his libraries - see LLVM website).

...then check and commit the result. That's it!

As said above, I have added a "format" job to the CI pipeline. This job runs the format_code.py script and checks that there are no new diffs due to this additional formatting. In that case, it means that your code was already correctly formatted.

If the job fails (if there are some diffs after running the script), the job produces a warning and stores the result of the diff in an archive that you can download from the pipeline web page and inspect (this is called an "artefact").

In other words, a bad format does not make your pipeline fail. You get an "orange" badge which reminds you that you have introduced some wrongly-formatted code.

In this PR, I have formatted the code so that it gets a green badge. As you can see, the code was already almost OK (we formatted the code manually with VSCode, which produces the same result).

The last remark is about the version used: Unfortunately, clang-format evolves continuously and the output is not exactly the same when different versions are used... This is mainly because the old versions have been built when the C++11, C++17 did not exist.

Thus, I have chosen clang-format-10 which is the latest version available (although VSCode only provides clang-format-9 and Debian is still stuck to clang-format-7!). I think it makes sense to choose the same version as the default one in the docker container. If everybody uses Ubuntu or Luc's libraries, it will not be a problem to use this version exclusively.

fdtd/src/wProblem.h

@@ -32,7 +32,7 @@ namespace fdtd
 
 class FDTD_API Problem : public fwk::wSharedObject
 {
-  public:
+public:
     Problem();
     virtual ~Problem();
 
@@ -40,6 +40,6 @@ class FDTD_API Problem : public fwk::wSharedObject
     virtual void write(std::ostream &out) const override;
 #endif
 };
-}
+} // namespace fdtd
 
 #endif //WPROBLEM_H