A way to query the current version of OpenFOAM during build?

Hello,

Is there a way to query the OpenFOAM System which version is currently active? For example, whether the active version is v1606+ or v1612+?

Reason for this is the fact that there are API changes between versions which are breaking builds of third-party tools (in this case, cfMesh and swak4Foam). In order to maintain backward and "sideward" compatibility for external tools, queries need to be made during the build process via macros to decide which API features are valid, available, etc...

Thank you.

Unix> echo $WM_PROJECT_VERSION

v1612+

Hello Mattijs, This method of extracting the current version only works on officially released tags. In the development version of OpenFOAM, the bashrc file which defines this variable contains:

export WM_PROJECT_VERSION=plus

The only place where I found a reference to the current version on which the code-base is based is in the file:

wmake/rules/General/general

#-------------------------------*- makefile -*--------------------------------- WM_VERSION = OPENFOAM_PLUS=1612 AR = ar ARFLAGS = cr RANLIB = ranlib CPP = cpp LD = ld

However, I need to be able to differentiate between various versions of OpenFOAM while compiling (for example) swak4Foam, because different versions of OpenFOAM (also v1606 and v1612) have changes which break the compile unless specifically detected and accounted for.

Reassigned to @mark

Hi Philippose,

Two answers for you:

• I was in discussion with @andy about this, if the master branch should be tagged as plus or v1612+. An argument for plus is that it is clearly a development version (ie, does necessarily correspond to the original release). An argument for v1612+ is that it is tagged as being an update (or not) on a particular baseline. There are probably more arguments to be found either way.

For swak4Foam, I didn't get the entire way through but hopefully enough to move forward. You may need to ping Bernhard (@bgschaid) about this too, I'm not sure how far he got with digesting my changes or if they were acceptable. My last adjustments are here: https://github.com/olesenm/openfoam-extend-swak4Foam-dev/tree/port1612 - feel free to clone, improve, mention on cfd-online, whatever.

Rather than listing all the details here, it probably makes sense to start with the git branch mentioned above (I didn't manage to figure out hg quickly enough). Please let me know how you get on (positive or negative).

/mark

BTW: if you scour through the python parsing (version file) https://github.com/olesenm/openfoam-extend-swak4Foam-dev/blob/port1612/maintainanceScripts/makeFoamVersionHeader.py , you'll see around line 180 that I also tagged v3.0+ as a 1601 release date. This means that you'd then be able to use the OPENFOAM_PLUS definition within swak4Foam for all versions.

Mentioned in commit 90be2c48

Hello Mark,

A Good day to you. Thank you very much for your response. I understand the reasons behind the version definition / differentiation between the tagged versions and the development versions.

I also noticed that the new versions of OpenFOAM have the macro definition OPENFOAM_PLUS. This might be one good way of doing things.

swak4Foam has to elegantly handle past, current and future versions of OpenFOAM, OpenFOAM+, and foam-extend along with all the different version number methodologies of each, and as you can see, the swak.H file is already beginning to look.... scary.

What really interested me the most in your response is the fact that you have already started a branch of swak4Foam for applying the modifications needed to get it to work with v1612. I had a quick look, and some of those changes are changes which I have also made in my parallel (but currently still local) hg branch. Though, the way you have implemented some of those changes differ from the way I have gone about it, and I think we can safely assume that your method would be probably the better way to go, because you have a deeper knowledge of OpenFOAM.

I think we really do need to get together with Bernhard (@bgschaid) rather than ending up with three (or more?) people working independently in the dark trying to port swak4Foam to the current (and future) versions of OpenFOAM and foam-extend.

BTW: on a side-note, I have already ported cfMesh to compile with OpenFOAM-v1612+, however, I have not done it in a backwards compatible manner yet (as in, using appropriate macros and conditional compiling). You can find this port in the following copy+branch of cfMesh:

https://github.com/philippose/cfMesh/tree/port-v1612+

Hi! Took me some time but yesterday I started to port the changes Mark did from git to the Mercurial. Looks good except that some things in swak.H had to be changed because it would have broken compilation on OF 4.1. Problem is that a change in swak.H retriggers a complete recompilation of swak4Foam so it takes some time. But I am confident that I will be able to push it later today

BTW: other people have been complaining as well https://sourceforge.net/p/openfoam-extend/ticketsswak4foam/236/

Bernhard

Very nice - thanks Bernhard!

@philippose The changes you made for cfMesh should be applicable across a very large range of OpenFOAM versions. The unallocLabelList started being phased on in favour of labelUList in 2010: https://github.com/OpenCFD/OpenFOAM-history/commit/0d176f71fc872

Not really the topic of this issue: Marks fixes to compile swak4Foam are now in the devel-branch of swak4foam and pushed to the "official" repository. Next week I'll update the docker-container https://hub.docker.com/r/hfdresearch/swak4foamandpyfoam/

Thats great news Bernhard :-)

I forked Mark's repository in Github today, and started a compile of swak4Foam on my work computer today. As you said, since it does a complete recompile, I had to leave before it was done. However, as far as I was still staring into the monitor, everything was looking good :-) It had reached a compile stage way past what I had achieved over the last two days (which was when I started porting swak4Foam to v1612+).

However, I have been thinking, and dont you think its reached a level where we should probably consider redoing the way the swak.H file handles the different versions? Maybe we can combine some of the macros together, and use the new "OPENFOAM_PLUS" variable also for the 1606 differentiation, etc...etc...

I was wondering whether we can get Henry and Jasak to put in a similar WM_VERSION entry into the wmake rules general file. If the entry is properly thought out, it would greatly reduce the effort for Third-party tools which aim to support multiple upcoming versions of each flavour of OpenFOAM. Though it wouldn't solve the issue of supporting older versions.

I would love to help out if there is something I can do. Please let me know.

@mark , thanks a lot for that very positive feedback regarding the cfMesh port. Then I should try to combine all the compiles into one generic version of cfMesh using a couple of macros.

Extend already has a FOAM_DEV defined that allows distinguishing it from the other distros (it is only a switch. But that's enough). Hrv introduced that some time ago at my request (back in the days when 1.6-dev was really based on 1.6). My favourite would be WM_PROJECT_FORK set to FOUNDATION, PLUS or EXTEND to make it consistent with WM_PROJECT_VERSION.

About swak.H: I don't see a way to fix the problem of "single point of recompilation" there: basically all the stuff set here is about differences in OpenFOAM and finiteVolume which are needed by almost every OpenFOAM-program. Cloud and thermo-stuff is already split of in separate headers. But I'm open to suggestions

As you may have guessed, when we put the extra define into the wmake rule it was designed to be easily modifiable (change the first line and the rest is automatic). Having the same information (eg, OPENFOAM_PLUS=1612) exported as an environment variable is a bit risky if you switch to an older version etc. Where it really counts (compilation and code) the compiler define seems to me to be the most reliable (works much like the __cplusplus define).

To query from the command-line directly, I now added the wmakePrintBuild -plus option, which is more or less the same as grepping the wmake rule, so that could even be used to reduce some of the python logic in swak4foam if desired.

One of the remaining difficulties I saw was in the the swak Libraries/rules/versionOptions - this is indeed fairly ugly and fairly fragile, but I have no real solution there (autoconf, cmake, m4 .... like I said, no real solution).

Status changed to closed