> -----Original Message-----
> From: [email protected]
> <[email protected]> On Behalf Of Richard
> Purdie via lists.openembedded.org
> Sent: den 29 januari 2026 00:21
> To: Peter Kjellerstedt <[email protected]>; OE Architecture
> ([email protected])
> <[email protected]>; Hongxu Jia
> <[email protected]>
> Subject: Re: [Openembedded-architecture] How to build for debug
>
> 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.
And that shall of course be supported. My problem here was that the
proposed changes seemed to more or less assume this was the only use
case (e.g., by changing the documentation to state that debugging is
enabled via a fragment rather than by setting the DEBUG_BUILD variable).
> 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.
Ok, that was not my intent. I just wanted to make sure that the use
cases that are supported today remain viable in the future. If this
involves a new and improved API for how to control debugging, then
that is perfectly fine.
>
> 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.
This makes a lot of sense.
>
> 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.
I guess I did it again. Somehow, when I comment on these kind of
problems I always seem to come across as a naysayer to any changes. :(
That really isn't the case. Promise.
However, what does trigger me is when there are breaking changes that
are not really technically motivated. In this case I consider renaming
DEBUG_BUILD to DEBUG_OPTIMIZE as such a change (since it still has the
exact functionality as it had before, even if the name may be a little
bit better). But hopefully we can find something that is better than
both DEBUG_BUILD and DEBUG_OPTIMIZE, and then this will be moot.
>
> 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.
I really do hope we can come to a solution for an improved way of
how to enable debug. So the question then is, what do we need to be
able to configure to cover all use cases? And how should it be done?
We're upgrading our platform to Whinlatter tonight. After that, I hope
that I can find some time next week to look at this. I have some ideas
that I really want to try out...
> Cheers,
>
> Richard
//Peter
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2220):
https://lists.openembedded.org/g/openembedded-architecture/message/2220
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]]
-=-=-=-=-=-=-=-=-=-=-=-
