-
-
Notifications
You must be signed in to change notification settings - Fork 773
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
Please add support for IAR ARM embedded toolchain #5344
Comments
We can set it as gcc If the unknown compiler is gcc/clang-like. e.g 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. |
How do I open a feature request? I thought this was the request. Thanks |
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 |
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? |
if it use gcc-like compiler, it will use xmake/xmake/modules/core/tools/gcc.lua Line 869 in 6040012
We can't use other flags unless we add native iar compiler support. |
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? |
You can refer some previous patches
We can make toolchain as a package, and use
then bind this package to toolchain.
|
you can use like toolchain:config("vs") will get it. xmake/xmake/toolchains/msvc/check.lua Line 31 in 7811d6e
|
That is it! Many thanks. Will work through some more. |
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") |
like llvm toolchain xmake/tests/projects/package/toolchain_llvm/xmake.lua Lines 2 to 7 in 7811d6e
xmake/xmake/toolchains/llvm/check.lua Line 89 in 7811d6e
|
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. |
Using packages, we can still use the system's installed toolchain, and 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 While it is possible to do this with
|
IAR is a proprietary compiler that costs a lot of money. Users will never be able to just install it automatically remotely if it is not on the system. Ever. This is absolutely not in the same vein as all the other open source and downloadable toolchains supported within xmake. However, if you are saying there is a mechanism to just try and use one that is already installed in this system, while following your preferred method, we can do that. The user will never be able to "on_install" for the IAR toolchain. I have another question. I am using the following code to try and discover a directory path to iccarm.exe. No matter what I put into the first parameter, I always get out nil. I am working on windows and do not understand why this function is not finding the directory. iccarm.exe is within my environment PATH. |
you should add then call https://github.com/xmake-io/xmake/tree/dev/xmake/modules/detect/tools |
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.
The text was updated successfully, but these errors were encountered: