CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Bugs

Foam Version as a compile-time macro

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   April 29, 2009, 18:35
Default Foam Version as a compile-time macro
  #1
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 386
Rep Power: 15
deepsterblue will become famous soon enough
Just a suggestion, but perhaps it would be useful to have the Foam version as a compile-time macro. For example, something like this for OF-1.5:

#define FOAM_MAJOR_REVISION 1
#define FOAM_MINOR_REVISION 5

Or something on similar lines (Maybe passed in to g++ with a -D option). Considering how member functions change over revisions, (like faceOwner instead of allOwner in polyMesh, for instance), backward compatibility is sometimes an issue. I agree that it makes code uglier because of #ifdefs all around the source code, but it might be handy to have...
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is offline   Reply With Quote

Old   May 25, 2009, 05:36
Default
  #2
Senior Member
 
Mark Olesen
Join Date: Mar 2009
Location: http://olesenm.github.io/
Posts: 777
Rep Power: 18
olesen will become famous soon enough
Quote:
Originally Posted by deepsterblue View Post
Just a suggestion, but perhaps it would be useful to have the Foam version as a compile-time macro. For example, something like this for OF-1.5:

#define FOAM_MAJOR_REVISION 1
#define FOAM_MINOR_REVISION 5
wmake already has/had a PROJECT_VERSION defined as major, 3 digits minor and 3 digits revision.
For example, 1.5 == -DPROJECT_VERSION=1005000.
Unfortunately this breaks down horribly when versions contain non-digits (eg, like 1.5.x). I would thus avoid using it at all.

IMO the better method is to keep your code up-to-date with the latest developments and use branching within git if you also need to maintain code for legacy versions. This is not only much cleanier to read than piles of #ifdefs, but also avoids strange and possibly hard to trace bugs. For example, if you'd moved from 1.5 to 1.5.x, the wrong chunk would get evaluated here:
Code:
#if PROJECT_VERSION >= 1005000
chunk1 ...
#else
chunk2 ...
#endif
I think the need for using PROJECT_VERSION disappeared with the introduction of git for version control. I wouldn't be surprised if PROJECT_VERSION disappeared in a future version, but you can copy the same idea in your own Make/options if you'd like.
olesen is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Superlinear speedup in OpenFOAM 13 msrinath80 OpenFOAM Running, Solving & CFD 18 March 3, 2015 06:36
SimpleFoam k and epsilon bounded nedved OpenFOAM Running, Solving & CFD 13 November 4, 2013 15:13
IcoFoam parallel woes msrinath80 OpenFOAM Running, Solving & CFD 9 July 22, 2007 02:58
Physical Reason for stability of Implicit Schemes? radhakrishnan Main CFD Forum 25 December 7, 2000 16:25
unsteady calcs in FLUENT Sanjay Padhiar Main CFD Forum 1 March 31, 1999 12:32


All times are GMT -4. The time now is 13:36.