FIND_OPM_PACKAGE (OpmPackage.cmake) does not honour build type about opm-core HOT 16 CLOSED

@bska
I think that the core of the problem here is that there is no good convention for a library to communicate the definitions necessary to compile and link correctly. The closest thing we have is xxx_DEFINITIONS in CMake and the Cflags field in .pc files, and a problem today is that definitions added in CFLAGS/CXXFLAGS/CMAKE_CXX_FLAGS(_xxx) is not added to these, both for DUNE (check dune-common.pc) but also OPM (or me, really) is guilty of this.

Generally, one could argue that they should be, although it will surely lead to problem if one library is compiled with -DNDEBUG and another with -DDEBUG, for instance. And isn't this the case for _GLIBCXX_DEBUG too? (What happens if Boost is not compiled with this? Won't mayhem ensue?)

The downside to using CMAKE_BUILD_TYPE is, of course, that the technique will be limited to Make-based generators.

Why do you think so? Make isn't used in the configuration step.

from opm-core.

The downside to using CMAKE_BUILD_TYPE is, of course, that the technique will be limited to Make-based generators.

Why do you think so? Make isn't used in the configuration step.

No, but CMAKE_BUILD_TYPE and, consequently, CMAKE_<LANG>_FLAGS_<BUILDTYPE> are specific to make-based (i.e., single configuration) generators. Details at http://www.cmake.org/cmake/help/v2.8.10/cmake.html#variable:CMAKE_BUILD_TYPE (or cmake --help-variable CMAKE_BUILD_TYPE for that matter).

I think that the core of the problem here is that there is no good convention for a library to communicate the definitions necessary to compile and link correctly.

Sure, and it is ultimately the builder's responsibility to ensure that the set of (external) prerequisites can be combined into a consistent executable. So, while highly imperfect, respecting the build type where possible will at least allow me to solve this immediate issue. I really don't want to forgo the possibility of using _GLIBCXX_DEBUG, because it has helped me uncover (and fix) a number of latent issues that would be hard to reliably reproduce otherwise.

from opm-core.

@bska
BTW, there is some issues (probably related to having an old CMake) with parsing the dependency list which gives the messages "checking for modules 'QUIET;dune-grid'". And why is it able to find dune-geometry but not dune-grid? (no STL containers in dune-geometry?).

Could you gist the entire Configure.out so I can see the context of the failure?

from opm-core.

And why is it able to find dune-geometry but not dune-grid? (no STL containers in dune-geometry?).

That's precisely it. Or, rather, the test program for dune-geometry doesn't use any STL containers.

Could you gist the entire Configure.out so I can see the context of the failure?

Sure, updated now. Configure.out.full contains all message (STATUS) output while Configure.out.stderr contains messages printed to file descriptor 2 during configuration.

from opm-core.

No, but CMAKE_BUILD_TYPE ... are specific to make-based (i.e., single configuration) generators

You are correct. But wouldn't _GLIBCXX_DEBUG need to be specified when probing for this library also when doing the release part of the build, when using a multi-configuration generator? (haha, only kidding, you probably wouldn't use Visual Studio... :-))

from opm-core.

Or, rather, the test program for dune-geometry doesn't use any STL containers.

Aha! Maybe a simple solution here is to write a check program that doesn't use STL containers?

from opm-core.

Or, rather, the test program for dune-geometry doesn't use any STL containers.

Aha! Maybe a simple solution here is to write a check program that doesn't use STL containers?

That (check programs not using STL containers) will certainly solve/work around/paper over (strike unsuitable) the immediate issue I'm facing.

from opm-core.

@bska

Please check that you can compile&link this program (say foo.cxx)

#include <dune/grid/onedgrid.hh>
int main (void) {
    Dune::OneDGrid grid(1, 0., 1.);
    return grid.lbegin<0>(0) == grid.lend<0>(0);
}

with something like:

g++ foo.cxx $(env PKG_CONFIG_PATH=/home/bska/work/opm/inst/dbg:$PKG_CONFIG_PATH pkg-config --cflags --libs dune-grid)

from opm-core.

But wouldn't _GLIBCXX_DEBUG need to be specified when probing for this library also when doing the release part of the build, when using a multi-configuration generator?

I don't know. Possibly. I haven't tried to use the cmake system in multi-configuration mode yet.

you probably wouldn't use Visual Studio... :-)

That's true, but I was able to build and develop OPM-Core using Eclipse in the context of the Autotools setup and I'd like to try/investigate Qt Creator once i upgrade my workstation to something more recent than Ubuntu 10.04 LTS...

from opm-core.

@bska
OK, now for the smoke test before spamming with pull-requests: Try to add this patch

https://github.com/rolk/dune-cornerpoint/commit/273a75f2fcfe152677bf6f207f57cf0fd6b3d2e7.patch

to every applicable project (i.e. dune-cornerpoint, opm-porsol and opm-upscaling if you need them too)

from opm-core.

Please check that you can compile&link this program (say foo.cxx)

with something like

g++ foo.cxx $(env ...)

That works (builds), albeit with noisy message concerning --enable-fieldvector-size-is-method. I did have to use

PKG_CONFIG_PATH=/home/bska/work/opm/inst/dbg/lib/pkgconfig:$PKG_CONFIG_PATH

rather than

PKG_CONFIG_PATH=/home/bska/work/opm/inst/dbg:$PKG_CONFIG_PATH

(note addition of lib/pkgconfig), but I assume that's a minor issue.

from opm-core.

https://github.com/rolk/dune-cornerpoint/commit/273a75f2fcfe152677bf6f207f57cf0fd6b3d2e7.patch

Success!

All of opm-core, dune-cornerpoint, opm-porsol, and opm-upscaling now build (without issue) in debug mode on my system. Please open Pull Requests in all appropriate modules.

from opm-core.

By the way, I got a number of configure-time messages of the form

-- Finding package opm-core using module mode
-- Performing Test HAVE_DUNE_CORNERPOINT
CMake Warning (dev) at CMakeLists.txt:11 (TARGET_LINK_LIBRARIES):
  Link library type specifier "optimized" is followed by specifier "debug"
  instead of a library name.  The first specifier will be ignored.
This warning is for project developers.  Use -Wno-dev to suppress it.

which I haven't tried to track down. Are they a problem?

from opm-core.

OK, I'll add it as a pull-request then. For a more long-term solution: Isn't this problem reminiscent of the --std=c++11 problem; if you use it in one, it should be exported to all the others?

from opm-core.

OK, I'll add it as a pull-request then

Good. I look forward to seeing this.

For a more long-term solution: Isn't this problem reminiscent of the -std=c++11 problem; if you use it in one, it should be exported to all the others?

Yes, it probably is. There is probably some deeper insight hidden here.

from opm-core.

Fixed (or rather worked around) in #239

from opm-core.