precice/openfoam-adapter

Support multiple OpenFOAM versions with the same source

Ouverte

#32 ouverte le 4 oct. 2018

 (17 commentaires) (1 réaction) (0 personne assignée)C++ (115 forks)auto 404
buildingcompatibilityenhancementhelp wantedquestion

Métriques du dépôt

Stars
 (171 étoiles)
Métriques de merge PR
 (Métriques PR en attente)

Description

Often users are bound to specific OpenFOAM variants (e.g. openfoam.com, openfoam.org, foam-extend) and versions (not always the latest, sometimes very old). However, often small or not-so-small differences will give errors during compilation. Therefore, we need a system to be able to support different versions at compile time.

Implementing such a system would help a lot dealing with issues such as #21, #8, #9, #26. A list of currently supported versions can be found in our wiki.

Fortunately, all the three main variants set the environment variables WM_PROJECT (OpenFOAM for .com and .org, foam for foam-extend) and WM_PROJECT_VERSION (4.1, 5.0, 6 (no dot), ... and dev for .org, v1712, v1806, ... for .com, 3.2, 4.0, ... for foam-extend) (see also #29). Versioning systems and other assumptions have changed much lately.

We currently use the WMake build system, developped together with OpenFOAM. This is a quite primitive system, but it is intrinsic to OpenFOAM. On top of it, I have added the Allwmake bash script to automate the procedure even more (also a common way in OpenFOAM-derived projects).

A few ideas on how to go on:

  1. (ugly) Support different versions in different branches. The current state of the branch works with the latest version, Git tags/other branches for older versions.

    • This is how we support multiple SU2 and CalculiX versions.
    • Difficult to maintain, but easier than other options (e.g. different directories)
    • Here we have multiple "latest versions".
  2. (ugly) Use pre-processor commands to check the version and activate different parts of the code.

    • A bit ugly and maybe difficult to maintain
    • Some changes (e.g. required in #8 and #9 ) are much bigger and spread throughout the code to treat with small patches
  3. (ugly) Have source files like Adapter_of6_dev.C and Adapter_of4_5.C and let our script pick the correct ones.

    • Difficult to maintain
    • Keep the files kind of clean
  4. Use a proper configuration system (e.g. CMake)

    • Ok, but how to solve our problem with it?
    • Do we need to replace WMake completely or can it work on top of it?

I would very much value your feedback on this.

Guide contributeur