Resent-Date: Wed, 28 Jan 2026 10:36:27 -0800
Resent-From: peter.kjellerstedt@axis.com
peter.kjellerstedt=axis.com@lists.openembedded.org
openembedded-architecture@lists.openembedded.org, Hongxu Jia
hongxu.jia@windriver.com
During the last months, Hongxu Jia has proposed patches for how to
rework DEBUG_BUILD. It started out with the idea to collect everything
related to building for debug in a common file (debug_build.inc), but
has evolved into something more dramatic where DEBUG_BUILD is replaced
by the new variable DEBUG_OPTIMIZE.
While I understand the anticipation of being able to replace the quite
messy current solution related to DEBUG_BUILD with something better,
there are also concerns about us loosing features that it currently
supports.
This is my attempt at gathering my thoughts about how to work with
debug. I have gathered some use cases for what I believe DEBUG_BUILD
currently supports and that I expect to be able to continue to use going
forward.
First, it may be a good idea to discuss what building for debug actually
means. The obvious is to enable compiler/linker flags that make it
possible to debug the application in GDB. With the current solution in
OE Core, this is handled via the FULL_OPTIMIZATION and
DEBUG_OPTIMIZATION variables. But there is more to it than that. Often
there is also a need to build the application differently, e.g., to
enable extra debug messages. This may require that, e.g., extra
configuration flags are passed to Meson.
It is also important to reflect on when (or for what) debug is enabled.
Speaking from my own experience, I typically only enable debug for one
application at a time. Possibly with the addition of key dependencies
that I expect that I need to step into during debugging in GDB. Enabling
debug for everything just because I want to debug one application would
just be a waste of time as everything would need to be rebuilt.
Based on the above, I think it is a bad idea to rename DEBUG_BUILD to
DEBUG_OPTIMIZE. While DEBUG_BUILD may not be the best named variable, it
is an established API. And (at least to me) it is about much more than
just tweaking the compiler optimization. Every time some of our
developers come up with a new ingenious way to enable extra debugging
for their application, I always tell them to use DEBUG_BUILD instead and
key off of it. That makes it easy, “if you want to debug an application,
enable DEBUG_BUILD for it”.
Below are some use cases, with examples of how to do it using the
current version of OE Core.
Enabling debug support:
- Enable debug for everything.
DEBUG_BUILD = “1” - Enable debug for all target recipes.
DEBUG_BUILD:class-target = “1” - Enable debug for all native recipes.
DEBUG_BUILD:class-native = “1” - Enable debug for a specific recipe.
DEBUG_BUILD:pn-foo = “1”
Tweaking what happens when debug support is/isn’t enabled:
- Use the debug buildtype with Meson recipes.
DEBUG_BUILD = “1” - Build a Rust module for debug.
DEBUG_BUILD = “1” - Add extra debug related compiler flags.
DEBUG_OPTIMIZATION += “-DDEBUG” - Add extra non-debug related compiler flags.
FULL_OPTIMIZATION += “-DNDEBUG” - Add extra debug related configuration flags.
EXTRA_OEMESON += “-Dprint_debug=${@oe.utils.vartrue(‘DEBUG_BUILD’,
‘true’, ‘false’, d)}”
There is probably a lot more that can be said about how to prepare for
debugging. I hope this can be a starting point for some discussions on
how to proceed so that we can get a simpler implementation without
losing any important use cases.
//Peter
(Attachment Attached Message Part.txt is missing)