Coder Social home page Coder Social logo

Comments (16)

waruqi avatar waruqi commented on August 18, 2024

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.

from xmake.

LostTime76 avatar LostTime76 commented on August 18, 2024

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

Thanks

from xmake.

LostTime76 avatar LostTime76 commented on August 18, 2024

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

from xmake.

LostTime76 avatar LostTime76 commented on August 18, 2024

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?

from xmake.

waruqi avatar waruqi commented on August 18, 2024

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

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

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

from xmake.

LostTime76 avatar LostTime76 commented on August 18, 2024

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?

from xmake.

waruqi avatar waruqi commented on August 18, 2024

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

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

then bind this package to toolchain.

set_toolchains("my_muslcc@muslcc")

from xmake.

LostTime76 avatar LostTime76 commented on August 18, 2024

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.
image

image

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

from xmake.

waruqi avatar waruqi commented on August 18, 2024

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

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

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

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

from xmake.

LostTime76 avatar LostTime76 commented on August 18, 2024

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

from xmake.

waruqi avatar waruqi commented on August 18, 2024

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")

from xmake.

waruqi avatar waruqi commented on August 18, 2024

like llvm toolchain

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

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

from xmake.

LostTime76 avatar LostTime76 commented on August 18, 2024

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.

from xmake.

waruqi avatar waruqi commented on August 18, 2024

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.

from xmake.

LostTime76 avatar LostTime76 commented on August 18, 2024

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.

image

from xmake.

waruqi avatar waruqi commented on August 18, 2024

you should add find_iccarm.lua to find it.

then call lib.detect.find_tool, it will call find_iccarm.lua

https://github.com/xmake-io/xmake/tree/dev/xmake/modules/detect/tools

from xmake.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.