Please add support for IAR ARM embedded toolchain

[LostTime76]

Is your feature request related to a problem? Please describe.

I was trying to develop a script for a custom toolchain, but after looking at the code, it does not seem xmake supports a toolchain with tool names like iar -> iccarm, ilinkarm, etc..

Describe the solution you'd like

Support for the IAR ARM embedded toolchain

Describe alternatives you've considered

Developing custom toolchain scripts

Additional context

Willing to develop custom toolchain scripts within the project if direct support cannot be added, but don't know how, seems like IAR tool names cannot be supported.

[waruqi]

We can set it as gcc If the unknown compiler is gcc/clang-like. e.g set_toolset("cc", "gcc@ccmips")

If it's not a gcc/clang compiler, then you need to open a feature request or a pr to make xmake to support it.

[LostTime76]

How do I open a feature request? I thought this was the request.

Thanks

[LostTime76]

I don't mind adding support and a PR myself if its possible. I am looking into the xmake source code to see if I can do it, following the toolchains templates

[LostTime76]

Seems like gcc might be a fit, but I am having trouble figuring out how to get xmake to generate header dependencies for my compiler and use them. My compiler can generate header deps in various forms, but it does so with a flag that is not -MMD.

I had thought xmake had its own dependency scanner for header files, but this does not seem to be the case? How do I get xmake to use a custom flag to the compiler to generate header dependencies and then subsequently use the generated file?

[waruqi]

if it use gcc-like compiler, it will use -MMD

xmake/xmake/modules/core/tools/gcc.lua

Line 869 in 6040012

compflags = table.join(compflags, "-MMD", "-MF", depfile)

We can't use other flags unless we add native iar compiler support.

[LostTime76]

Yes, I have found that out. I am attempting to add support, but it doesn't seem there is a lot of documentation on how to do so, so I am having to reverse engineer the code using print statements...

For the embedded toolchain, it is very important to have the ability to 'lock' the toolchain to a specific version for compilation. For example, many projects can be using the same toolchain, but require different versions of it depending on the project. The user then has multiple versions installed on the system.

I want to be able to allow the user to set the toolchain version in their xmake.lua file for the project; however, it looks like I cannot add options in the toolchain xmake file to supply defaults. I don't want the user to have to define the option using their xmake file.

option() does not work within the toolchain .xmake file to define default options which the user can set. How do I supply these?

[waruqi]

Yes, I have found that out. I am attempting to add support, but it doesn't seem there is a lot of documentation on how to do so, so I am having to reverse engineer the code using print statements...

You can refer some previous patches

• Add armcc/armclang support for Keil/MDK #1773
• add keil-c51 toolchain & rules & review #2349
• add icx toolchain #2498

We can make toolchain as a package, and use add_requires to install specific version toolchain package.

xmake/tests/projects/package/toolchain_muslcc/xmake.lua

Line 33 in 7811d6e

add_requires("muslcc")

then bind this package to toolchain.

xmake/tests/projects/package/toolchain_muslcc/xmake.lua

Line 36 in 7811d6e

set_toolchains("my_muslcc@muslcc")

[LostTime76]

I think I understand that as I am working through it. What I don't find is the ability for the user to select a toolchain version through their xmake.lua file. I think we should be able to provide default options through the toolchain that the user can set within their xmake.lua file. The user should not have to define the options themselves... they should be provided by the toolchain.

The toolchain can then find the respective version of the toolchain during the search

[waruqi]

you can use set_toolchains("iararm", {version = "9.3"})

like set_toolchains("msvc", {vs = "2022"})

toolchain:config("vs") will get it.

xmake/xmake/toolchains/msvc/check.lua

Line 31 in 7811d6e

local vs = toolchain:config("vs") or config.get("vs")

[LostTime76]

That is it! Many thanks. Will work through some more.

[waruqi]

However, this assumes that multiple versions of the ivar toolchain are already installed on the user's system environment.

I would recommend making ivar as a package in the way I described earlier. Then we can choose as many toolchain versions as we want, and we just need

add_requires("iararm 9.3")

set_toolchain("@iararm")

[waruqi]

like llvm toolchain

xmake/tests/projects/package/toolchain_llvm/xmake.lua

Lines 2 to 7 in 7811d6e

	add_requires("llvm 14.0.0", {alias = "llvm-14"})
	target("test")
	set_kind("binary")
	add_files("src/*.c")
	set_toolchains("llvm@llvm-14")

xmake/xmake/toolchains/llvm/check.lua

Line 89 in 7811d6e

for _, package in ipairs(toolchain:packages()) do

[LostTime76]

I am not sure I understand the benefit of what you are proposing. Why can't I make a single toolchain that supports all installed versions on the user's system and by default selects whatever is within the user's path? All versions must support a base feature set of command line arguments. If the user is using a specific version of the compiler that doesn't support specific flags, they simply won't pass them to the compiler in their xmake.lua.

[waruqi]

Using packages, we can still use the system's installed toolchain, and add_requires("llvm") will prioritize the selection of the specified version from the system for use via on_fetch. It also has the added benefit that we can download and install the toolchain remotely, even if the user does not have it installed.

https://github.com/xmake-io/xmake-repo/blob/7169f79cf3d705c228fc40ac70a8c441cba25579/packages/l/llvm/xmake.lua#L123

https://github.com/xmake-io/xmake-repo/blob/7169f79cf3d705c228fc40ac70a8c441cba25579/packages/l/llvm/fetch.lua#L22

If we don't implement on_install for packages and just implement on_fetch, then it will only use the toolchain that is already installed on the system.

At the same time, we still need to define the toolchain to bind to the package, so there's no conflict.

Alternatively, we can configure add_requires("llvm 14.x", {system = true}) to force the toolchain to use the system installed toolchain instead of downloading it remotely.

While it is possible to do this with set_toolchains("llvm", {version = "14.x"}), for xmake this way of managing toolchain versions is very confusing, not easy to maintain, and each toolchain needs to implement its own lookup logic. I'd like to be able to manage all toolchains in xmake-repo and be able to improve their lookup logic at any time without having to update xmake every time.

add_requires("llvm 14.x", {system = true})
-> package("llvm")/on_fetch will find 14.x llvm toolchain on user system if exists
-> set_toolchain("@llvm") bind llvm toolchain and package and use it to build target

add_requires("llvm 14.x")
-> package("llvm")/on_fetch will find 14.x llvm toolchain on user system if exists
-> if it does not exists on user system, xmake will install it, then use it.