-
Notifications
You must be signed in to change notification settings - Fork 166
gnu: Add legacy Zephyr compatibility #989
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gnu: Add legacy Zephyr compatibility #989
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On second thought, "compatibility" is probably not the best choice of word here since SDK 1.0.0 is not meant to be "compatible" with Zephyr <= 4.2.
Maybe, s/compatibility/bisectability/ ?
set(ZEPHYR_TOOLCHAIN_VARIANT "zephyr/gnu") | ||
if(DEFINED ZEPHYR_TOOLCHAIN_VARIANT_COMPILER_SUPPORT) | ||
set(ZEPHYR_TOOLCHAIN_VARIANT "zephyr/gnu") | ||
else() | ||
set(ZEPHYR_TOOLCHAIN_VARIANT "zephyr") | ||
endif() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In Zephyr-sdkConfig.cmake, set ZEPHYR_TOOLCHAIN_VARIANT to zephyr/gnu only when Zephyr sets ZEPHYR_TOOLCHAIN_VARIANT_COMPILER_SUPPORT before finding the SDK module. This will require a change to Zephyr, which is unfortunate. Ideally, we'd use some existing mechanism to detect when to make this switch.
What about using Zephyr version?
SDK 1.0.0 support will be available from Zephyr 4.3.0 (well, 4.2.99/main at this time), so we can set the default ZEPHYR_TOOLCHAIN_VARIANT=zephyr
when Zephyr_VERSION VERSION_LESS 4.2.99
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need something that changes precisely when Zephyr gets this support so that we can do SDK validation across the change. That won't align with a Zephyr version change, it will happen when the SDK compatibility patches are merged to Zephyr, and we can add this symbol at that point. We can remove it once we're done with the transition.
Yes, this is a better word choice. There's no compatibility with previous Zephyr versions as we require Zephyr changes to use the new SDK, all we're trying to do is provide a transition mechanism to enable A/B testing of Zephyr with SDK 0.17 and SDK 1.0. |
In setup.sh, add option to create symlinks from gnu/ so that paths match previous SDK versions. In Zephyr-sdkConfig.cmake, set ZEPHYR_TOOLCHAIN_VARIANT to zephyr/gnu only when Zephyr sets ZEPHYR_TOOLCHAIN_VARIANT_COMPILER_SUPPORT before finding the SDK module. This will require a change to Zephyr, which is unfortunate. Ideally, we'd use some existing mechanism to detect when to make this switch, but it needs to be synchronous with with changes in Zephyr which enable this support, and I couldn't find anything in that series which looked workable. Signed-off-by: Keith Packard <[email protected]>
The underlying test was removed, but the comment left in place. Signed-off-by: Keith Packard <[email protected]>
…isectabilty When building with Zephyr that doesn't have full SDK 1.0 support, the TOOLCHAIN_VARIANT_COMPILER variable will not be set. So, instead of checking whether that is equal to "gnu", check if it is not equal to "llvm" so that we ensure that we use the -O2 version of libstdc++ when exceptions are required. Signed-off-by: Keith Packard <[email protected]>
9e950dc
to
1af31ad
Compare
I added a commit which inverts the test for when to use -O2 with libstdc++ to preserve bisectability with the existing Zephyr bits. I also added a random cleanup commit which removes a stale comment in the Kconfig file. |
In setup.sh, add option to create symlinks from gnu/ so that paths match previous SDK versions.
In Zephyr-sdkConfig.cmake, set ZEPHYR_TOOLCHAIN_VARIANT to zephyr/gnu only when Zephyr sets ZEPHYR_TOOLCHAIN_VARIANT_COMPILER_SUPPORT before finding the SDK module. This will require a change to Zephyr, which is unfortunate. Ideally, we'd use some existing mechanism to detect when to make this switch.
Fixes #851