toolchain: rename xcc-clang to xt-clang, and add linker profile xt-ld

[dcpleung]

This renames the toolchain profile xcc-clang to xt-clang to better reflect the actual compiler being used.

This also adds a linker profile xt-ld so we can tailor support for Xtensa's linker. For now, it is simply to not pass -no-pie.

[andyross]

No complaints with this patch, but I still think we need to rethink the way we handle "gcc-like" toolchains to reduce all the cut/paste in the cmake tree.

[dcpleung]

No complaints with this patch, but I still think we need to rethink the way we handle "gcc-like" toolchains to reduce all the cut/paste in the cmake tree.

Xtensa tools tend to be way behind (like xt-ld being based on ld 2.34). The LD profile on main tracks latest binutils rather closely (as with the Zephyr SDK). So this is simply to avoid the main LD profile having incompatible changes to xt-ld.

[marc-hb]

Xtensa tools tend to be way behind (like xt-ld being based on ld 2.34). The LD profile on main tracks latest binutils rather closely (as with the Zephyr SDK). So this is simply to avoid the main LD profile having incompatible changes to xt-ld.

This is worth being stated at the top of the new file IMHO. Otherwise people will keep wondering about the duplication.

PS: thanks for the rename that was requested in #54445 and thesofproject/sof#7027, much appreciated.

[nordicjm]

No problem with the change but this seems to just instantly break anyone using xcc-clang with no deprecation notice to them or indication of how they cane update their workflow to remain compatible in the future

[tejlmand]

please deprecate so that users are made aware about this change.

[tejlmand]

Please add a deprecation warning here:

--- a/cmake/modules/FindDeprecated.cmake
+++ b/cmake/modules/FindDeprecated.cmake
@@ -50,6 +50,11 @@ if("XCC_USE_CLANG" IN_LIST Deprecated_FIND_COMPONENTS)
     set(ZEPHYR_TOOLCHAIN_VARIANT xt-clang CACHE STRING "Zephyr toolchain variant" FORCE)
     message(DEPRECATION "XCC_USE_CLANG is deprecated. Please set ZEPHYR_TOOLCHAIN_VARIANT to 'xt-clang'")
   endif()
+
+  if("${ZEPHYR_TOOLCHAIN_VARIANT}" STREQUAL "xcc-clang")
+    set(ZEPHYR_TOOLCHAIN_VARIANT xt-clang CACHE STRING "Zephyr toolchain variant" FORCE)
+    message(DEPRECATION "ZEPHYR_TOOLCHAIN_VARIANT 'xcc-clang' is deprecated. Please set ZEPHYR_TOOLCHAIN_VARIANT to 'xt-clang'")
+  endif()
 endif()
 
 if("CROSS_COMPILE" IN_LIST Deprecated_FIND_COMPONENTS)

[dcpleung]

Added.

[marc-hb]

this seems to just instantly break anyone using xcc-clang with no deprecation notice to them or indication of how they cane update their workflow to remain compatible in the future

This is exactly why it's being done now while very few people and machines are just getting started with xt-clang; before the backwards incompatibility situation you describe happens.

[nashif]

This is exactly why it's being done now while very few people and machines are just getting started with xt-clang; before the backwards incompatibility situation you describe happens.

we have been using xt-clang for quite a while, deprecation is still needed./

[nordicjm]

This is exactly why it's being done now while very few people and machines are just getting started with xt-clang; before the backwards incompatibility situation you describe happens.

It doesn't matter if it's 0, 1 or half of europe using it, you can't just silently break a whole setup by changing the name without having some level of warning to users for a period of time until it is removed.

[marc-hb]

It doesn't matter if it's 0, 1 or half of europe using it, you can't just silently break a whole setup by changing the name without having some level of warning to users for a period of time until it is removed.

Some level of warning is required and it does matter for how many people it breaks.

[galak]

so probably better to just copy the files over to xt-clang and leave the xcc-clang files

[dcpleung]

The snippet posted by @tejlmand above should provide the necessary deprecation warning.