On 19. Oct. 2016 at 10:45, Bernd Flemisch wrote:
I must have different code paths to support 2016.04 and
2016.10 at the same time. Is there a way to do this? I don't
see any Opm version information written into config.h.
Personally, I like to have macros that define the version together
with the interface, for just this reason.
But these have to be *manually* updated according to the level of
changes made, and should also be combined with adherence to
semver[*]-style so-naming lest you may introduce subtle bugs if
things get out of sync.
On 14. Nov. 2016 at 17:19, Andreas Lauser wrote:
include "opm/$MODULE/version.hpp"... but as far as I know, the
build system currently does not generate these headers
There was such a file opm/core/version.h, but it was removed with
commit 7df248 in pull request 912.
An alternative way is to probe for the functionality needed, and
have the build system put this into *your* config.h
CHECK_CXX_SOURCE_COMPILES("
#include <opm/core/snafu.h>
int main (void) { Opm::Snafu snafu; return 0; }
" HAVE_SNAFUCATION)
It may also be that the find_dune_version macro in
UseDuneVer.cmake can be used to probe for the version of OPM
modules; I haven't tried that.
If the feature you need is part of your API, for instance you need
to return two different types, then things get ugly fast: I guess
the best way would have to be to generate a header with a
typedef.
--
Roland.
[*] <http://semver.org/>
_______________________________________________
Opm mailing list
[email protected]
http://opm-project.org/cgi-bin/mailman/listinfo/opm
