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.

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/foamEtcFile in any consistent manner.

changed the description

Opinions? @andy, @Mattijs

mentioned in commit 92d0798d

mentioned in commit 7675954c

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

mentioned in commit c26bb12f

mentioned in commit 1cbacc7d

mentioned in commit c3a62be4

mentioned in merge request !222 (merged)

mentioned in commit 3edc9b64

mentioned in commit 21fb3acc

mentioned in commit f17551e5

mentioned in commit 1179bfa6

mentioned in commit f21af7ac

mentioned in commit 55b81cb0

mentioned in commit f308aa61

mentioned in commit 7384152e

mentioned in commit 4db2fd78

closed