inconsistency in handling of FOAMversion
Issue raised (or stumbled over) by @escrmic
The compilation scripts define Foam::FOAMversion based on the version information at compile time (eg, WM_PROJECT_VERSION=1612). Subsequent renaming of the version within the etc/bashrc (eg, WM_PROJECT_VERSION=1612.update2 or whatever) will not be respected in the internal findEtcFiles() lookups.
This can lead to a slight dichotomy since bin/foamEtcFile will use the current value of WM_PROJECT_VERSION. Thus foamEtcFile and findEtcFiles() will potentially locate different version-specific user or site files.
Child items
0No child items are currently assigned. Use child items to break down this issue into smaller parts.
Activity
Possible solution: use WM_PROJECT_VERSION instead of FOAMversion in findEtcFiles, but leave IOobjectWriteHeader.C untouched, since this corresponds roughly to the API level.
Another alternative? Could use API level only for findEtcFiles (the OPENFOAM define) since this reflects changes in behaviour and would be consistent for various patch updates, but it is not clear how this would be propagated into
bin/foamEtcFilein any consistent manner.-
Discussion with @andy right now, but should also refer it to the other @Development .
If we aim to have update releases, there still be some mismatches/ambiguities about version names. Eg, OpenFOAM-v1806 as the main release has "v1806" for its version and expects a directory of "OpenFOAM-v1806". If we shipped a patched version sometime in the future - eg, "v1806.1915" for a version that was patched for week 15 in 2019 - we need to decide how to deal with this type of thing.
-
the version "v1806.1915" really should not be influencing how the etc files are being searched, since files that work for 1806, should also be found for the update version. At the moment, the value of WM_PROJECT_VERSION is used to determine where to search, so need to move directories or use symlinks to resolve this. The only constant value is the API value, which is defined in the wmake rules.
-
we have an over or under specification of the naming. If the version is "v1806.1915", the default expected directory name is then "OpenFOAM-v1806.1915". If we want to continue using the same directory location after updating a service pack, we must manually change things.
For addressing the first part (constant value). I think this means that we indeed need to be using the compile-time API value (eg, 1806) for the searching - in the foamEtcFile script and in the foamEtcFiles() routine. The value should be extracted from the corresponding wmake rule, since this is the only reliable value we have. To make life easier for consumers of this information, the OpenFOAM environment should also export this extracted value.
For the directory naming. I think we should ditch a lot of this stuff and replace it with the bash/csh sourcing magic instead. Rather than automatically obtaining the FOAM_INST_DIR, for setting the WM_PROJECT_INST_DIR, we should just use it to grab the WM_PROJECT_DIR directly. The values returned are from
pwd -L, so they are absolute paths. Stripping off one directory level (with shell) to determine the installation directory probably makes much more sense. -
-
@gsg001 - this is also packaging related #1050 (closed)
mentioned in merge request !222 (merged)