search

xmake-io / xmake

🔥 A cross-platform build utility based on Lua
https://xmake.io
Apache License 2.0
10.08k stars 784 forks source link

v3.0 Roadmap #5527

Open waruqi opened 2 months ago

waruqi commented 2 months ago

If there are proposed changes that you would like to see introduced in xmake v3.0, you can submit them here.

It will be adopted if the vote result >= 80%.

we can use set_policy("compatibility.version", "3.0") or xmake f --policies=compatibility.version:3.0 to attempt v3.0

Roadmap (Adopted)

Roadmap (Draft)

24bit-xjkp commented 2 months ago

Support dynamical script load, so we can distribute some xmake scripts by packages. This would be useful when sharing some scripts between projects.

waruqi commented 2 months ago

Support dynamical script load, so we can distribute some xmake scripts by packages. This would be useful when sharing some scripts between projects.

This key point is difficult to be implemented because the package is not yet installed when it is first compiled. We can currently only distribute packages rules.

SirLynix commented 2 months ago

A better way for xmake packages to pull off info from their build xmake.lua, to avoid having to duplicate defines and such

heheda123123 commented 2 months ago

I think it is very important to improve the documentation, now the documentation of a few more serious problems 1 Even if I select Chinese in xmake.io, the search still comes up with English results 2 Some methods are not found in the documentation

KkemChen commented 2 months ago

支持对apt，pkg-config等系统库指定使用动态库或静态库

jingkaimori commented 2 months ago

elements of target

Re-consider relationship of rules, toolchains, config variables, values and policies.

Table below shows which entity can hold which element:

entity type rule toolchain config variable value policies
option v
target v v v v v
(global space) v v v v
package
xpack

Option

should option be a type of task, or just a object like value? should option checks itself?

waruqi commented 2 months ago

I think it is very important to improve the documentation, now the documentation of a few more serious problems 1 Even if I select Chinese in xmake.io, the search still comes up with English results 2 Some methods are not found in the documentation

new document, https://docs.xmake.io/en-us/index.html

But I don't have a lot of time alone to update and perfect it.

24bit-xjkp commented 2 months ago

Maybe we can use document generators like LDoc and embed the document into annotations.

Issues-translate-bot commented 2 months ago

Bot detected the issue body's language is not English, translate it automatically.

Supports specifying the use of dynamic libraries or static libraries for system libraries such as apt and pkg-config.

waruqi commented 2 months ago

Remove support for built-in variables in script scope, support it only in the description scope, Poll: https://github.com/xmake-io/xmake/discussions/5529

qudix commented 2 months ago

A way to reuse rules in a project that uses xmake, but in a package definition without duplicating work. https://github.com/shad0wshayd3-FO4/CommonLibF4/blob/master/CommonLibF4/xmake.lua#L133

If such a thing requires some modifications on the lib side, that's fine.

WubiCookie commented 2 months ago

Rename buildir to builddir

waruqi commented 2 months ago

Rename buildir to builddir

Poll: https://github.com/xmake-io/xmake/discussions/5533

A2va commented 2 months ago

For my project xmake-rs, I wanted xmake to send the resolved list of a target's links to the rust part. This way the user wouldn't need to link anything in the build.rs. To do this, I had to copy a large part of the xmake source code, my idea would be to add a target:orderlinks() function which would return a resolved list of links on a binary target. I thought about using target:linkcmd(), but the flags are different for different compilers and you'd have to parse them.

star-hengxing commented 2 months ago

Use ninja generator for cmake package by default.

waruqi commented 2 months ago

Use ninja generator for cmake package by default.

Poll: https://github.com/xmake-io/xmake/discussions/5545

jube commented 2 months ago

Add a way to really clean everything. Sometimes, I need to delete .xmake directories (and/or build directory) in order to fix a build that should work. A nice command like xmake mrproper would be nice to delete everything, as if it was a fresh installation of xmake (like on a CI).

waruqi commented 2 months ago

Add a way to really clean everything. Sometimes, I need to delete .xmake directories (and/or build directory) in order to fix a build that should work. A nice command like xmake mrproper would be nice to delete everything, as if it was a fresh installation of xmake (like on a CI).

xmake f -c will ignore all configuration cache.

SirLynix commented 2 months ago

A way to change config without having to respecify all config, maybe separate some configs such as mode from other configs. It's quite painful to work with a lot of config because of that.

KkemChen commented 2 months ago

希望option域里面 能够支持 add_rules 接口

Issues-translate-bot commented 2 months ago

Bot detected the issue body's language is not English, translate it automatically.

It is hoped that the add_rules interface can be supported in the option domain.

xq114 commented 2 months ago

希望定义option时可以直接指定default值，而不用这样再包一层 https://github.com/xmake-io/xmake-repo/blob/dev/packages/a/angle/port/6288/xmake.lua

Issues-translate-bot commented 2 months ago

Bot detected the issue body's language is not English, translate it automatically.

I hope that when defining options, I can directly specify the default value without having to wrap it up again https://github.com/xmake-io/xmake-repo/blob/dev/packages/a/angle/port/6288/xmake.lua

waruqi commented 2 months ago

希望定义option时可以直接指定default值，而不用这样再包一层 https://github.com/xmake-io/xmake-repo/blob/dev/packages/a/angle/port/6288/xmake.lua

原本就可以直接指定，这里的问题是你用了 is_plat ，想要在 option 里用，只能在脚本域。这个是本身机制决定的，没法在描述域实现

heheda123123 commented 2 months ago

跑测试的时候，是否有必要把所有的config也测试到呢？ 比如下面的pr，其实是测试不到新添加的config的 https://github.com/xmake-io/xmake-repo/pull/5115

或者说写包描述的时候可以给config添加一个字段指定是否对这个config进行自动测试

waruqi commented 2 months ago

跑测试的时候，是否有必要把所有的config也测试到呢？ 比如下面的pr，其实是测试不到新添加的config的 xmake-io/xmake-repo#5115

或者说写包描述的时候可以给config添加一个字段指定是否对这个config进行自动测试

这个不太现实，新增一个config ，排列组合下，ci 的测试 job 是数量级暴增的，一个 config 如果不是 boolean 值，是 string values 的，组合就更多， 还可能引入各种 deps 编译，没这么多资源，不仅耗时，耗ci资源，跑出问题，也没这么多人力修。

Issues-translate-bot commented 2 months ago

Bot detected the issue body's language is not English, translate it automatically.

When running tests, is it necessary to test all configs? For example, in the PR below, the newly added config cannot be tested xmake-io/xmake-repo#5115

Or when writing a package description, you can add a field to the config to specify whether to automatically test this config.

This is not realistic. If you add a new config, the number of ci test jobs will increase by orders of magnitude under the permutation and combination. Without so many resources, it will not only be time-consuming, but also consume ci resources. If problems occur, there will not be so many manpower to repair them.

TurnOffNOD commented 2 months ago

vote for Rename buildir to builddir #5533 and Improve custom toolchain to support unknown compiler/linker #5554

heheda123123 commented 2 months ago

是否考虑增加has_option/get_option相关针对option的独立api。把option和config的获取分开 现在其实是用一个has_config/get_config来获取option包括config的值，很容易有歧义，下意识去搜索option相关的api也找不到 群友也有遇到同样问题 image

waruqi commented 2 months ago

是否考虑增加has_option/get_option相关针对option的独立api。把option和config的获取分开 现在其实是用一个has_config/get_config来获取option包括config的值，很容易有歧义，下意识去搜索option相关的api也找不到 群友也有遇到同样问题 image

option 就是为 config 服务的，改不了。

Issues-translate-bot commented 2 months ago

Bot detected the issue body's language is not English, translate it automatically.

Whether to consider adding has_option/get_option related independent API for option. Separate the acquisition of option and config. Now we actually use a has_config/get_config to obtain the value of option including config. It is easy to have ambiguity. I subconsciously searched for the option-related API and could not find it. Group friends also encountered the same problem! [image] (https://private-user-images.githubusercontent.com/97490782/365031766-b4dad2ed-5588-4a53-9193-2c094543140a.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..Unu5pTwiqbZr3 XWeyaXbkOQYtvNtj6SDOJTlh9qPGco)

option serves config and cannot be changed.

jingkaimori commented 1 month ago

c51和sdcc工具链的默认plat不要设为当前系统，建议为裸机（没有系统的单片机，自立实现）添加名为bare或者standalone的目标平台plat属性值。c51工具链的默认架构arch建议也弄成mcs51，不然下面的日志太难绷：

> xmake config --clean
checking for platform ... windows
checking for architecture ... x64
checking for Microsoft Visual Studio (x64) version ... 2022
checking for Microsoft C/C++ Compiler (x64) version ... 19.40.33811
> xmake build --rebuild
[ 50%]: cache compiling.release src\main.c
[ 75%]: linking.release hello
[ 75%]: generating.release build\windows\x64\release\hello.hex
[100%]: build ok, spent 0.125s
> xmake config --toolchain=c51
checking for platform ... windows
checking for architecture ... x64
waruqi commented 1 month ago

c51和sdcc工具链的默认plat不要设为当前系统，建议为裸机（没有系统的单片机，自立实现）添加名为bare或者standalone的目标平台plat属性值。c51工具链的默认架构arch建议也弄成mcs51，不然下面的日志太难绷：

> xmake config --clean
checking for platform ... windows
checking for architecture ... x64
checking for Microsoft Visual Studio (x64) version ... 2022
checking for Microsoft C/C++ Compiler (x64) version ... 19.40.33811
> xmake build --rebuild
[ 50%]: cache compiling.release src\main.c
[ 75%]: linking.release hello
[ 75%]: generating.release build\windows\x64\release\hello.hex
[100%]: build ok, spent 0.125s

这个无解，每个 target 可以绑定多个不同 toolchain 的，而全局平台 toolchain 只有一个，跟他们独立。

你走 set_toolchain 设置，仅仅只影响 target toolchain ，不会影响 platform toolchain ，也不应该去影响它。

jingkaimori commented 1 month ago

而全局平台 toolchain 只有一个，跟他们独立。

你走 set_toolchain 设置，仅仅只影响 target toolchain ，不会影响 platform toolchain ，也不应该去影响它。

为什么全局的 toolchain 会和目标平台绑定？这个全局 toolchain 和 host 绑定可能更好吧

heheda123123 commented 1 month ago

之前用xmake构建的时候老是通不过，最后发现是因为xmake会从PATH环境变量找到我添加的工具链，混用就出错了。 为了用xmake我都是把PATH环境里面的工具链去掉，这也导致命令行连个g++都没有，有时候想写点小东西，也必须xmake创建一个项目，就很繁琐。 是否可以给全局设置里面添加一个功能让xmake忽略指定路径下的工具链，即使他在PATH环境变量里。

Issues-translate-bot commented 1 month ago

Bot detected the issue body's language is not English, translate it automatically.

When I used xmake to build before, it always failed. In the end, I found out that it was because xmake would find the tool chain I added from the PATH environment variable, and an error occurred when mixed. In order to use xmake, I always remove the tool chain in the PATH environment, which also results in the command line not even having g++. Sometimes if I want to write something small, I have to create a project with xmake, which is very cumbersome. Is it possible to add a function to the global settings to make xmake ignore the tool chain under the specified path, even if it is in the PATH environment variable?

waruqi commented 1 month ago

而全局平台 toolchain 只有一个，跟他们独立。 你走 set_toolchain 设置，仅仅只影响 target toolchain ，不会影响 platform toolchain ，也不应该去影响它。

为什么全局的 toolchain 会和_目标平台_绑定？这个全局 toolchain 和 host 绑定可能更好吧

如果这样， xmake f -p mingw 也会用 msvc 编译

waruqi commented 1 month ago

之前用xmake构建的时候老是通不过，最后发现是因为xmake会从PATH环境变量找到我添加的工具链，混用就出错了。 为了用xmake我都是把PATH环境里面的工具链去掉，这也导致命令行连个g++都没有，有时候想写点小东西，也必须xmake创建一个项目，就很繁琐。 是否可以给全局设置里面添加一个功能让xmake忽略指定路径下的工具链，即使他在PATH环境变量里。

不从 path 里找，从哪找。而且也不是所有 toolchain 都从 PATH 找，如果有问题，可以提 issues

Issues-translate-bot commented 1 month ago

Bot detected the issue body's language is not English, translate it automatically.

When I used xmake to build before, it always failed. Finally, I found out that it was because xmake would find the tool chain I added from the PATH environment variable, and an error occurred when mixed. In order to use xmake, I always remove the tool chain in the PATH environment, which also results in the command line not even having g++. Sometimes if I want to write something small, I have to create a project with xmake, which is very cumbersome. Is it possible to add a function to the global settings to make xmake ignore the tool chain under the specified path, even if it is in the PATH environment variable?

If you don’t search from path, where can you find it? And not all toolchains are found from PATH. If you have any problems, you can raise issues.

heheda123123 commented 1 month ago

之前用xmake构建的时候老是通不过，最后发现是因为xmake会从PATH环境变量找到我添加的工具链，混用就出错了。 为了用xmake我都是把PATH环境里面的工具链去掉，这也导致命令行连个g++都没有，有时候想写点小东西，也必须xmake创建一个项目，就很繁琐。 是否可以给全局设置里面添加一个功能让xmake忽略指定路径下的工具链，即使他在PATH环境变量里。

不从 path 里找，从哪找。而且也不是所有 toolchain 都从 PATH 找，如果有问题，可以提 issues

可以从PATH里找，但是希望能有个exclude列表可以排除掉指定的目录，xmake分析PATH的时候遇到这个目录就跳过 之前提过issue，是因为我把msys2的bin加到windows的PATH环境里面。最后是去掉解决的（用下来，只对xmake有影响，没有其他问题，而且有些情况最好得加，有几个大型程序是在msys2里面编译出来的，我单独拿出来用，如果不加msys2的bin到环境变量里面跑不起来，除非把所有依赖单独再复制一份出来）

还有就是想在win命令行下用msys2下的工具，但是加了bin，又会影响xmake编译程序

xq114 commented 1 month ago

可以从PATH里找，但是希望能有个exclude列表可以排除掉指定的目录，xmake分析PATH的时候遇到这个目录就跳过 之前提过issue，是因为我把msys2的bin加到windows的PATH环境里面。最后是去掉解决的（用下来，只对xmake有影响，没有其他问题，而且有些情况最好得加，有几个大型程序是在msys2里面编译出来的，我单独拿出来用，如果不加msys2的bin到环境变量里面跑不起来，除非把所有依赖单独再复制一份出来）

还有就是想在win命令行下用msys2下的工具，但是加了bin，又会影响xmake编译程序

这种情况推荐是用虚拟环境 https://github.com/xmake-io/xmake/issues/5580 跑xmake的时候开虚拟环境把自己的toolchain放在系统gcc前面

Issues-translate-bot commented 1 month ago

Bot detected the issue body's language is not English, translate it automatically.

When I used xmake to build before, it always failed. Finally, I found out that it was because xmake would find the tool chain I added from the PATH environment variable, and an error occurred when mixed. In order to use xmake, I always remove the tool chain in the PATH environment, which also results in the command line not even having g++. Sometimes if I want to write something small, I have to create a project with xmake, which is very cumbersome. Is it possible to add a function to the global settings to make xmake ignore the tool chain under the specified path, even if it is in the PATH environment variable?

If you don’t search from path, where can you find it? And not all toolchains are found from PATH. If you have any problems, you can raise issues.

You can find it from PATH, but I hope there is an exclude list to exclude specified directories.

Issues-translate-bot commented 1 month ago

Bot detected the issue body's language is not English, translate it automatically.

You can find it from PATH, but I hope there is an exclude list to exclude the specified directory. When xmake analyzes PATH, it will skip this directory when it encounters this directory. The issue mentioned before is because I added the bin of msys2 to the PATH of windows. inside the environment. In the end, it was solved by removing it (after using it, it only affects xmake and has no other problems. In addition, in some cases it is better to add it. There are several large programs compiled in msys2. I use them separately. If msys2 is not added, bin cannot run in the environment variables unless all dependencies are copied separately)

I also want to use the tools under msys2 under the win command line, but adding bin will affect the xmake compiler.

In this case, it is recommended to use a virtual environment https://github.com/xmake-io/xmake/issues/5580. When running xmake, open the virtual environment and put your toolchain in front of the system gcc.

heheda123123 commented 1 month ago

可以从PATH里找，但是希望能有个exclude列表可以排除掉指定的目录，xmake分析PATH的时候遇到这个目录就跳过 之前提过issue，是因为我把msys2的bin加到windows的PATH环境里面。最后是去掉解决的（用下来，只对xmake有影响，没有其他问题，而且有些情况最好得加，有几个大型程序是在msys2里面编译出来的，我单独拿出来用，如果不加msys2的bin到环境变量里面跑不起来，除非把所有依赖单独再复制一份出来） 还有就是想在win命令行下用msys2下的工具，但是加了bin，又会影响xmake编译程序

这种情况推荐是用虚拟环境 #5580 跑xmake的时候开虚拟环境把自己的toolchain放在系统gcc前面

可以解决，不过这样的话，每个项目都得设置一遍环境变量，略繁琐，本身我是明确了不需要xmake使用特定路径下的工具链

Issues-translate-bot commented 1 month ago

Bot detected the issue body's language is not English, translate it automatically.

You can find it from PATH, but I hope there is an exclude list to exclude the specified directory. When xmake analyzes PATH, it will skip this directory when it encounters it. The issue mentioned before is because I added the bin of msys2 to windows. Inside the PATH environment. In the end, it was solved by removing it (after using it, it only affects xmake and has no other problems. In addition, in some cases it is better to add it. There are several large programs compiled in msys2. I use them separately. If msys2 is not added, bin cannot run in the environment variables unless all dependencies are copied separately) I also want to use the tools under msys2 under the win command line, but adding bin will affect the xmake compiler.

In this case, it is recommended to use a virtual environment #5580 When running xmake, open the virtual environment and put your own toolchain in front of the system gcc

It can be solved, but in this case, environment variables must be set for each project, which is a bit cumbersome. I have made it clear that xmake does not need to use the tool chain under a specific path.

xq114 commented 1 month ago

可以解决，不过这样的话，每个项目都得设置一遍环境变量，略繁琐，本身我是明确了不需要xmake使用特定路径下的工具链

每个项目都用不同的toolchain吗？一般有一两个全局虚拟环境就可以了吧

Issues-translate-bot commented 1 month ago

Bot detected the issue body's language is not English, translate it automatically.

It can be solved, but in this case, environment variables must be set for each project, which is a bit cumbersome. I have made it clear that xmake does not need to use the tool chain under a specific path.

Does each project use a different toolchain? Generally, one or two global virtual environments will suffice.

heheda123123 commented 1 month ago

可以解决，不过这样的话，每个项目都得设置一遍环境变量，略繁琐，本身我是明确了不需要xmake使用特定路径下的工具链

每个项目都用不同的toolchain吗？一般有一两个全局虚拟环境就可以了吧

现在是这样， 1 PATH里面只有msys2中bin的环境变量 2 如果用xmake使用msvc去编译项目，他会混合使用到msys2中的库(好像是这种情况，反正是混合了不同工具链的库，之前issue提过，但是找不到了，最后就是去掉msys2的库才正常)

我现在是希望xmake不管我在环境变量中加的这个msys2中的库

Issues-translate-bot commented 1 month ago

Bot detected the issue body's language is not English, translate it automatically.

It can be solved, but in this case, environment variables must be set for each project, which is a bit cumbersome. I have made it clear that xmake does not need to use the tool chain under a specific path.

Does each project use a different toolchain? Generally, one or two global virtual environments will suffice.

This is now the case, 1 PATH only contains the environment variables of bin in msys2 2 If you use msvc to compile the project using The library is normal)

I now hope that xmake will ignore the library in msys2 that I added in the environment variable.

xq114 commented 1 month ago

可以解决，不过这样的话，每个项目都得设置一遍环境变量，略繁琐，本身我是明确了不需要xmake使用特定路径下的工具链

每个项目都用不同的toolchain吗？一般有一两个全局虚拟环境就可以了吧

现在是这样， 1 PATH里面只有msys2中bin的环境变量 2 如果用xmake使用msvc去编译项目，他会混合使用到msys2中的库(好像是这种情况，反正是混合了不同工具链的库，之前issue提过，但是找不到了，最后就是去掉msys2的库才正常)

我现在是希望xmake不管我在环境变量中加的这个msys2中的库

这个很奇怪啊，msys2的库名字是xxx.dll.a，msvc是.lib，格式都不一样不应该链接上的，除非用了msys2 gfortran之类工具；这种情况把自己的flang/intel fortran放gfortran前面也能解决问题。感觉根本问题不在环境变量，在xmake找系统toolchain/library的机制