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 <https://dealii.org/current/users/cmake_user.html#dealiiconfig> 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 On Fri, Nov 7, 2025 at 11:00 AM Matthias Maier <[email protected]> wrote: > 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 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 > [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/dealii/87ikflygrk.fsf%4043-1.org. > -- 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/CAEt%3DwjM_FyNc%2B7HW86Y_WM2aO_6y4NMM%2Bxih1hCO84aZzbxRdw%40mail.gmail.com.
