Provide a way to export only modified configs

[xq114]

你在什么场景下需要该功能？

#2401

有时需要在一个config模板上增加新的config，目前xmake中不提供config-update功能，只能通过

xmake f --export=template.txt
xmake f --import=template.txt --a=on

来实现。但这种做法存在一些问题，例如项目中存在a,b,c三个option，其中b的值依赖a而变动。（例如a=off时b设为on）这时运行

xmake f --a=on
xmake f --export=template.txt
xmake f --import=template.txt --a=off

就会出现问题，template.txt中b为off，最后的效果相当于xmake f --a=off --b=off，产生conflict。#2401 中提到的config-update插件似乎也不能处理这种情况。

描述可能的解决方案

类似VSCode的做法，只记录modified configs，而非记录全部configs：

xmake f --a=on
xmake f --export=template.txt

template.txt

{ a = true }

对非手动设置的默认config留给项目自己决定，不记录/导出。这样就避免了之前提到的conflict。

可以先提供xmake f --export-modified 选项并保留之前的做法，3.0投票确认是否要更改为默认行为

描述你认为的候选方案

用 export-modified 和 import 实现一个官方的 config-update ，原有export行为保留；config-update运行的时候输出一行实际的config命令

> xmake config --a=on --c=on
...
> xmake config-update --a=off
run: xmake config --c=on --a=off
...

这样可以很清晰地看到是否有config conflict，和直接输入xmake config --c=on --a=off是一样的。

其他信息

Related issues/comments:

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.

Originally posted by @SirLynix in #5527 (comment)

#5041
#2401
#823

[waruqi]

但这种做法存在一些问题，例如项目中存在a,b,c三个option，其中b的值依赖a而变动。（例如a=off时b设为on）这时运行

就是因为依赖联动很难搞，所以我一直没支持 config update，因为支持了，联动不了，反而会引入各种暗坑，导致用户各种报障，还很难复现和调试

[Issues-translate-bot]

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

---

But there are some problems with this approach. For example, there are three options a, b, and c in the project, and the value of b changes depending on a. (For example, when a=off, set b to on) Then run

Just because it is difficult to rely on linkage, I have never supported config update, because if it is supported, linkage cannot be done, but it will introduce various hidden pits, causing users to report various problems, and it is difficult to reproduce and debug.

[xq114]

但这种做法存在一些问题，例如项目中存在a,b,c三个option，其中b的值依赖a而变动。（例如a=off时b设为on）这时运行

就是因为依赖联动很难搞，所以我一直没支持 config update，因为支持了，联动不了，反而会引入各种暗坑，导致用户各种报障，还很难复现和调试

所以才需要学vscode的存modified的方式，vscode的模式还能支持合并多个设备不同的setting，也是很成熟的解决方案了；而且也不一定非要提供config update，提供一个modified config就行了

[Issues-translate-bot]

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

---

But there are some problems with this approach. For example, there are three options a, b, and c in the project, and the value of b changes depending on a. (For example, when a=off, set b to on) Then run

It is because it is difficult to rely on linkage, so I have not supported config update, because if it is supported, linkage cannot be done, but it will introduce various hidden pits, causing users to report various problems, and it is difficult to reproduce and debug.

That’s why you need to learn the modified method of vscode. The vscode mode can also support merging different settings of multiple devices, which is also a very mature solution; and it is not necessary to provide a config update, just provide a modified config.

[waruqi]

但这种做法存在一些问题，例如项目中存在a,b,c三个option，其中b的值依赖a而变动。（例如a=off时b设为on）这时运行

就是因为依赖联动很难搞，所以我一直没支持 config update，因为支持了，联动不了，反而会引入各种暗坑，导致用户各种报障，还很难复现和调试

所以才需要学vscode的存modified的方式，vscode的模式还能支持合并多个设备不同的setting，也是很成熟的解决方案了；而且也不一定非要提供config update，提供一个modified config就行了

不懂，如果三个 option 都存在依赖关系, a -> b -> c，并且这三要么全是 true 要么全是 false ，互相关联的。

我仅仅修改存储 c 的状态

那 a 和 b 的状态怎么同步？我改完 c 直接 build 不就报错了么？

对非手动设置的默认config留给项目自己决定，不记录/导出。这样就避免了之前提到的conflict。

那不是还得用户手动分析关系后，手动再去改 a/b? 要是没去改呢 不也会出错么

[Issues-translate-bot]

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

---

But there are some problems with this approach. For example, there are three options a, b, and c in the project, and the value of b changes depending on a. (For example, when a=off, set b to on) Then run

Because it is difficult to rely on linkage, I have not supported config update. Because if it is supported, linkage cannot be done, but it will introduce various hidden pits, causing users to report various problems, and it is difficult to reproduce and debug.

That’s why you need to learn the modified method of vscode. The vscode mode can also support merging different settings of multiple devices, which is also a very mature solution; and it is not necessary to provide a config update, just provide a modified config.

I don’t understand, if all three options have a dependency relationship, a -> b -> c, and these three are either all true or all false, they are related to each other.

I only modify the state of storage c

How to synchronize the status of a and b? After I change c, won’t it report an error if I build directly?

The default config that is not set manually is left to the project itself and is not recorded/exported. This avoids the conflict mentioned earlier.

Doesn’t the user have to manually analyze the relationship and then manually change a/b? If he didn’t change it, wouldn’t there be an error?

[xq114]

不懂，如果三个 option 都存在依赖关系, a -> b -> c，并且这三要么全是 true 要么全是 false ，互相关联的。

我仅仅修改存储 c 的状态

那 a 和 b 的状态怎么同步？我改完 c 直接 build 不就报错了么？

对非手动设置的默认config留给项目自己决定，不记录/导出。这样就避免了之前提到的conflict。

那不是还得用户手动分析关系后，手动再去改 a/b? 要是没去改呢 不也会出错么

如果是这样互相关联的情况，b c都应该设成 set_showmenu(false) ，不暴露接口。暴露出来的只应该是能改、能影响其他option的接口。这种问题和有没有config update 无关，暴露c出来直接执行xmake f --c=on也会报错，xmake不需要处理所有的conflict，只需要不在命令行基础上引入新的conflict就行了

[Issues-translate-bot]

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

---

I don’t understand, if the three options all have a dependency relationship, a -> b -> c, and these three are either all true or all false, they are related to each other.

I only modify the state of storage c

How to synchronize the status of a and b? After I change c, won’t it report an error if I build directly?

The default config that is not set manually is left to the project itself and is not recorded/exported. This avoids the conflict mentioned earlier.

Doesn’t the user have to manually analyze the relationship and then manually change a/b? If he didn’t change it, wouldn’t there be an error?

If this is the case, b and c should be set to set_showmenu(false) and the interface should not be exposed. Exposed should only be interfaces that can be changed and affect other options. This kind of problem has nothing to do with whether there is a config update. Exposing c and executing xmake f --c=on directly will also report an error.

[waruqi]

不懂，如果三个 option 都存在依赖关系, a -> b -> c，并且这三要么全是 true 要么全是 false ，互相关联的。
我仅仅修改存储 c 的状态
那 a 和 b 的状态怎么同步？我改完 c 直接 build 不就报错了么？

对非手动设置的默认config留给项目自己决定，不记录/导出。这样就避免了之前提到的conflict。

那不是还得用户手动分析关系后，手动再去改 a/b? 要是没去改呢 不也会出错么

如果是这样互相关联的情况，b c都应该设成 set_showmenu(false) ，不暴露接口。暴露出来的只应该是能改、能影响其他option的接口。

不一定，联动有可能只是默认值联动，不是强制联动的。比如 --plat/--arch 都是暴露的

如果 xmake f -p linux ，没有指定 arch，那么 arch 默认可以联动到 linux 支持的 arch 上去。。但是用户还是可以 xmake f -p linux -a x86_64 强制全部指定。

比如现在支持了增量更新。

首次用户配置，xmake f -p linux -a x86_64
第二次用户配置切了平台，xmake f -p iphoneos

这时候的 arch 到底应该是之前用户指定的 x86_64 还是iphoneos 默认的 arm64 呢？

目前的全量配置，也支持联动，但是仅仅只需要支持默认值联动，也就是 arch 会自动切到 arm64，其实反而是最合理的。

如果是增量更新，如果还是用之前用户指定的 x86_64 其实不对的，但是要支持联动，就不仅仅是默认值的联动关系了，这块实现上，目前的机制处理起来就更复杂了，目前不太好实现。但要是不处理，那么状态就不一致冲突了。各种配置多了，用户自己都记不清哪些 option 当前是哪些状态了，然后编译报错了，就各种提 issues 。

[Issues-translate-bot]

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

---

I don’t understand, if all three options have a dependency relationship, a -> b -> c, and these three are either all true or all false, they are related to each other.
I only modify the state of storage c
How to synchronize the status of a and b? After I change c, won’t it report an error if I build directly?

The default config that is not set manually is left to the project itself and is not recorded/exported. This avoids the conflict mentioned earlier.

Doesn’t the user have to manually analyze the relationship and then manually change a/b? If he didn’t change it, wouldn’t there be an error?

If this is the case, b and c should be set to set_showmenu(false) and the interface should not be exposed. Exposed should only be interfaces that can be changed and affect other options.

Not necessarily, the linkage may only be the default value linkage, not forced linkage. For example, --plat/--arch are exposed

If xmake f -p linux does not specify arch, then arch can be linked to the arch supported by linux by default. . But users can still use xmake f -p linux -a x86_64 to force all specifications.

For example, incremental updates are now supported.

First user configuration, xmake f -p linux -a x86_64
The second user configuration switched platforms, xmake f -p iphoneos

Should the arch at this time be the x86_64 specified by the previous user or the default arm64 of iPhoneos?

The current full configuration also supports linkage, but it only needs to support linkage with the default value, that is, arch will automatically switch to arm64, which is actually the most reasonable.

If it is an incremental update, it is actually wrong to use the x86_64 specified by the previous user. However, to support linkage, it is not just the linkage relationship of the default value. In terms of implementation, the current mechanism is more complicated to handle. Currently Not easy to implement. But if it is not handled, the status will be inconsistent and conflicting. There are so many configurations that users can no longer remember which options are currently in which status. Then when compilation errors are reported, various issues are raised.

[xq114]

不一定，联动有可能只是默认值联动，不是强制联动的。比如 --plat/--arch 都是暴露的

如果 xmake f -p linux ，没有指定 arch，那么 arch 默认可以联动到 linux 支持的 arch 上去。。但是用户还是可以 xmake f -p linux -a x86_64 强制全部指定。

比如现在支持了增量更新。

首次用户配置，xmake f -p linux -a x86_64 第二次用户配置切了平台，xmake f -p iphoneos

这时候的 arch 到底应该是之前用户指定的 x86_64 还是iphoneos 默认的 arm64 呢？

目前的全量配置，也支持联动，但是仅仅只需要支持默认值联动，也就是 arch 会自动切到 arm64，其实反而是最合理的。

如果是增量更新，如果还是用之前用户指定的 x86_64 其实不对的，但是要支持联动，就不仅仅是默认值的联动关系了，这块实现上，目前的机制处理起来就更复杂了，目前不太好实现。但要是不处理，那么状态就不一致冲突了。各种配置多了，用户自己都记不清哪些 option 当前是哪些状态了，然后编译报错了，就各种提 issues 。

可以不改默认行为，提供一个增量更新的接口或者导出更改过的options的接口就好了。上面的行为如果在增量更新里面等价于

xmake f -p linux -a x86_64 -p iphoneos

出错误是应该的，这种情况就应该用全量更新清除之前设置。

（p.s. 实际上这种同时需要产出两种target的情况直接切config会覆盖之前的detect cache等，来回切换并不太方便，一般我会直接开两个子文件夹build_linux和build_ios然后分别在里面跑xmake -P ..，这样每个文件夹的detect cache、config等都是独立的）

[Issues-translate-bot]

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

---

Not necessarily, the linkage may only be the default value linkage, not forced linkage. For example, --plat/--arch are exposed

If xmake f -p linux does not specify arch, then arch can be linked to the arch supported by linux by default. . But users can still use xmake f -p linux -a x86_64 to force all specifications.

For example, incremental updates are now supported.

First user configuration, xmake f -p linux -a x86_64 Second user configuration to switch platforms, xmake f -p iphoneos

Should the arch at this time be the x86_64 specified by the previous user or the default arm64 of iphoneos?

The current full configuration also supports linkage, but it only needs to support linkage with the default value, that is, arch will automatically switch to arm64, which is actually the most reasonable.

If it is an incremental update, it is actually wrong to use the x86_64 specified by the previous user. However, to support linkage, it is not just the linkage relationship of the default value. In terms of implementation, the current mechanism is more complicated to handle. It's not easy to implement at the moment. But if it is not handled, the status will be inconsistent and conflicting. There are so many configurations that users can no longer remember which options are currently in which status. Then when compilation errors are reported, various issues are raised.

You can leave the default behavior unchanged and provide an interface for incremental updates or an interface for exporting changed options. The above behavior in incremental updates is equivalent to

xmake f -p linux -a x86_64 -p iphoneos

An error is expected. In this case, a full update should be used to clear the previous settings.

(p.s. In fact, when two targets need to be generated at the same time, switching config directly will overwrite the previous detect cache, etc., and switching back and forth is not very convenient. Generally, I will directly open two sub-folders, build_linux and build_ios, and run them in them respectively. xmake -P .., so that the detect cache, config, etc. of each folder are independent)

[waruqi]

p.s. 实际上这种同时需要产出两种target的情况直接切config会覆盖之前的detect cache等，来回切换并不太方便，一般我会直接开两个子文件夹build_linux和build_ios然后分别在里面跑xmake -P ..，这样每个文件夹的detect cache、config等都是独立的）

现在各种 cache 原本就是根据 plat/arch 独立存储的，为啥会冲突，我来回各种切，也没见啥问题

 .xmake/macosx/x86_64/cache/detect 

出错误是应该的，这种情况就应该用全量更新清除之前设置。

现在的问题就是，支持了增量更新，遇到这种错误的频率就变的更多了，有需要用户手动全量，然后对于大部分用户，并不了解这些机制和原理，就会各种趟坑后过来开 issues 问，很容易被劝退，而全量更新，至少目前 cmake/autoconf 目前也都是，至少行为上一致，熟悉这种方式。

可以不改默认行为，提供一个增量更新的接口或者导出更改过的options的接口就好了

为了个配置，额外再去加个 xmake config-update 太臃肿了，现在内置的命令已经太多了。而且每次更新配置，要敲这么长，也不见得比全量的省事。

后面，增量可以考虑做，但前提是，需要先完全解决依赖联动的问题。就比如这里提到的 menuconf option 的状态联动。#4878

只有把这个问题彻底解了，那就没必要分 xmake config 和 xmake config-update 了。到时候，config-update 反而显得冗余，没啥意义了。

关于如何联动，目前我暂时没时间想好怎么弄，可能会考虑 option 里面加个 on_changed/on_updated 来实现用户修改状态的快速更新。

[Issues-translate-bot]

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

---

p.s. In fact, when two targets need to be generated at the same time, switching config directly will overwrite the previous detect cache, etc. It is not very convenient to switch back and forth. Generally, I will directly open two sub-folders, build_linux and build_ios, and run them respectively. xmake -P .., so that the detect cache, config, etc. of each folder are independent)

Now various caches are originally stored independently according to plat/arch. Why do they conflict? I have switched back and forth and there is no problem.

 .xmake/macosx/x86_64/cache/detect

An error is expected. In this case, a full update should be used to clear the previous settings.

The problem now is that as incremental updates are supported, the frequency of encountering this kind of error becomes more frequent. Users are required to manually complete the update. However, most users do not understand these mechanisms and principles and will encounter various errors. It is easy to be persuaded to leave if you come to open issues after the pit, and full updates, at least for now, cmake/autoconf, at least the behavior is consistent, and you are familiar with this method.

You can leave the default behavior unchanged and provide an interface for incremental updates or an interface for exporting changed options.

For the sake of configuration, adding an additional xmake config-update is too bloated. There are already too many built-in commands. And every time the configuration is updated, it takes so long to type, which is not necessarily less troublesome than the full amount.

Later, increments can be considered, but the premise is that the problem of dependence on linkage needs to be completely resolved first. For example, the status linkage of menuconf option mentioned here. #4878

Only if this problem is completely solved, there will be no need to separate xmake config and xmake config-update. By then, config-update will appear redundant.

As for how to link it, I don’t have time to figure out how to do it at the moment. I may consider adding on_changed/on_updated to the option to quickly update the user’s modified status.

[xq114]

而全量更新，至少目前 cmake/autoconf 目前也都是，至少行为上一致，熟悉这种方式。

这个其实不准确，cmake/autoconf机制上是不支持更新的，要新的config就必须开新的文件夹，不然直接报错。所以微软才搞了个CMakePresets.json来实现增量更新，VS里Modified内容放到CMakePresets.json里，VS调用cmake的时候从CMakePresets.json生成设置。在同一个文件夹config多次的功能只有xmake才有，谈不上方式已经熟悉，其实我这边“理所当然”觉得多次config应该增量的新用户更多，只是来提issue问的比较少。

为了个配置，额外再去加个 xmake config-update 太臃肿了，现在内置的命令已经太多了。而且每次更新配置，要敲这么长，也不见得比全量的省事。

这个说法赞同，而且确实支持联动之后不再需要config-update了。目前可以不用官方提供config-update，只修改一下config --export的行为作为权益之计也足够了，需要增量更新的可以自己用modified export实现。上面微软搞得那套实际上也就是modified export。xmake-vscode插件里内部也可以用增量更新，目前vscode里点击build自动先运行xmake f --plat=windows --arch=x64，把之前设置的config都清除了，导致gui基本没法用，有增量更新的实现方式也可以参考VS支持CMake的方式，先把gui用起来

[Issues-translate-bot]

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

---

As for full updates, at least for now, cmake/autoconf is also the same, at least the behavior is consistent, and I am familiar with this method.

This is actually not accurate. The cmake/autoconf mechanism does not support updates. If you want a new config, you must open a new folder, otherwise an error will be reported directly. That's why Microsoft created a CMakePresets.json to implement incremental updates. The Modified content in VS is placed in CMakePresets.json. When VS calls cmake, it generates settings from CMakePresets.json. The function of configuring the same folder multiple times is only available in xmake. I am not familiar with the method. In fact, I "naturally" think that more new users should increment multiple configs, but there are relatively few people who come to ask questions. .

For the sake of configuration, adding an additional xmake config-update is too bloated. There are already too many built-in commands. And every time I update the configuration, it takes so long to type, which is not necessarily less troublesome than the full version.

I agree with this statement, and it does support that config-update is no longer needed after linkage. At present, there is no need to officially provide config-update. Just modifying the behavior of config --export is enough as a benefit measure. If you need incremental updates, you can use modified export to implement it yourself. What Microsoft did above is actually modified export. Incremental updates can also be used internally in the xmake-vscode plug-in. Currently, clicking build in vscode automatically runs xmake f --plat=windows --arch=x64, which clears all the previously set configs, making the gui basically unusable. For implementation methods of incremental updates, you can also refer to the way VS supports CMake. First use the gui.