ENH: update handling of versioning and make control (issue #1010)
- 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 value. - 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): WM_PROJECT_VERSION=myVersion installed as /some/path/somewhere/openfoam-mySandbox This makes the -prefix, -foamInstall, -projectVersion, -version values of foamEtcFiles, and similar entries for foamConfigurePaths superfluous. 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 VERSION = `$WM_PROJECT_VERSION` 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 incompatibilities 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 contents. REMOVED: foamExec - was previously used when switching versions and before the bashrc/cshrc discovery logic was added. It is now obsolete.