Do not use macros if libscip is a shared library.

[kkofler]

The macros are not binary-compatible across different versions of libscip, whereas the functions are. (That is because the macros poke directly in structures whose layout changes from version to version, because members are added and/or removed in the middle of the structure.) So force JSCIP to always call the out-of-line functions instead of the macros unless libscip is a static library (in which case the macros are safe to use). (In that case, the static library has hopefully been built with position-independent code enabled, but that is a different matter, and we cannot easily check that here.) This should make libjscip keep working if you swap the libscip under it, instead of silently returning nonsense values for SCIPinfinity(). The performance hit should be minimal, because this only affects calls from Java, which go through 3 layers of Java wrappers (Scip, SCIPJNI, and SCIPJNIJNI) and 1 JNI call either way, so 1 C/C++ function call is not going to be a big hit.

CMakeLists.txt: Check whether SCIP is a static library (in which case it is safe to use macros), define -DHAVE_STATIC_LIBSCIP=1 in that case.

src/scipjni.i: #ifndef HAVE_STATIC_LIBSCIP, #undef any relevant macros (with an #ifdef check because some compilers warn about #undef-ing already undefined macros), also #define the BMS ones because the functions are named differently (with a _call suffix) in that case. This ensures that, if libscip is a shared library, we use function calls instead of the macros.

src/scipjni_wrap.cxx: Regenerate.

[kkofler]

(This is a significant enough change that I would like some feedback before merging it, hence the pull request.)

[ambros-gleixner]

This makes sense to me, but I would like to pass this on to @fschloesser for a review, since she takes care of the build system in SCIP, too.

[fschloesser]

I have no comments, looks good!

[kkofler]

Thanks! Merged.