Visual Studio generator (vsxxxx) doesn't allow parallel building #1062
Comments
It has not been deprecated, and users can still use it. However, the vs201x plugin cannot fully support all the features in xmake.lua, such as on_xxx/after_xxx scripts and on_xxx scripts in some built-in rules.
MultiProcessorCompilation -> enable
Why? If we don't tell it, how does vs know the real output path of each object file?
This just looks strange, but there is no problem. Each source file should only be compiled once. Xmake will have a file lock to ensure that each target is compiled one by one. If the current source file has been compiled, it will not be compiled again. Another solution is that you can add a target("all")
set_kind("phony")
add_deps("t1", "t2", "t3") |
Fair enough, so as long as I don't use this it's fine to use the vs2019 generator?
It's possible, but since minimal regeneration is deprecated, it could also be enabled by default imo.
It doesn't have to be set for each file, in the .vcxproj file there's already which does the trick.
I rechecked on this and you're right, files get only compiled once, I had multiple compilations of the same file because one of my target failed to compile, nvm. It's interesting to know about this file lock! The phony all solution is also quite interesting, I think cmake does something like this. |
Yes, as long as you don’t use
But there are still some other flags that are not compatible with it. I think it is better for users to manually enable it in VS. https://docs.microsoft.com/en-us/cpp/build/reference/mp-build-with-multiple-processes?view=msvc-160
You are right, here I can improve it. Thank you. |
|
No problem, do you want me to make a PR to handle /Gm- /Gm and /MP flags? |
I think there are still some other problems. If there are multiple object files with the same name in the same object root directory, will it cause conflicts? e.g.
Will VS write these object files to the same location? |
|
I just checked and folders are kept, no problem for that. |
Got it, then there is no problem. I have removed |
Yes, I welcome your contribution. But I still don't know how to better support it. If you use In addition, we also need to consider how to deal with Perhaps it would be better for users to modify and enable it directly in the VS project configuration property page. |
I suppose this is only a problem when xmake is used for compilation (instead of Visual Studio), I think /MP can be dropped in that case, as xmake will do parallel compilation on its own. |
You can try the following command to enable it only for vs project. xmake f --cxflags="/MP"
xmake project -k vs |
I tried it, It does not work. object files will conflict. see #2016
|
|
I have fixed it. |
Describe the bug
Hi, when using the old Visual Studio 2019 generator, it outputs project files that don't allow multiprocessorcompilation, so I made a change to add them, but found out that it was still blocked because of the ObjectFileName conditions.
It does generate this:
Removing the ObjectFileName entry does fix and allows parallel compilation. The object files are still generated in the right folder (so I guess this isn't necessary).
Now I know the old Visual Studio generator is deprecated, but I'm having troubles with the new one, like using the "build solution" button which does something like this:
Which I'm guessing is troublesome, I have some files that get compiled multiple times when doing so.
Why is the VS2019 generator deprecated btw? It seems to be fine, except for that multiprocessor issue.
Expected behavior
To generate a project allowing for multiprocessor compilation.
Related Environment
Please provide compiling and running environment information:
Additional context
I added
in the vs201x_vcxproj.lua (before
-- make AdditionalIncludeDirectories) to setup correctly the multiprocessor flags, and excluded "Gm-" and "Gm" from the additional flags.The text was updated successfully, but these errors were encountered: