.cpp files are not recompiled by xmake when a header changes on Windows #1072
Comments
|
I think it may be related to the lowercase header file path list output by cl.exe + /sourceDependencies. But there is no time to confirm it further. I will check this issue in detail tomorrow. |
|
I tested it completely using the test example you provided. It works fine for me. But I don’t have a wsl environment, I did the test on cmd/msvc. Can you let me see your the content of In addition, I found a small problem in detecting I am not sure if it is related to the problem you encountered, of course you can try to update to the dev version and continue to test it. |
|
I don't think it's related to WSL as I reproduced the problem using a vsxmake2019 project. Here's main.cpp.obj.d content, it's kinda weird (beware: french, maybe that's causing the issue?): I'll update to the dev version and test it again |
|
Okay, as far as I understand it's due to the french output, as https://github.com/xmake-io/xmake/blob/master/xmake/modules/private/tools/cl/parse_include.lua#L35 only handle two languages and doesn't understand french outputs. I'll try to fill that array if you want |
|
I probably know the reason, because xmake is not compatible with all the prefix strings generated by xmake/xmake/modules/private/tools/cl/parse_include.lua Lines 35 to 39 in 92a8c9c Currently xmake only supports parsing Chinese and English string prefixes and does not support If xmake uses
|
If it is a high version vs, this problem should not be encountered, of course, I am also happy that you can help to improve this list. |
|
My MSVC version is 19.28.29334, the latest I'm aware of. Updating to the dev branch didn't fix the issue unfortunately. And adding the french prefix didn't seem to work either (I edited xmake files to test, it's still not recompiling files). Is there anything I can do to better understand what xmake does internally? |
|
Can you try cleaning cache first? |
xmake/xmake/modules/core/tools/cl.lua Lines 413 to 418 in 92a8c9c xmake/xmake/modules/core/tools/cl.lua Lines 487 to 496 in 92a8c9c xmake/xmake/modules/core/project/depend.lua Lines 52 to 58 in 92a8c9c /showIncludeshttps://github.com/xmake-io/xmake/blob/master/xmake/modules/private/tools/cl/parse_deps.lua /sourceDependencieshttps://github.com/xmake-io/xmake/blob/master/xmake/modules/private/tools/cl/parse_deps_json.lua |
|
Okay so I did clean the cache and removed the build folder, it seems to work now. I added a print in parse_include.lua which shows that xmake now parses the french output. I also ran a -vD build to show what xmake was doing with flags But I'm wondering now, you said this issue shouldn't be encountered with a high VS version (which is my case as far as I know) because it will use /sourceDependencies, which it seems to be doing, but it's still using /showIncludes lines. |
I see that he is already using If you have updated to the dev version, then it should not continue to use Can you let me see the content of main.cpp.obj.d again? |
|
Okay I found something weird. On the very first xmake run, it does use sourceDependencies and main.cpp.obj.d looks like this: If I change a header file, the .cpp is recompiled as it should be, but the main.cpp.obj.d content changes to this: So I tried to do this using verbose output. First time: After changing a header file: At this point the main.cpp.obj.d now uses showIncludes And from there, it relies on the french output parsing to continues to work. Edit: I did try after using |
This is the small problem I said at the beginning. It should have been fixed on dev, unless you have not fully updated to the latest commit of the dev branch. see this patch: 6426a1e
see #1072 (comment) |
|
It's weird, I ran Edit: Ok it seems to be related to WSL, running |
|
please run |
|
I can confirm your fix for /sourceDependencies works! Thanks. I will make a PR to add the french prefix to parse_includes.lua, and maybe more if I find other languages prefixes. I know xmake 2.3.9 just released, but considering the severity of this issue could a small bugfix release be considered? I wanted to use xmake for some projects I'm teaching next week to my C++ students, but as they're french xmake 2.3.9 won't work. |
This will cause sha256 errors in existing installation packages, affecting the installation of other package managers, such as winget. But I can upload an additional patch version on github/release/assets. For example: xmake-v2.3.9-1.win64.exe |
|
That would be perfect, thanks a lot. About showIncludes, I've been looking at what CMake does, it seems to be wrapping cl.exe and receive the file prefix (folder I guess) as a parameter. I suppose listing every language prefix isn't the best way to handle this, wouldn't it be better to try to parse a file path from the end of each line? |
However, the output of cl.exe will also mix compilation warning output and error messages to interfere with the analysis. like this: |
|
Oh yeah, didn't think of that. From reading ninja-build/ninja#613 : It seems CMake detects the prefix by running cl.exe on a dummy file, I think this is the best solution, albeit a bit complicated. I will make you a PR with french and Japanese prefixes, couldn't find more for now. |
This seems to be a good solution, I will consider it later. |
I have improved and supported it. xmake/xmake/modules/private/tools/cl/parse_include.lua Lines 30 to 81 in feca9bb |
|
I have uploaded latest binary package to github/releases. https://github.com/xmake-io/xmake/releases/download/v2.3.9/xmake-v2.3.9-patch1.win64.exe |
|
Dude you're a machine! Thank you for being so reactive 😄 |
Describe the bug
I tried to switch to xmake yesterday when I got this bug, it seems .cpp are not recompiled when a .hpp changes on Windows.
I reproduced the problem using a very small project, here are the files:
src/headerA.hpp:
src/headerB.hpp:
src/headerC.hpp:
src/main.cpp:
xmake.lua:
When I change any value in the header, the main.cpp is not recompiled and outputs the old values.
This bug doesn't occurs on Linux.
Expected behavior
That when changing any header file, all .cpp including it (even not directly) are compiled.
Error output
Note the B value is the previous one.
(Please note also I'm on WSL so I have access to Linux cat command but I'm using the Windows xmake version)
Related Environment
Please provide compiling and running environment information:
The text was updated successfully, but these errors were encountered: