This was discussed for around 45 minutes on the tech call yesterday. I feel someone needs to summarise things since Hongxu wasn't there and we are at a bit of an impasse.
There is a proposal that all debug options should have individual PACKAGECONFIG options. I can see why that is attractive, I can also see potential issues. It means we need a way of merging "global" PACKAGECONFIG options into "recipe specific" ones. There are long standing issues with default values of PACKAGECONFIG (with '=', '?=' or '??='), how to modify for target/native specifics and adding in a need for "global" settings with overrides would probably result in an intermediate variable anyway, which is what it was originally trying to avoid. I am also concerned that PACKAGECONFIG is effectively implemented in inline python, which is slow from a parsing perspective and hard to optimise later. It could use "contains" support to mitigate some of that but contains support, whilst more optimised, isn't free of overhead either. I'm of the view that we should make the optimization selection a dedicated variable in it's own right. Adrian did comment that this would be preferred from the SDK/IDE perspective which can handle that more easily. I did also suggest that the built type options for meson and cargo should become PACKAGECONFIG options as that would make more sense. Most people don't enable these system wide. There was an argument made that end users want to enable "all debug" and ask for this. I maintain that this isn't what they really want and upon discussion it was noted they actually create a debug profile, also enabling for example kernel tracing or adding tools to images. From that perspective, I still maintain that DEBUG_BUILD is misleading and does not help end users as it is unclear which things it does and does not do. We can better serve users with options with a clear use and functionality. There was also discussion about whether the 'tweaks' for debug optimisations should be in recipes or whether they should be in a central include file. There are pros and cons to both. Having centrally makes the scale and areas of the issues clear and gives a clear task list of things we ideally need to fix. It also removes the conditional overhead from the standard builds and only the users of it hit that overhead. It does however disconnect it from the recipes and is therefore less obvious to maintainer and people changing the recipe. Personally, I'm still leaning to an include_all standard for these rather than continuing to clutter the recipes with them (which is where this series started out). What we did all agree on is that individual recipe selection of debug optimisation is important and we need to retain that. The differing views on elements of this does create a bit of an impasse on how to proceed, as I maintainer I probably have to make a decision and upset someone... Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2230): https://lists.openembedded.org/g/openembedded-architecture/message/2230 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]] -=-=-=-=-=-=-=-=-=-=-=-
