Vscode-cmake-tools: CMake Tools doesn't recognize CMakeLists.txt on Windows

[Quincunx271]

Brief Issue Summary

On Windows, when configuring cmake through CMake Tools, the "You do not have a CMakeLists.txt" message appears even though the file does exist.

Expected:

The project configures

Apparent Behavior:

CMake Tools doesn't find the CMakeLists.txt

CMake Tools Log

[cms-client] Configuring using the "Ninja" CMake generator
[cms-client] Configuring using the "Ninja" CMake generator

Developer Tools Log

 INFO no standard startup: panel is active
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:19.211Z [debug] [rollbar] Updated Rollbar payload {"environment":"production","packageJSON":{"name":"cmake-tools","version":"1.1.1"},"client":{"code_version":"1.1.1"},"platform":"win32"}
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:19.439Z [debug] [kit] Reading kits file C:\Users\Justin\AppData\Roaming\CMakeTools\cmake-tools.json
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:19.440Z [debug] [kit] Not reading non-existent kits file: c:\Users\Justin\Documents\CPP\pitchfork\.vscode\cmake-kits.json
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:19.606Z [info] [kit] Successfully loaded 12 kits from C:\Users\Justin\AppData\Roaming\CMakeTools\cmake-tools.json
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:19.609Z [debug] [main] Safe constructing new CMakeTools instance
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:19.611Z [debug] [variant] Constructing VariantManager
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:19.613Z [debug] [main] Constructing new CMakeTools instance
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:19.615Z [debug] [main] Starting CMakeTools second-phase init
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:19.617Z [debug] [rollbar] Checking Rollbar permissions
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:19.625Z [debug] [rollbar] Rollbar enabled?  true
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:19.739Z [info] [variant] Loaded new set of variants
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:19.742Z [debug] [main] CMakeTools instance initialization complete.
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:19.743Z [debug] [main] Injecting new Kit into CMake driver
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:19.747Z [debug] [kit] Reading kits file C:\Users\Justin\AppData\Roaming\CMakeTools\cmake-tools.json
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:19.767Z [info] [kit] Successfully loaded 12 kits from C:\Users\Justin\AppData\Roaming\CMakeTools\cmake-tools.json
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:19.769Z [debug] [kit] Not reading non-existent kits file: c:\Users\Justin\Documents\CPP\pitchfork\.vscode\cmake-kits.json
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:19.771Z [debug] [rollbar] Updated Rollbar payload {"kit":{"name":"Visual Studio Community 2017 - amd64","visualStudio":"e3c5dd2b","visualStudioArchitecture":"amd64","preferredGenerator":{"name":"Visual Studio 15 2017","platform":"x64"}}}
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:19.771Z [debug] [main] Injecting new Kit into CMake driver
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] activating extension
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:22.349Z [debug] [extension] Configuring workspace on open  file:///c%3A/Users/Justin/Documents/CPP/pitchfork
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:22.351Z [debug] [main] Run configure  
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:22.351Z [debug] [main] Saving open files before configure/build
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:22.795Z [debug] [main] Starting new CMake driver
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:22.796Z [debug] [main] Starting CMake driver
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:22.797Z [debug] [driver] CMakeDriver Kit set to Visual Studio Community 2017 - amd64
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:24.148Z [debug] [driver] Run _refreshExpansions
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:24.149Z [debug] [cms-driver] Run doRefreshExpansions
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:24.149Z [debug] [driver] Run _refreshExpansions cb
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:24.159Z [debug] [cms-client] Started new CMake Server instance with PID 6536
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:25.162Z [debug] [driver] Trying to detect generator supported by system
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:25.192Z [info] [cms-client] Configuring using the "Ninja" CMake generator
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:25.196Z [debug] [driver] Setting new variant , Emit debug information without performing optimizations
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:25.196Z [debug] [driver] Run _refreshExpansions
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:25.197Z [debug] [cms-driver] Run doRefreshExpansions
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:25.197Z [debug] [driver] Run _refreshExpansions cb
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:25.265Z [debug] [cms-client] Started new CMake Server instance with PID 3496
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:26.266Z [debug] [driver] Trying to detect generator supported by system
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:26.301Z [info] [cms-client] Configuring using the "Ninja" CMake generator
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:26.398Z [debug] [driver] Start configure  
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:26.398Z [debug] [driver] Runnnig pre-configure checks and steps
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:272 [Extension Host] [CMakeTools] 2018-09-03T04:29:26.399Z [debug] [driver] No configuring: There is no  c:/users/justin/documents/cpp/pitchfork/cmakelists.txt
/C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:2386 You do not have a CMakeLists.txt
t.onDidNotificationChange @ /C:/Program Files/Microsoft VS Code/resources/app/out/vs/workbench/workbench.main.js:2386

Platform and Versions

• Operating System: Windows
• CMake Version: 3.12.1
• VSCode Version: 1.26.1
• CMake Tools Extension Version: 1.1.1
• Compiler/Toolchain: Visual C++ 2017

Other Notes/Information

Clicking "Quickstart a new CMake project" fails with the message: "This workspace already contains a CMakeLists.txt!"

I'm guessing this has to do with the fact that Windows uses case insensitive file paths.

[Quincunx271]

It's happening with the Pitchfork project, but not with other projects.

[Randshot]

@Quincunx271
I have tried it on macOS and it worked just fine, so the problem isn't originating from the project (pitchfork) itself.
I will try it on Windows some time later.

I can't understand your guess with case case-insensitive paths, since it seems like you don't have any problems with other projects?

Also, have you tried configuring from the command line yet? Does it work there?

[Quincunx271]

@Randshot I think I should try a fresh git clone to see if that fixes the issue.

I originally thought it had to do with case-insensitive paths, but then once I realized it worked with other projects, I no longer thought that.

Yes, I tried configuring from the terminal and it does work there.

[Quincunx271]

Here's what happened: I created the directory from the Windows Subsystem for Linux (WSL), even though it is a Windows folder. Windows automatically enables case sensitivity for files created from the WSL, meaning that the paths are actually case sensitive.

I verified it by running fsutil.exe:

C:\...\pitchfork>fsutil.exe file queryCaseSensitiveInfo .
Case sensitive attribute on C:\...\pitchfork is enabled.

[Randshot]

Well, that's a weird edge case.
Now the question is how to best detect edge cases like these.
I guess we could run fsutil.exe on the workspace folder.

[Quincunx271]

I don't think that running fsutil.exe on the workspace folder is sufficient to catch all cases. AFAIK, case-sensitivity can apply to any directory. You'd have to run fsutil.exe on every directory in the workspace that we want to worry about. I don't think that's a feasible solution.

The ideal solution is if Windows provided some form of path normalization function (or at the very least, a path equality function).

Do we need to include lowercasing for path normalization on Windows, or can we drop that entirely?

[Randshot]

@Quincunx271 I think internally it is needed, for comparing paths and the like.
I have found this comment on an MSDN blog post:

Matt Waters
June 21, 2018 at 17:16
I used WSL for git with a legacy compiler that always expected case-insensitivity. I think it makes file names all lower or all upper case at some point. I checked out an old branch which deleted some directories. The legacy compiler failed due to case sensitivity. I had no idea about this feature.

Also, I did not just want to fix all new directories with fsutil. There were a lot of directories and I may have to change them on every checkout between branches.

In case people with similar issues find this blog post first (like I did), I will give how I fixed the issue. I had to create /etc/wsl.conf within WSL. The following lines were added:

[automount]
options = case=off

At least for me, I also had to restart my whole computer, not just WSL, to implement wsl.conf. Not sure why. The wsl.conf blog post just says to restart WSL, which didn’t work for me.

This might be a temporary solution? Don't know whether this will break applications on the Linux side though.

[Quincunx271]

Yeah, the user turning off case sensitivity globally with wsl.conf is an option, and it shouldn't break anything in Linux except for things which assume they can create colliding files.

My workaround was to turn off case sensitivity for the single project folder. CMake Tools seems to interact fine if I do that

[vector-of-bool]

That's gross. There have been a few bugs opened related to path normalization. There's actually a change I have pending for the 1.1.2 release branch (uncommitted) that will change the way the ext does path normalization. It may or may not help with this situation. I just wish the Windows API gave a "canonicalize path" function.

Case-insensitive paths are a mistake.

[marc-h38]

OMG, per-directory case-sensitivity... Thank you so much for root-causing and sharing this, I would have never suspected something that insane.

Similar to the example above, I experienced this error in many random places:

CMake Error at foo\CMakeLists.txt:123 (ADD_SUBDIRECTORY):
  The source directory

    C:\Users\joe\Project\foo\bar\

  does not contain a CMakeLists.txt file.

This was happening in many random directories because I initially checked out Project in Windows and updated it later from Windows Subsystem for Linux. I promise I won't do that again.

WSL is generally awesome but the default way it uses this bug^H feature by default is really bad.

I found a recursive "repair" script in PowerShell there: https://stackoverflow.com/questions/51591091/apply-setcasesensitiveinfo-recursively-to-all-folders-and-subfolders

If you're reading this there's a good chance you've just been hit by this default WSL behaviour too hence you may prefer to start from a (tested!) repair script in shell:

time find -type d -exec /mnt/c/Windows/System32/fsutil.exe file queryCaseSensitiveInfo {} \; | awk '/is enabled/ { print $6 } ' | while read -r; do /mnt/c/Windows/System32/fsutil.exe file setCaseSensitiveInfo "$REPLY" disable; done

As opposed to the PowerShell repair script above this shell version changes only the directories that need changing. This may or may not be faster, in any case it took only a few minutes on ~15000 directories which was fast enough for me.

[marc-h38]

I have no idea how to fix this but in the meantime a small error message change would really go a long way and save a number of lives. Something like:

  The source directory
    C:\Users\joe\Project\foo\bar\
  does not contain a CMakeLists.txt file. Note Windows supports per-directory case-sensitivity. We're not joking.

[vector-of-bool]

@Quincunx271 does this still occur? I'm not sure if the 1.1.2 fixes changed the behavior here or not.

[Quincunx271]

Sorry, I haven't gotten around to checking this yet. I'd have to make a project with case sensitivity to test it, and I haven't had much free time in the past few weeks.

[Quincunx271]

AFAICT, this is solved.