Normalize LLVM_ROOT when writing sanity file

emscripten-core / emscripten

Emscripten: An LLVM-to-WebAssembly Compiler

Other

25.35k stars 3.25k forks source link

Normalize LLVM_ROOT when writing sanity file #22153

Open xanzarx opened 3 days ago

xanzarx commented 3 days ago

Visual Studio Code CMakeTools extension cleans cache when the editor opens in Windows. Possible root cause is different LLVM root paths string case in santiy.txt:

For startup it produces path starting with 'c:\' e.g c:\projects\emscripten\upstream\bin
For regular cmake configuration or build it produces path starting with 'C:\' e.g C:\projects\emscripten\upstream\bin This leads to rebuilding cache every time the editor is launched, which is a bit frustrating Link to similar issue

For windows path to folders is case independent anyways, so possible fix is just put lowercase string to sainty.txt for Windows.

sbc100 commented 3 days ago

I'd like to understand this issue a little more before landing this. How/where/why is VSCode settings the llvm root?

sbc100 commented 3 days ago

Is EM_CONFIG being set somewhere perhaps?

xanzarx commented 3 days ago

As it turns out running commands with drive letter in different case in windows terminal application will lead change sanity.txt (and cache rebuild)

C:\Projects\test>C:\projects\emscripten\upstream\emscripten\em++ main.cpp sanity.txt:

3.1.59|C:/Projects/emscripten/upstream/bin

C:\Projects\test>c:\projects\emscripten\upstream\emscripten\em++ main.cpp sanity.txt:

3.1.59|c:/Projects/emscripten/upstream/bin

For not it seems the issue was not caused (at least directly) by interaction with VS Code or CMake tools plugin for VSCode

sbc100 commented 3 days ago

As it turns out running commands with drive letter in different case in windows terminal application will lead change sanity.txt (and cache rebuild)

C:\Projects\test>C:\projects\emscripten\upstream\emscripten\em++ main.cpp sanity.txt:
3.1.59|C:/Projects/emscripten/upstream/bin
C:\Projects\test>c:\projects\emscripten\upstream\emscripten\em++ main.cpp sanity.txt:
3.1.59|c:/Projects/emscripten/upstream/bin
For not it seems the issue was not caused (at least directly) by interaction with VS Code or CMake tools plugin for VSCode

Interesting! Thanks for the repro case. I wonder if we can make that into a test case? Maybe not worth it..