On Wed, 2026-01-28 at 18:36 +0000, Peter Kjellerstedt via
lists.openembedded.org wrote:
> 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.
We do need to discuss and agree on this since whilst I understand this
is your view on how this should work and how you use it, this does not
match the way others have evolved to use it.
There are people who enable this globally on a build for example.
There are also people who want finer grained control of "debug" since
debug means different things to different people. For many people they
would want to control compiler optimisations separately since that is
not something they might want to change for debugging, since compiling
using different optimisations may actually change the problem being
debugged. Debugging might mean including debug tools or debug packages.
Why doesn't DEBUG_BUILD turn those on too? To be clear, it shouldn't in
my opinion at least, right now, you could argue it should from the
variable name.
> 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.
It is established API, but to me, it is poor API since users don't
actually agree on what it should mean and you can argue it to mean
anything.
It is also very very old code which doesn't really work the way we'd
have written it now and doesn't follow name spacing which makes much
sense either.
> 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.
The trouble is you're approaching this from a "lets not change the API"
position and also, that you want any possible kind of debug to be keyed
off it. If we do that, we have the implementation we have today. I
think it is poor and we can do better.
My position is different in that I'd prefer to make a new API and
remove the old one, adding more granular controls that let the user
actually do what they want rather than changing many different things
and hoping for the best.
For example, recipe level debug options could be triggered off
PACKAGECONFIG options instead.
The review of the patches has been held up as I have not been able to
give this series the thought needed to make sure we get it right. I'm
not convinced about the new name DEBUG_OPTIMIZE and I'm also not
convinced we get the simplifications I was hoping for by having things
always included from base.bbclass. I have not been able to find the
time to experiment and see what else might be possible, or come up with
a better name to propose though.
I do get depressed about some of this as we have some people who want
to try and improve this, but also a lot of inertia about "established
API" which people don't want to deal with any change on. If the project
shows no ability to accept change, we will put off such contributions
and we will stagnate.
These changes did come out of some discussions where I was trying to
improve various things, such as moving debug tweaking into somewhere
more central rather than spread around the recipes in a way which
wasn't obvious or maintainable, improving some variable naming and
namespacing, changing a one size fits all approach into something more
granular and also making it move obvious to people what the impact of
setting the variable(s?) might be.
It would be very easy for me not to want to do anything further with
this, but I also think it would be a missed opportunity to make the
debug code more accessible to more people.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2217):
https://lists.openembedded.org/g/openembedded-architecture/message/2217
Mute This Topic: https://lists.openembedded.org/mt/117513031/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
