ruki
> > 不懂，如果三个 option 都存在依赖关系, `a -> b -> c`，并且这三要么全是 true 要么全是 false ，互相关联的。 > > 我仅仅修改存储 c 的状态 > > 那 a 和 b 的状态怎么同步？我改完 c 直接 build 不就报错了么？...
> 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...
Incremental compilation is not currently supported because it is not known how to analyze and obtain their dependencies.
If we just rebuild the entire project, it works for me. ```console ruki:console ruki$ xmake [ 63%]: linking.release test [100%]: build ok, spent 0.359s ruki:console ruki$ touch src/main.nim ruki:console ruki$...
I still don't understand what you are saying. Can you provide a complete reproducible project and commands?
Currently it is not supported, only static library packages are supported.
> 但是 xmake l scripts\test.lua -vD libabc 不加 --shallow 的话会使得 ci 重新编译gcc，测试耗时拉的非常长；加 --shallow 又会让别的包也找到系统包上去，无法作完整的测试 不对吧，`--shallow` 只是决定是否拉取依赖， 并不决定是否走系统库。。。即使 没设置 `--shallow` ，拉依赖时候，也是优先找的 system 包的，找不到才会去远程拉。
I have no time to do it. you can make package to submit to conda-forge directly.
> checkinfo: cannot runv(C:\Users\admin\AppData\Local\.xmake\packages\c\cosmocc\3.6.2\7c0c13c9e6eb4f63a70078b888fd9978\bin\cosmoc++.exe --version), No such file or directory checkinfo: cannot runv(cosmoc++.exe --version), No such file or directory not found, you can check it, or run `xmake f -c...
it does not support for windows. because `cosomcc` is not a exe program, it's a shell file. we need bash/sh to load it. you can try this patch. https://github.com/xmake-io/xmake/pull/5553 But...