v3.0 Roadmap

[waruqi]

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)

• [x] Use MD/MDd runtimes for msvc by default
  • Poll: https://github.com/xmake-io/xmake/discussions/5526
• [x] Use ninja generator for cmake package by default
  • Poll: https://github.com/xmake-io/xmake/discussions/5545
• [x] Simplifying add_requires with configs
  • https://github.com/xmake-io/xmake/issues/5727#issuecomment-2421040107

Roadmap (Draft)

• [ ] Remove support for built-in variables in script scope, support it only in the description
  • Poll: https://github.com/xmake-io/xmake/discussions/5529
• [ ] Rename buildir to builddir
  • Poll: https://github.com/xmake-io/xmake/discussions/5533
  • https://github.com/xmake-io/xmake/issues/5596
• [ ] Improve custom toolchain to support unknown compiler/linker.
  • https://github.com/xmake-io/xmake/issues/5554
• [ ] Support project namespace
  • https://github.com/xmake-io/xmake/issues/3380
• [ ] Autobuild when calling xmake run
  • Poll: https://github.com/xmake-io/xmake/discussions/5624
• [ ] ...

[24bit-xjkp]

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

[waruqi]

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]

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

[heheda123123]

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]

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

[jingkaimori]

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]

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]

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

[Issues-translate-bot]

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]

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]

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-rules.lua

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

[WubiCookie]

Rename buildir to builddir

[waruqi]

Rename buildir to builddir

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

[A2va]

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]

Use ninja generator for cmake package by default.

[waruqi]

Use ninja generator for cmake package by default.

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

[jube]

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]

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]

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]

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

[Issues-translate-bot]

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]

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

[Issues-translate-bot]

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]

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

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

[heheda123123]

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

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

[waruqi]

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

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

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

[Issues-translate-bot]

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]

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

[heheda123123]

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

[waruqi]

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

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