improve(toolchain): enhance gcc/clang support for cross-compilation

[romeoxbm]

This PR patches the built-in gcc and clang toolchain files to properly support cross-compilation by prepending the appropriate target prefix to the toolset. This avoids the need for custom toolchain definitions in many common scenarios and allows xmake to correctly pick up the expected cross tools.

After implementing this, I noticed that xmake already provides a dedicated cross toolchain. However, that implementation seems to mainly support gcc and may not cover more advanced setups (e.g., clang-based cross builds). It would be good to get maintainer input here, as my changes might overlap or partially conflict with that toolchain.

[gemini-code-assist]

Summary of Changes

Hello @romeoxbm, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances xmake's built-in GCC and Clang toolchain support for cross-compilation. It refactors the Clang toolchain configuration to centralize logic and introduces robust cross-compilation detection and toolset prefixing for both GCC and Clang. These changes aim to reduce the need for custom toolchain definitions and ensure xmake correctly identifies and uses cross-compilation tools, particularly for Linux targets.

Highlights

• Centralized Clang Toolchain Configuration: The Clang toolchain's on_load logic has been refactored, moving LTO settings, architecture-specific flags (-m64, -m32), and Windows runtime configurations from xmake.lua to load.lua. This improves modularity and consolidates configuration logic.
• Enhanced Cross-Compilation Detection and Toolset Prefixing: Both GCC and Clang toolchains now include robust logic to detect cross-compilation scenarios. They introduce an early exit if the host and target architectures match, preventing unnecessary configuration. For cross-compilation, the GCC toolchain now prepends the appropriate target prefix (e.g., x86_64-linux-gnu-) to compiler and linker commands for Linux targets.
• Improved Architecture-Specific Flag Handling: The Clang toolchain now explicitly adds march flags (-m64, -m32) to various compiler and linker flags (cxflags, mxflags, asflags, ldflags, shflags) based on the target architecture, ensuring correct compilation settings.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors the clang toolchain configuration by moving logic from xmake.lua to load.lua and enhances both gcc and clang toolchains with automatic cross-compilation support. The changes infer the target toolset from the architecture and platform, simplifying cross-compilation setups.

While the overall direction is good, I've found a critical issue in the clang toolchain's load.lua where an early return for native builds breaks compilation on Windows by skipping essential Visual Studio environment setup. I've also suggested a minor refactoring in the gcc toolchain for better code clarity. Please address the critical issue to ensure native builds are not broken.

[gemini-code-assist]

This early return for native builds (host_arch == target_arch) is problematic. It causes the toolchain to skip crucial configuration steps that follow, such as setting up the Visual Studio environment for clang on Windows. This breaks native builds with the clang toolchain on Windows.

The logic should be restructured to only print a message for cross-compilation, without exiting early for native builds, allowing the subsequent configuration to always run.

    if host_arch ~= target_arch and option.get("verbose") then
        cprint("${bright yellow}cross compiling from %s to %s", host_arch, target_arch)
    end

[gemini-code-assist]

For better readability and to make the logic more explicit, it's better to separate the early exit for native compilation from the verbose logging for cross-compilation. The elseif here implicitly depends on the failure of the first if condition, which can be slightly confusing to read.

        if host_arch == target_arch then
            -- Early exit for native compilation, as the rest of the logic is for cross-compilation.
            return
        end

        if option.get("verbose") then
            cprint("${bright yellow}cross compiling from %s to %s", host_arch, target_arch)
        end

[waruqi]

The clang/gcc toolchain is only designed to support the host platform. Please use the cross toolchain.

it will break many things. e.g. packages, toolchain cross state, ...

xmake/xmake/modules/private/utils/toolchain.lua

Line 28 in 888f5c3

if name:startswith("clang") or name:startswith("gcc") or name == "llvm" then

xmake/xmake/modules/package/tools/cmake.lua

Line 99 in 888f5c3

function _is_toolchain_compatible_with_host(package)

and other places.

[waruqi]

In addition, the cross toolchain is bound to the cross platform (xmake f -p cross), and many cross-compilation logics rely on the judgment of if is_plat("cross").

e.g. install all packages (cross-compilation)

So, please specify xmake f -p cross to do cross-compilation.

[romeoxbm]

Thanks for the clarification!

The idea that something might be amiss with the current cross-compilation behavior originated from examining the Clang toolchain. In the load.lua file, I noticed the use of the --target option, but that file was only imported on Windows and MinGW. That seemed unusual to me, which is why I initially thought extending that logic more generally might be the right approach.

That said, I completely understand your point about the cross toolchain being the intended way to handle these cases, and why modifying the built-in gcc/clang toolchains could break existing assumptions around is_plat("cross") and package/toolchain states.

One thing I did notice, though — unless I’m missing something — is that the cross toolchain seems to rely primarily on GCC. In my case, and I suspect for others as well, using GCC is not always an option since I also need to cross-compile with other compilers such as Clang or MSVC.

I’ll take a closer look at the cross toolchain implementation and the files you pointed out to better understand how xmake handles cross-compilation internally. I definitely don’t want to push changes that could disrupt existing workflows.

[waruqi]

If you use gcc to cross-compile, you can use the cross toolchain. No need to modify the gcc toolchain.

msvc also supports cross-compilation, just need to modify the arch. e.g. build arm64 on x86_64

If you want to improve the clang toolchain to support building other arch products, you can do so, but the premise is that you don't break the existing logic. It may need to be supported in many other places, such as the ones I just mentioned.

Cross toolchain currently mainly supports gcc, because most embedded cross-compilation toolchain SDKs are based on gcc

In addition, mingw toolchain is also cross-compiled, but it is handled by mingw platform.

[waruqi]

Therefore, I think you should just improve the clang toolchain and modify some of the clang handling in package.tools and so on.

Perhaps we also need to improve toolchain:is_cross()

https://github.com/xmake-io/xmake/blob/dev/xmake/core/base/private/is_cross.lua

[waruqi]

And llvm toolchain. https://github.com/xmake-io/xmake/blob/dev/xmake/toolchains/llvm/xmake.lua

• clang toolchain: clang on system, e.g. /usr/bin/clang, /usr/local/bin/clang-17, clang-18, clang-xx with system ar.
• llvm toolchain: full llvm tools, use llvmsdk/bin/clang + llvmsdk/bin/llvm-ar (first) , we need xmake f --sdk=/llvmsdk to detect it.

Therefore, I think if we want to make clang support cross-compilation, it might be better to improve the llvm toolchain to add other platform targets to support it instead of clang toolchain.

xmake f --toolchain=llvm -arch xxx --sdk=/xxx

[romeoxbm]

Thanks for the detailed clarification — it's very helpful to understand the current expectations around cross-compilation support.
In my case, I need cross-compilation to work with MSVC, GCC, and Clang. What feels confusing to me is that the way xmake handles cross-compilation seems to differ quite a bit depending on the toolchain:

• With MSVC, simply setting the architecture is enough. For example (assuming I'm building on x64):

xmake f -p windows -a arm64 --toolchain=msvc

works out of the box without needing to use the cross platform or toolchain.

• For GCC, from what I understand, the expected approach is to explicitly specify -p cross --toolchain=cross.

• For Clang, it seems to require yet another approach, which adds to the feeling of inconsistency. Each compiler currently needs a different set of command-line options to achieve what is conceptually the same goal (cross-compilation), which makes the UX harder to reason about.

I also have some doubts about the role of the cross platform and toolchain in this whole picture, since their usage doesn’t seem uniform across toolchains.

Regarding improvements: I'll definitely take a closer look at the LLVM toolchain, as well as the other places you pointed out, to better understand how xmake currently handles cross-compilation internally before making any further changes.

My main goal here would be to help make cross-compilation behavior more consistent across toolchains, so that specifying -a <arch> would ideally work similarly whether the compiler is MSVC, Clang, or GCC (or any other supported).