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
On Fri, Nov 7, 2025, at 09:12 CST, Kyle Schwiebert <[email protected]> wrote:
> 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
--
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 the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/dealii/87ikflygrk.fsf%4043-1.org.
