You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE] move debug and optimization to global configs in cmake #3467
Is your feature request related to a problem? Please describe.
Allow optimizations to be globally configurable, as they should be, we should not be enforcing anything on the developer
Describe the solution you'd like
move to cmake vars/env vars
I think we can do more work on this once we stop running Cmakes both with and without kconfig. If it's only with kconfig values set then we can adjust things as necessary
@cujomalainey I think we have the global debug/optimisation configs in kconfig today but there may be one or tow places where it's hard coded in cmake. Would using only kconfig work here for you to set the cmake vars ?
I don't think so, sorry. I had a very quick look a long time ago and it seemed to require significant CMake surgery. I'm familiar with CMake but not with our CMakeLists.txt files.
Activity
lgirdwood commentedon Sep 25, 2020
@jajanusz fyi.
lgirdwood commentedon Jan 12, 2021
@cujomalainey I guess this is still WIP since Janusz has left Intel ? IIRC I've seen one or two PRs to help here but assume we need more ?
cujomalainey commentedon Jan 13, 2021
I think we can do more work on this once we stop running Cmakes both with and without kconfig. If it's only with kconfig values set then we can adjust things as necessary
lgirdwood commentedon Jan 14, 2021
@cujomalainey I think we have the global debug/optimisation configs in kconfig today but there may be one or tow places where it's hard coded in cmake. Would using only kconfig work here for you to set the cmake vars ?
cujomalainey commentedon Jan 15, 2021
Thanks, once #3617 is complete i can go around and fixup hardcoded flags where i find them
lgirdwood commentedon Jan 18, 2021
@marc-hb do you think you can fix #3617 this week ?
marc-hb commentedon Jan 19, 2021
I don't think so, sorry. I had a very quick look a long time ago and it seemed to require significant CMake surgery. I'm familiar with CMake but not with our CMakeLists.txt files.
bkokoszx commentedon Jan 27, 2021
@cujomalainey Regarding #3467 (comment) comment - will you be able to take a look at this after #3617 gets merged?
cujomalainey commentedon Jan 27, 2021
Yes, this should be much easier
lgirdwood commentedon May 10, 2021
Aim is to align with how Zephyr set configuration. More of this will align in v1.9
marc-hb commentedon May 10, 2021
Just for the record: Zephyr does not use CMAKE_BUILD_TYPE.
(and .config change #3617 has been merged for some time)