1. 13 Dec, 2018 1 commit
  2. 02 Dec, 2018 1 commit
    • 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.