Linking unoptimized user code against release deal.II

[Kyle Schwiebert]

Hi everyone,

I will try to be brief. I have a hopefully quick question for those in the know that has been bothering me for some time now:

I often have an issue purely in my application code that clearly has nothing to do with violating the API expectations of deal.II. A super simple example would be a loop that accidentally accesses some std::vector out of range. I then run in Valgrind and find I have some memory issue. Next, I want to jump in GDB and see what's up. Unfortunately:

1) When I link against DEBUG deal.II, deal.II is running a bunch of checks that I already know will pass since the issue is purely in application code. Additionally, for some reason, when using locally built versions of deal.II rather than the binaries from the a package manager, there is so much debug information that gets loaded in GDB, that my computer can run out of memory and crash. That's probably a seperate issue that I'm not asking for anyone to address right now; just part of why I'm asking this question.

2) When I link against RELEASE deal.II, I cannot stop dealii_setup_target from injecting "-O2" into the gcc calls. So then I can't really investigate my code. I've tried various -DCMAKE... and -DDEAL_II... variations to no avail. I even tried manually tinkering with CMakeCache.txt.

The above can make debugging application code much slower than it needs to be. Can anyone offer some help?

In my humble opinion, I think this information would be something that would be really helpful to put in an early tutorial step. When you get a helpful debug assert it's great, and that and the documentation are features I love about deal.II. When you aren't getting an assert because the issue is "purely" in application code, building against DEBUG deal.II seems to slow down the compile->run->edit loop quite a bit. Sorry if I'm missing some existing documentation and thanks again.

-Kyle

[Matthias Maier]

Hi,

Yes, the deal_ii_setup_target() macro sets compile flags on the target.
For context, the entire

find_package(deal.II ...)
deal_ii_initialize_cached_variables()
project(... CXX)
deal_ii_invoke_autopilot() or deal_ii_setup_target()

is meant for simple projects where we will set up compiler, compiler
flags, debug and release flavors and some custom targets.

If you don't want that behavior, then you cannot use the
deal_ii_initialize_cached_variables() / deal_ii_invoke_autopilot(), or
deal_ii_setup_target() macros.



I suggest to simply write a custom CMakeLists.txt as follows:

make_minimum_required(VERSION 3.20)

set(CMAKE_CXX_FLAGS_DEBUG "-Og -ggdb" CACHE STRING "")
set(CMAKE_CXX_FLAGS_RELEASE "-O3" CACHE STRING "")
set(CMAKE_BUILD_TYPE "Debug" CACHE STRING "")

project(step CXX)

# call find_package after project() so that targets get included:
find_package(deal.II 9.7.0 REQUIRED
HINTS ${deal.II_DIR} ${DEAL_II_DIR} ../ ../../ $ENV{DEAL_II_DIR}
)

add_executable(test test.cc)
target_link_libraries(test dealii::dealii_release)



This will allow you to switch between Debug and Release build will
always linking against the release library. Similarly, you can always
link against the debug library via

target_link_libraries(test dealii::dealii_debug)

or switch between the two depending on Debug / release via

target_link_libraries(test debug dealii::dealii_debug optimized dealii::dealii_release)



Important: the dealii::dealii_debug and dealii::dealii_release targets
will enforce preprocessor definitions and compile flags that are
necessary for ABI compatiblity. That means if you compile and link
against the debug variant of deal.II we will force -DDEBUG and if you
compile and link against the release variant of deal.II we will force
-DNDEBUG.

So, use a different preprocessor macro to compile in your debug code
paths - you cannot use "#ifdef DEBUG" when compiling against the deal.II
release variant.



Best,
Matthias

[Kyle Schwiebert]

Matthias,

Thank you for the reply. In retrospect such a solution should have been obvious. I knew upon getting an answer that I would feel that way. I appreciate you calling out the #ifdef issue. That's helpful to know about.

On the other hand, I always got the impression that the deal.II cmake macros were doing some "magic" and that would make it difficult or impossible to roll my own. I'm thinking of something like Kokkos which needs to wrap compilers and so on. (Not that I'm an expert there in any way. I'm sure there there are also ways to "roll your own" as well.) Maybe including an example that does not use the deal.II cmake macros here would be helpful. Perhaps just a comment that these macros are a convenience and not a necessity. Maybe such a comment would only be helpful for people in a narrow range of CMake experience--enough to want to change something--not enough to know better how to investigate. There are doubtless very good reasons not make any changes. I'll leave it to the developers' judgement.

Thanks again.

Regards,

Kyle

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "deal.II User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dealii/nYjSWkURWJk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dealii+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dealii/87ikflygrk.fsf%4043-1.org.