• Mark OLESEN's avatar
    ENH: update handling of versioning and make control (issue #1010) · 6c68c34e
    Mark OLESEN authored
    - Use the OPENFOAM define (eg, 1806, 1812), which normally corresponds
      to a major release, to define an API level. This remains consistent
      within a release cycle and means that it is possible to manage
      several sub-versions and continue to have a consistent lookup.
      The current API value is updated automatically during the build
      and cached as meta data for later use, even when the wmake/ directory
      is missing or OpenFOAM has not yet be initialized.
      The version information reported on program start or with -help
      usage adjusted to reflect this. The build tag from git now also
      carries the date as being more meaningful to trace than a hash
    - Update etc/bashrc and etc/cshrc to obtain the project directory
      directly instead of via its prefix directory. The value obtained
      corresponds to an absolute path, from which the prefix directory
      can be obtained.
      The combination of these changes removes the reliance on any
      particular directory naming convention.
      For example,
         With an 1812 version (API level):
         installed as /some/path/somewhere/openfoam-mySandbox
      This makes the -prefix, -foamInstall, -projectVersion, -version
      values of foamEtcFiles, and similar entries for foamConfigurePaths
      WM_PROJECT_INST_DIR is no longer required or used
    ENH: improve handling and discovery of ThirdParty
    - improve the flexibility and reusability of ThirdParty packs to cover
      various standard use cases:
        1. Unpacking initial release tar files with two parallel directories
           - OpenFOAM-v1812/
           - ThirdParty-v1812/
        2. With an adjusted OpenFOAM directory name, for whatever reason
           - OpenFOAM-v1812-myCustom/
           - openfoam-1812-other-info/
        3. Operating with/without ThirdParty directory
      To handle these use cases, the following discovery is used.
      Note PROJECT = the OpenFOAM directory `$WM_PROJECT_DIR`
           PREFIX = the parent directory
           API = `$WM_PROJECT_API`, as per `foamEtcFiles -show-api`
       0. PROJECT/ThirdParty
          - for single-directory installations
       1. PREFIX/ThirdParty-VERSION
          - this corresponds to the traditional approach
       2. PREFIX/ThirdParty-vAPI
          - allows for an updated value of VERSION (eg, v1812-myCustom)
            without requiring a renamed ThirdParty. The API value
            would still be '1812' and the original ThirdParty-v1812/
            would be found.
       3. PREFIX/ThirdParty-API
          - this is the same as the previous example, but using an unadorned
            API value. This also makes sense if the chosen version name also
            uses the unadorned API value in its naming
            (eg, 1812-patch190131, 1812.19W03)
       4. PREFIX/ThirdParty-common
          - permits maximum reuse for various versions, but only for
            experienced user who are aware of potential version
       Directory existence is checked as is the presence of an Allwmake file
       or a platforms/ directory. This reduces the potential of false positive
       matches and limits the selection to directories that are either
       with sources (has the Allwmake file), or pre-compiled binaries (has
       the platforms/ directory).
       If none of the explored directories are found to be suitable,
       it reverts to using a PROJECT/ThirdParty dummy location since
       this is within the project source tree and can be trusted to
       have no negative side-effects.
    ENH: add csh support to foamConfigurePaths
    - this removes the previously experienced inconsistence in config file
    REMOVED: foamExec
    - was previously used when switching versions and before the
      bashrc/cshrc discovery logic was added. It is now obsolete.
To learn more about this project, read the wiki.