Comments (16)
@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.
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.
Related Issues (20)
- Some tests break after OPM/opm-parser#768 HOT 1
- Initialization and restart HOT 1
- Failing test_relpermdiagnostics HOT 4
- Dereferencing of end iterator happens in initStateEquil.hpp
- test_pinchprocessor is broken? HOT 3
- opm-core build fails HOT 4
- parameter's ouput does not show up in .CASE_NAME.DEBUG HOT 2
- Allow passing the size of the initial time step to adaptive time stepper HOT 1
- Runtime failure in "linsolver" test - umfpack not configured HOT 2
- Add restart test with no wells present.
- WellState::init has memory problems HOT 7
- Don't we need to keep track of (artificially) shut completions in the simulator for output? HOT 3
- Windows Installer (guide) failed HOT 3
- Compilation error due to not finding opm/output/data/Wells.hpp HOT 2
- Broken test HOT 3
- Multiple definitions of OPM_THROW HOT 1
- opm-core broken related to petsc HOT 2
- Some files missing? HOT 2
- Question: How OPM handles well sources in multi-cell wells? HOT 4
- Installing OPM in CentOS 8.1 (RPM) HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from opm-core.