modules: hal_rpi_pico: set -std=gnu11 in a more toolchain independent way.
#89822
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
RobinKastberg
changed the title
-std=gnu11 in a more toolchain independent way.
github-actions
bot
added
platform: Raspberry Pi Pico
|
Just saw that my commit message is bad. Lemme fix that first. |
ajf58
approved these changes
May 16, 2025
soburi
requested changes
May 17, 2025
Set `-std=gnu11` in a more toolchain independent way. Signed-off-by: Robin Kastberg <[email protected]>
RobinKastberg
force-pushed
the
iar-pico-gnu11
branch
from
15e4c70 to
14c1dff
Compare
soburi
approved these changes
May 19, 2025
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The hardcoded flag in #84974 causes some issues with IAR.
This tries to set
-std=gnu11in a more toolchain independent way.Trying to fix this to start work on
hal_rpi_picousing IAR toolchain.I tried doing in the "proper cmake way", there are a couple of other ways, but I don't have experience enough in these parts to have an opinion:
zephyr_library_property?if(CMAKE_C_COMPILER_IDI'm not sure that mixing and matching C++ versions in the same linking unit is wise anyway?
And if #30105 goes through, maybe we can have the right version globally?