2

I am trying to use the Build --> Compile functionality of Visual Studio in an almost "Hello World!" program.

On a new CMake Project, I set up CMakeSettings configuration to WSL-Clang-Debug.

Then I edited CMakeProject3.cpp to include some header file (gdal.h), which is found by CMake when it generates its cache.

// CMakeProject3.cpp : Defines the entry point for the application.
//

#include "CMakeProject3.h"
#include "gdal.h"

using namespace std;

int main()
{
    cout << "Hello CMake." << endl;
    return 0;
}

The CMakeLists.txt file looks like this:

# CMakeList.txt : CMake project for CMakeProject3, include source and define
# project specific logic here.
#
cmake_minimum_required (VERSION 3.8)

# Add source to this project's executable.
add_executable (CMakeProject3 "CMakeProject3.cpp" "CMakeProject3.h")

# TODO: Add tests and install targets if needed.
find_package(GDAL)
target_link_libraries(CMakeProject3 PRIVATE GDAL::GDAL)

Building, which I thought meant compiling and linking succeeds, but if I try to compile only, it fails:

 cd /mnt/c/Users/user/source/repos/CMakeProject3/out/build/WSL-Clang-Debug;export CFLAGS=-fno-limit-debug-info;export CXXFLAGS=-fno-limit-debug-info;clang++ -fno-limit-debug-info -g   -I"C:\Users\user\AppData\Local\Microsoft\Linux\HeaderCache\1.0\wsl_wsl\usr\include\gdal" -c "/mnt/c/Users/user/source/repos/CMakeProject3/CMakeProject3/CMakeProject3.cpp"



Build failed.

If I try to run the exact same command in WSL, it's even more obvious why it fails. It can't find gdal.h. This is not because it doesn't exist under C:\Users\user\AppData\Local\Microsoft\Linux\HeaderCache\1.0\wsl_wsl\usr\include\gdal, but because in wsl it's supposed to be under /mnt/c/Users/andrei/AppData/Local/Microsoft/Linux/HeaderCache/1.0/wsl_wsl/usr/include/gdal

If I run the above command with the correct path style, the compiling succeeds.

How do I convince Visual Studio to not try to use windows style paths in wsl?

If you want to try the exact same example, you'll have to first run these in wsl:

sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable
sudo apt update
sudo apt install libgdal-dev
sudo apt install openssh-server g++ gdb make ninja-build rsync zip

Is this a bug in Visual Studio, or am I not setting something somewhere that I should be setting?

Andrei
  • 961
  • 1
  • 9
  • 29
  • Did you run `cmake .` from inside your WSL? It looks a lot like you ran cmake from windows and then tried to compile it in WSL which obviously would fail. – super Oct 25 '20 at 18:45
  • I am not running anything directly, I am using Visual Studio and I am just clicking on Build --> Compile. CMake runs whenever CMakeLists.txt is edited, or when the configuration is changed, e.g. to WSL-Clang-Debug – Andrei Oct 25 '20 at 18:48
  • the only thing I ran directly, just for testing, was the command I copy-pasted from the Build Output of the Compile command, which I then adapted to unix path style – Andrei Oct 25 '20 at 18:49
  • Do you have the remote plugin enabled and vscode is in your WSL environment? – super Oct 25 '20 at 18:50
  • 1
    Also note that to rebuild with cmake, you need to manually remove the generated files like CMakeFiles and CMakeCache. – super Oct 25 '20 at 18:51
  • yes, if I don't ```#include gdal.h```, everything works perfectly, including the Compile command. Actually, as I mentioned, even with the include, building works, which includes compiling, just separate compiling fails. – Andrei Oct 25 '20 at 18:52
  • Try rebuilding cmake from wsl manually. I still think that is your problem. Is rebuild the right word? Re-run `cmake .` manually from within WSL after you have removed CMakeFiles and CMakeCache. – super Oct 25 '20 at 18:55
  • I deleted the cache about a thousand times, and when it's regenerated, gdal is found at the correct location in wsl – Andrei Oct 25 '20 at 18:56
  • am I supposed to manually run cmake in wsl every time? or are you suggesting this only for testing purposes? – Andrei Oct 25 '20 at 19:02

0 Answers0