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
Zephyr Toolchain handling is split in generic.cmake and target.cmake files.
The reason for this split is to allow loading of generic.cmake during early CMake configure time to define a set of host tools which are independent of the target build.
An example is a generic C compiler which can be used for pre-processing, but not compilation (devicetree use)
Later, when devicetree and Kconfig has been executed, all required target information is available (for example arch), then the correct set of target tools can be defined, including the correct C compiler / arch flags for the compiler invocation.
The HWMv2 adoptation for native_posix revealed that the split above is not honored as expected, see #69034 (comment)
As additional context, the current implementation makes it harder than necessary to re-use portion of Zephyr SDK infrastructure, see #71163.
This enhancement issue must address above limitations, and further make the generic/target separation clearer, so that this can be reused.
Also the need for arch/board knowledge in generic stages must be removed.
Host based targets (native(posix) and unit_testing), which defaults to the host toolchain, should do this as part of FindTargetTools.cmake ), not as part of host tools. (Although in this case the target is also the host)
The text was updated successfully, but these errors were encountered:
Zephyr Toolchain handling is split in generic.cmake and target.cmake files.
The reason for this split is to allow loading of generic.cmake during early CMake configure time to define a set of host tools which are independent of the target build.
An example is a generic C compiler which can be used for pre-processing, but not compilation (devicetree use)
Later, when devicetree and Kconfig has been executed, all required target information is available (for example arch), then the correct set of target tools can be defined, including the correct C compiler / arch flags for the compiler invocation.
The HWMv2 adoptation for native_posix revealed that the split above is not honored as expected, see #69034 (comment)
As additional context, the current implementation makes it harder than necessary to re-use portion of Zephyr SDK infrastructure, see #71163.
This enhancement issue must address above limitations, and further make the generic/target separation clearer, so that this can be reused.
Also the need for arch/board knowledge in generic stages must be removed.
Host based targets (native(posix) and unit_testing), which defaults to the host toolchain, should do this as part of FindTargetTools.cmake ), not as part of host tools. (Although in this case the target is also the host)
The text was updated successfully, but these errors were encountered: