add policy msbuild.multi_tool_task

[SirLynix]

if its a msbuild config, setting it as a toolchain runenvs won't do anything, as xmake doesn't use msbuild.exe (it uses cl.exe and link.exe with its own scheduler).

[ChrisCatCP]

if its a msbuild config, setting it as a toolchain runenvs won't do anything, as xmake doesn't use msbuild.exe (it uses cl.exe and link.exe with its own scheduler).

it used by package(cmake or msbuild)

[SirLynix]

then maybe the policy shouldn't be named that way. since it's just an env variable, what's the benefit of adding it to xmake as a policy instead of just setting the env variable on the computer using xmake?

[ChrisCatCP]

then maybe the policy shouldn't be named that way. since it's just an env variable, what's the benefit of adding it to xmake as a policy instead of just setting the env variable on the computer using xmake?

Just to speed up package compile like package.cmake_generator.ninja

[SirLynix]

As far as I know ninja doesn't use msbuild either, that's the purpose of ninja (to schedule compiler calls like xmake does), but I may be wrong.

however, does it necessary need to be a xmake policy if you want set the environment variable in your xmake.lua, or on the CI/computer using it? there's already a lot of policies

[ChrisCatCP]

If package.cmake_gener.ninja is not enabled, this may be useful on msvc

[SirLynix]

you're not answering my question, what's the point of having it in xmake instead of just using os.setenv("UseMultiToolTask", "true") in your xmake.lua, or set UseMultiToolTask as an environment variable on the computer compiling?

[ChrisCatCP]

you're not answering my question, what's the point of having it in xmake instead of just using os.setenv("UseMultiToolTask", "true") in your xmake.lua, or set UseMultiToolTask as an environment variable on the computer compiling?

Is os.setenv ("CMAKE_GENERATOR", "Ninja") and package.cmake_gener.ninja similar to this?

[star-hengxing]

I think it should add here https://github.com/xmake-io/xmake/blob/2412ed94e70b00b0c2f3bd8c4553828efd458b1b/xmake/modules/package/tools/msbuild.lua#L60

[ChrisCatCP]

I think it should add here

https://github.com/xmake-io/xmake/blob/2412ed94e70b00b0c2f3bd8c4553828efd458b1b/xmake/modules/package/tools/msbuild.lua#L60

cmake dont use package.tools.msbuild

[SirLynix]

you're not answering my question, what's the point of having it in xmake instead of just using os.setenv("UseMultiToolTask", "true") in your xmake.lua, or set UseMultiToolTask as an environment variable on the computer compiling?

Is os.setenv ("CMAKE_GENERATOR", "Ninja") and package.cmake_gener.ninja similar to this?

it's not really the same as the env is taken by xmake directly, and xmake has full control on the way cmake is invoked

[ChrisCatCP]

xmake also has full control invoke msbuild，Do you think msbuild /p:UseMultiToolTask=true would be better?

[waruqi]

既然仅仅对 package 里面 tools.cmake 生效，添加到 msvc toolchain 干嘛，哪里是调用 cl.exe 构建用的，即使也会影响到 tools.cmake ，但是影响范围太广，会干扰到原本不应该被影响的地方。。

应该只在 tools.cmake 去修改，而且 msbuild 并行，这里应该已经加了，不需要再加额外的配置，msbuild -m:jobs 已经指定了并行，除非它没生效

https://github.com/xmake-io/xmake/blob/c6a1199e622bf6de11a8ab0cd7665a39d8fd1c36/xmake/modules/package/tools/cmake.lua#L1021

即使 /m: 不生效，必须要加额外的 envs，也应该 https://github.com/xmake-io/xmake/blob/c6a1199e622bf6de11a8ab0cd7665a39d8fd1c36/xmake/modules/package/tools/cmake.lua#L96 这里加。。

另外，先得确认为啥 /m: 为啥不管用，有验证过么

[Issues-translate-bot]

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

---

Since it only takes effect on tools.cmake in the package, what is the purpose of adding it to the msvc toolchain, where cl.exe is called for construction? Even if it will also affect tools.cmake, the scope of influence is too wide and will interfere with things that should not be affected in the first place. The place. .

It should only be modified in tools.cmake, and msbuild parallelism should have been added here. No additional configuration is needed. msbuild -m:jobs has already specified parallelism, unless it does not take effect.

https://github.com/xmake-io/xmake/blob/c6a1199e622bf6de11a8ab0cd7665a39d8fd1c36/xmake/modules/package/tools/cmake.lua#L1021

Even if /m: does not take effect and additional envs must be added, it should be https://github.com/xmake-io/xmake/blob/c6a1199e622bf6de11a8ab0cd7665a39d8fd1c36/xmake/modules/package/tools/cmake.lua#L96 here add. .

In addition, you must first confirm why /m: does not work. Have you verified it?

[ChrisCatCP]

既然仅仅对 package 里面 tools.cmake 生效，添加到 msvc toolchain 干嘛，哪里是调用 cl.exe 构建用的，即使也会影响到 tools.cmake ，但是影响范围太广，会干扰到原本不应该被影响的地方。。

应该只在 tools.cmake 去修改，而且 msbuild 并行，这里应该已经加了，不需要再加额外的配置，msbuild -m:jobs 已经指定了并行，除非它没生效

https://github.com/xmake-io/xmake/blob/c6a1199e622bf6de11a8ab0cd7665a39d8fd1c36/xmake/modules/package/tools/cmake.lua#L1021

即使 /m: 不生效，必须要加额外的 envs，也应该

https://github.com/xmake-io/xmake/blob/c6a1199e622bf6de11a8ab0cd7665a39d8fd1c36/xmake/modules/package/tools/cmake.lua#L96

这里加。。 另外，先得确认为啥 /m: 为啥不管用，有验证过么

/m:不是不生效，/m是针对一个sln的多个项目并行编译，这个是针对源文件进行并行编译，而且不仅仅针对cmake生效，也针对package.tool.msbuild生效，所以加到toolchain里了

[Issues-translate-bot]

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

---

Since it only takes effect on tools.cmake in the package, what is the purpose of adding it to the msvc toolchain, where cl.exe is called for construction? Even if it will also affect tools.cmake, the scope of influence is too wide and will interfere with things that should not be originally affected places. .

It should only be modified in tools.cmake, and msbuild parallelism should have been added here. No additional configuration is needed. msbuild -m:jobs has already specified parallelism, unless it does not take effect.

https://github.com/xmake-io/xmake/blob/c6a1199e622bf6de11a8ab0cd7665a39d8fd1c36/xmake/modules/package/tools/cmake.lua#L1021

Even if /m: does not take effect and additional envs must be added, it should

https://github.com/xmake-io/xmake/blob/c6a1199e622bf6de11a8ab0cd7665a39d8fd1c36/xmake/modules/package/tools/cmake.lua#L96

Add here. . In addition, you must first confirm why /m: does not work. Have you verified it?

/m: It is not invalid. /m is for parallel compilation of multiple projects of one sln. This is for parallel compilation of source files, and it is not only effective for cmake, but also effective for package.tool.msbuild, so it is added to the toolchain. Got it

[waruqi]

/m:不是不生效，/m是针对一个sln的多个项目并行编译，这个是针对源文件进行并行编译，而且不仅仅针对cmake生效，也针对package.tool.msbuild生效，所以加到toolchain里了

那直接在 tools.cmake 和 tools.msbuild 的 envs 里加上不就好了么，哪里需要生效，就加哪里。。

加 toolchain，可不只是 tools 里生效这么简单的，这个影响的范围大了去了。。会在大量无意义的地方，添加上这个 env 。。

xmake 的直接构建，project generator ，还有各种 rules ，flags 检测，只要用到 msvc env 的地方，全会被加上这个，而且加了也不会被用到。。说不定哪天还会来个副作用。。

凡事都应该最小化影响范围，加到实际需要的地方，不应该加的地方，就不要加

[Issues-translate-bot]

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

---

/m: It is not invalid. /m is for parallel compilation of multiple projects of one sln. This is for parallel compilation of source files, and it is not only effective for cmake, but also effective for package.tool.msbuild, so it is added to the toolchain. Inside

Then just add it directly to the envs of tools.cmake and tools.msbuild. Just add it wherever it needs to take effect. .

Adding toolchain is not just as simple as taking effect in tools. The scope of this influence is much wider. . This env will be added in a lot of meaningless places. .

[ChrisCatCP]

/m:不是不生效，/m是针对一个sln的多个项目并行编译，这个是针对源文件进行并行编译，而且不仅仅针对cmake生效，也针对package.tool.msbuild生效，所以加到toolchain里了

那直接在 tools.cmake 和 tools.msbuild 的 envs 里加上不就好了么，哪里需要生效，就加哪里。。

加 toolchain，可不只是 tools 里生效这么简单的，这个影响的范围大了去了。。会在大量无意义的地方，添加上这个 env 。。

是这样没错，但是这样改动少，而且这个环境变量只影响msbuild，不会影响别的工具链，如果要加到特定工具里，那就直接加到msbuild的参数里可能更好一点 /p:UseMultiToolTask=true

[Issues-translate-bot]

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

---

/m: It is not invalid. /m is for parallel compilation of multiple projects of one sln. This is for parallel compilation of source files, and it is not only effective for cmake, but also effective for package.tool.msbuild, so add it to In the toolchain

Then just add it directly to the envs of tools.cmake and tools.msbuild. Just add it wherever it needs to take effect. .

Adding toolchain is not just as simple as taking effect in tools. The scope of this influence is much wider. . This env will be added in a lot of meaningless places. .

That's true, but there are fewer changes this way, and this environment variable only affects msbuild and will not affect other tool chains. If you want to add it to a specific tool, it may be better to add it directly to the parameters of msbuild/p: UseMultiToolTask=true

[waruqi]

/m:不是不生效，/m是针对一个sln的多个项目并行编译，这个是针对源文件进行并行编译，而且不仅仅针对cmake生效，也针对package.tool.msbuild生效，所以加到toolchain里了

那直接在 tools.cmake 和 tools.msbuild 的 envs 里加上不就好了么，哪里需要生效，就加哪里。。 加 toolchain，可不只是 tools 里生效这么简单的，这个影响的范围大了去了。。会在大量无意义的地方，添加上这个 env 。。

是这样没错，但是这样改动少，而且这个环境变量只影响msbuild，不会影响别的工具链，如果要加到特定工具里，那就直接加到msbuild的参数里可能更好一点 /p:UseMultiToolTask=true

你这样改动反而最多。。clang-cl 也需要， package 切换 clang-cl ，msbuild 也会调用到，那么 clang-cl toolchain 的也得同步改。。而且 msvc/clang-cl toolchain 本身跟 msbuild 没有必然关系。。你去加 toolchain 。。属于反向操作。。没这么改法的。。其他开发者会看的莫名其妙。我都不保证 toolchain 一定会被 msbuild 用到，也许将来我重构下，msbuild 不会去调用 toolchain 的 envs 呢，那不就被 break 了么。。但是你改 tools/cmake, tools/msbuild 肯定会一直生效，并且其他维护者看到 也能一目了然

tools.cmake 和 tools.msbuild 也就改两个地方，改动量又不大。。

反正，我还是那句话，哪里实际需要，就改哪里，不要改任何其他无意义的地方。

[Issues-translate-bot]

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

---

/m: It is not invalid. /m is for parallel compilation of multiple projects of one sln. This is for parallel compilation of source files, and it is not only effective for cmake, but also effective for package.tool.msbuild, so add In the toolchain

Then just add it directly to the envs of tools.cmake and tools.msbuild. Just add it wherever it needs to take effect. . Adding toolchain is not just as simple as taking effect in tools. The scope of this influence is much wider. . This env will be added in a lot of meaningless places. .

That’s true, but there are fewer changes, and this environment variable only affects msbuild and will not affect other tool chains. If you want to add it to a specific tool, it may be better to add it directly to the parameters of msbuild/p :UseMultiToolTask=true

This way you will make the most changes. . clang-cl is also needed. When package switches clang-cl, msbuild will also call it, so the clang-cl toolchain must also be changed simultaneously. . Moreover, the msvc/clang-cl toolchain itself has no necessary relationship with msbuild. . You go and add toolchain. . It is a reverse operation. . There is no such change of law. . Other developers will look confused. I don't guarantee that the toolchain will be used by msbuild. Maybe if I reconstruct it in the future, msbuild will not call the envs of the toolchain. Then it will be broken. . But if you change tools/cmake, tools/msbuild, it will definitely take effect, and other maintainers can see it clearly.

tools.cmake and tools.msbuild are only two changes, and the amount of changes is not large. .

Anyway, I still say what I said, change whatever is actually needed, and don’t change any other meaningless places.

[ChrisCatCP]

/m:不是不生效，/m是针对一个sln的多个项目并行编译，这个是针对源文件进行并行编译，而且不仅仅针对cmake生效，也针对package.tool.msbuild生效，所以加到toolchain里了

那直接在 tools.cmake 和 tools.msbuild 的 envs 里加上不就好了么，哪里需要生效，就加哪里。。 加 toolchain，可不只是 tools 里生效这么简单的，这个影响的范围大了去了。。会在大量无意义的地方，添加上这个 env 。。

是这样没错，但是这样改动少，而且这个环境变量只影响msbuild，不会影响别的工具链，如果要加到特定工具里，那就直接加到msbuild的参数里可能更好一点 /p:UseMultiToolTask=true

你这样改动反而最多。。clang-cl 也需要， package 切换 clang-cl ，msbuild 也会调用到，那么 clang-cl toolchain 的也得同步改。。而且 msvc/clang-cl toolchain 本身跟 msbuild 没有必然关系。。你去加 toolchain 。。属于反向操作。。没这么改法的。。其他开发者会看的莫名其妙。我都不保证 toolchain 一定会被 msbuild 用到，也许将来我重构下，msbuild 不会去调用 toolchain 的 envs 呢，那不就被 break 了么。。但是你改 tools/cmake, tools/msbuild 肯定会一直生效，并且其他维护者看到 也能一目了然

tools.cmake 和 tools.msbuild 也就改两个地方，改动量又不大。。

反正，我还是那句话，哪里实际需要，就改哪里，不要改任何其他无意义的地方。

已修改

[Issues-translate-bot]

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

---

/m: It is not invalid. /m is for parallel compilation of multiple projects of one sln. This is for parallel compilation of source files, and it is not only effective for cmake, but also effective for package.tool.msbuild, so Added to toolchain

Then just add it directly to the envs of tools.cmake and tools.msbuild. Just add it wherever it needs to take effect. . Adding toolchain is not just as simple as taking effect in tools. The scope of this influence is much wider. . This env will be added in a lot of meaningless places. .

This is true, but there are fewer changes, and this environment variable only affects msbuild and will not affect other tool chains. If you want to add it to a specific tool, it may be better to add it directly to the parameters of msbuild/ p:UseMultiToolTask=true

You will make the most changes this way. . clang-cl is also needed. When package switches clang-cl, msbuild will also call it, so the clang-cl toolchain must also be changed simultaneously. . Moreover, the msvc/clang-cl toolchain itself has no necessary relationship with msbuild. . You go and add toolchain. . It is a reverse operation. . There is no such change of law. . Other developers will look confused. I don't guarantee that the toolchain will be used by msbuild. Maybe if I reconstruct it in the future, msbuild will not call the envs of the toolchain. Then it will be broken. . But if you change tools/cmake, tools/msbuild, it will definitely take effect, and other maintainers can see it clearly.

There are only two changes to tools.cmake and tools.msbuild, and the amount of changes is not large. .

Anyway, I still say what I said, change whatever is actually needed, and don’t change any other meaningless places.

already edited