Make parts of code version dependent (check and toggle with `#ifdef`s?)
 

EDIT: tl;dr: Can I access something like $WM_PROJECT_VERSION inside C++ code to be compiled with wmake (libso)?

I am (still, sort of, part time) working on a 2D amr library and everything is moving along (slowly). When someone downloaded the source files via github, they emailed me and told me it wouldn't compile. Because of the time difference between us, they had already found the problem when I read this, and sent a second email stating that my files compiled for OF-2.3.0 (which I updated to, and made some changes to support), but not for OF-2.2.1 (I initially started writing the library in OF-2.2.2).

Now, obviously I can just write that the library will require OF-2.3.0, but since the changes are relatively small (referring to the function "topoChanging", whose implementation changed between 2.2.2 and 2.3.0), writing something along the lines of

I guess I'd need to be careful avoiding any variable declarations during these sections, since I'm guessing that would make my compiler hate me, but since I think it's just a change to the arguments passed (the old function was called changing(const bool) or changing(), returning a bool with true if the mesh was changing, or similar)

Is it possible to write code which can detect the OF version, and selectively choose a #define pre-processor command? The version is usually held in the headers of files, like the controlDict, but relying on this seems unhelpful (since it can easily be wrong, if the OF version is updated but the files are kept, or you can as far as I'm aware, just write whatever you want there...) and if I use
then I suspect it will compile in neither case, since both OF-2.3.0 and OF-2.2.2 would be missing one of the functions.

If I could define based on the existence of the function, I could possibly use
but I still need to be able to get a preprocessor token which depends on the version of OF.

Any help would be much appreciated.

And with much ado about nothing - getenv() in <stdlib.h> is likely to be something I can use to get the value of $WM_PROJECT_VERSION, which solves much of the problem.

Now just to work out if that can get me a conditional #define or #include statement (since they should occur even if in an if() branch that isn't chosen, right? :( )

Solution:

In Make/options, before my
section, use:
Then test for I guess a whole collection of further Makefile comparisons could be used to make this less specific, which I'll look into but probably not redocument here.

Link to helpful page about conditional makefile variables: http://www.chemie.fu-berlin.de/chemn...ke/make_7.html

(although once you know what you want to find, google is your friend)

Greetings Christian,

There are two implementations I'm aware of and neither are present in OpenFOAM, or at least not yet.

1. One's here: http://www.openfoam.org/mantisbt/view.php?id=293
2. Another is swak4Foam, which has its own implementation. For example, have a look into the file "Libraries/Allwmake" in swak4Foam's source code, e.g.: https://github.com/Unofficial-Extend...aries/Allwmake

Best regards,
Bruno

Dear Bruno,

Thank you for taking the time to read this and adding the links as reference.

It seems like the mantis link contains a comment (from mwild) that is roughly the same as what I've done, although it also seems like the point of the 'bug' report/feature request is to avoid doing that - "#ifdef is BAAAAD". Certainly, it does make code very "Ugly".

I confess that I'm at a loss as to how you would go about using the 'dog-tag' style code in 3rd party libraries/solvers/applications etc though. Doesn't generating a set of
inherently lend itself to writing code with lots of #ifdef and #ifndef statements?

Is the suggestion that a version dependencies file of some kind, containing only #define commands, be included everywhere? For example, taking the mathmaticalConstants idea, something like

or (but I don't think this works - MATHCONSTS will always be the case 1 define, right?)
and then use the MATHCONSTS in the rest of the code?

Hallo Christian,

I might add another source of inspiration, since waves2Foam also tries to be cross-version compatible. In waves2Foam I transform the version number to a 3 digit number and applies "==", "<" etc. booleans in the pre-processor statements.

It is not too bad with the amount of #if statements, but specifically for PI, I use M_PI instead, because it is too common to bother about the change in syntax. In waves2Foam you will also find a whole class called crossVersionCompatibility or something along those lines, which is an attempt to gather all naming changes in one place.

Good luck,

Niels

Niels,

Thank you for this suggestion - I took a look at the class you wrote and it indeed looks very useful. My current implementation is similar, but messy - implementing the changes as function calls returning 'word's is a much better plan!

Best,
Christian

Good morning,

I might add that I simply pass the integer as

and that the whole process of stripping for '.', '-' and 'x' is performed in waves2Foam/bin/bashrc(.org). Note that there are some additional flags due to a lot of changes in the 2.2.X line of version and that foam-extend runs with a higher version number, but applies and older (but not obsolete) interface for some classes and for the naming of variables.

Kind regards,

Niels