6c68c34e1a
- 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.
|
||
|---|---|---|
| .. | ||
| .gitignore | ||
| api-info | ||
| README.md | ||
META-INFO
Meta-information is for OpenFOAM internal use only.
Do not rely on any files or any file contents in this directory, or even the existence of this directory.
The format, content and meaning may be changed at anytime without notice.
The information is provided here for internal documentation purposes.
api-info
This file and its contents are to be tracked by git.
-
File content (api) generated by wmakeBuildInfo from OPENFOAM define in
wmake/rules/General/general -
File content (patch) is manually generated content.
build-info
This file is never to be tracked by git, but may be present in shipped source archives.
- File content (branch, build) generated by wmakeBuildInfo from git information and cached from previous wmake (api)
Content types
api
-
4-digit year-month (YYMM) integer corresponding to the major release or in unusual cases an intermediate release.
-
Format is year-month, as per
date +%y%m. Eg,1712for the Dec-2017 release.
patch
-
6-digit year-month-day (YYMMDD) integer corresponding to a patch-level for the given released API. Development branches have a patch value of
0. -
Format is year-month-day, as per
date +%y%m%d. -
The first release is by definition unpatched, and thus carries a patch value of
0. If this release were to be patched the following day, the patch level would jump accordingly.
The patch value is only meaningful together with the api value.
Flow of information
Changes in the build information must be reflected in information available in the final binaries. Conversely, it is necessary for later distributions to have a record of the same information.
| property | source | saved |
|---|---|---|
| api | wmake/rules | api-info |
| patch | manual (api-info) | build-info |
| branch | git | build-info |
| build | git | build-info |
The command wmakeBuildInfo -check is used to determine if
the saved information needs synchronization. The command
wmakeBuildInfo -update preforms the synchronitzation.
Notes
The saved information is split into two separate files. The api-info
contains more permanent information, whereas the build-info is more
transient in nature.
2018-11-29