When building on Windows, which command-line interpreter should I use?

[Jayman2000]

I’m working on a PR, and I want to test it out on Windows. The instructions for compiling Descent 3 on Windows say:

Building - Windows

Requires Visual Studio 2022 and C++ Tools (cmake and vcpkg)

Install and configure vcpkg:

git clone https://github.com/microsoft/vcpkg.git
cd vcpkg && bootstrap-vcpkg.bat
setx VCPKG_ROOT="C:\path\to\vcpkg"
setx PATH=%VCPKG_ROOT%;%PATH%

Build Descent 3:

cmake --preset win -D ENABLE_LOGGER=[ON|OFF]
cmake --build --preset win --config [Debug|Release]

Now that I’ve installed Visual Studio Build Tools 2022 with the “Desktop development with C++” workload, there are several new entries in my Start menu:

• Developer Command Prompt for VS 2022
• Developer PowerShell for VS 2022
• x64 Native Tools Command Prompt for VS 2022
• x64_x86 Cross Tools Command Prompt for VS 2022
• x86 Native Tools Command Prompt for VS 2022
• x86_x64 Cross Tools Command Prompt for VS 2022

In order to run the commands in the README, I need choose one of those command-line interpreters. Which one should I choose?

[SiriusTR]

I would probably use the first one (Developer Command Prompt). Technically you don't have to use any of them - you could just use cmd.exe - but there is some path configuration required for CMake, which it looks like VS already does for you in that environment.

[Jayman2000]

OK. I tried using the Developer Command Prompt for VS 2022, but I ran into several issues. When I tried to run the first setx command, this happened:

D:\VC\Not mine\vcpkg>setx VCPKG_ROOT="D:\VC\Not mine\vcpkg"
ERROR: Invalid syntax.
Type "SETX /?" for usage.

D:\VC\Not mine\vcpkg>

According to SETX /? you’re supposed to do SETX <name> <value>, not SETX <name>=<value>. Once I figured that problem out, I ran into a different problem with the second setx command:

D:\VC\Not mine\vcpkg>setx VCPKG_ROOT "D:\VC\Not mine\vcpkg"

SUCCESS: Specified value was saved.

D:\VC\Not mine\vcpkg>setx PATH %VCPKG_ROOT%;%PATH%
ERROR: Invalid syntax. Default option is not allowed more than '2' time(s).
Type "SETX /?" for usage.

D:\VC\Not mine\vcpkg>

The value of VCPKG_ROOT contains a space which causes %VCPKG_ROOT%;%PATH% to expand into more than one argument. I was able to fix this problem by putting quotation marks around %VCPKG_ROOT%;%PATH%. Unfortunately, this lead to another problem:

D:\VC\Not mine\vcpkg>setx PATH "%VCPKG_ROOT%;%PATH%"

WARNING: The data being saved is truncated to 1024 characters.

SUCCESS: Specified value was saved.

D:\VC\Not mine\vcpkg>

Not only did that command permanently change my Path variable, it changed it to a bad truncated value. Previously, my Path variable looked like this:

After that setx command, my Path variable looked like this:

I had to revert my computer to a previous system restore point in order to undo the changes to my Path variable.

---

SETX appears to be the wrong command to use here. I tried using SET instead of SETX, and it seems to have worked:

D:\VC\Partially mine\Descent3\repo>set VCPKG_ROOT=D:\VC\Not mine\vcpkg

D:\VC\Partially mine\Descent3\repo>set PATH=%VCPKG_ROOT%;%PATH%

D:\VC\Partially mine\Descent3\repo>cmake --preset win -D ENABLE_LOGGER=ON
Preset CMake variables:

  CMAKE_TOOLCHAIN_FILE:FILEPATH="D:\VC\Not mine\vcpkg/scripts/buildsystems/vcpkg.cmake"

-- Running vcpkg install
Detecting compiler hash for triplet x64-windows...
Compiler found: C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.39.33519/bin/Hostx64/x64/cl.exe
Detecting compiler hash for triplet x86-windows...
Compiler found: C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/VC/Tools/MSVC/14.39.33519/bin/Hostx64/x86/cl.exe
All requested packages are currently installed.
Total install time: 1.5 us
The package gtest is compatible with built-in CMake targets:

    enable_testing()

    find_package(GTest CONFIG REQUIRED)
    target_link_libraries(main PRIVATE GTest::gtest GTest::gtest_main GTest::gmock GTest::gmock_main)

    add_test(AllTestsInMain main)

The package spdlog provides CMake targets:

    find_package(spdlog CONFIG REQUIRED)
    target_link_libraries(main PRIVATE spdlog::spdlog)

    # Or use the header-only version
    find_package(spdlog CONFIG REQUIRED)
    target_link_libraries(main PRIVATE spdlog::spdlog_header_only)

The package zlib is compatible with built-in CMake targets:

    find_package(ZLIB REQUIRED)
    target_link_libraries(main PRIVATE ZLIB::ZLIB)

-- Running vcpkg install - done
-- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.22631.
Enabling Logging
-- Configuring done (3.7s)
-- Generating done (1.2s)
-- Build files have been written to: D:/VC/Partially mine/Descent3/repo/builds/win

D:\VC\Partially mine\Descent3\repo>cmake --build --preset win --config Debug
MSBuild version 17.9.8+b34f75857 for .NET Framework

  1>Checking Build System
  inetfile.vcxproj -> D:\VC\Partially mine\Descent3\repo\builds\win\netcon\inetfile\Debug\inetfile.lib
  […]
  Descent3.vcxproj -> D:\VC\Partially mine\Descent3\repo\builds\win\Descent3\Debug\Descent3.exe
  Building Custom Rule D:/VC/Partially mine/Descent3/repo/CMakeLists.txt

D:\VC\Partially mine\Descent3\repo>

Oddly enough, it looks like you need to use quotation marks when using SETX and like you need to not use quotation marks when using SET. When I use quotation marks with SET, it puts quotation marks in the value of the environment variable.

[george-tsiros]

had to revert my computer to a previous system restore point in order to undo the changes to my Path variable

you didn't need to go that far, you just had to remove the "program f" entry and the "%vcpk..." entry from the list of entries for %path% 🫤

[Jayman2000]

Could you elaborate? Why do you think that I didn’t need to go that far?

[george-tsiros]

Because if %path% was corrupted, the only thing you need to fix to get back the old %path% value, is to... put that old value back into %path%. It's like, if you put the wrong wallpaper on your desktop, you don't need to buy a new computer. Just, put the old wallpaper back. %path% does not have any special characters or some special, weird purpose: it's just a set of locations where the command line will look for executables. When you type curl, for example, on the command line, it runs curl.exe that it finds at c:\windows\system32\ because if you look in the screenshot you put above, that directory is one of the directories in %path%. If there is a curl.bat in the current directory you are in, then this .bat file will run instead of the .exe in \windows\system32. You can check what will run with where curl. This, is how if you write 'devenv' in command line, you actually run devenv*.com* while if you run "visual studio" from the start menu, devenv*.exe* runs.

Coincidentally, the two screenshots you put in your comment, I think they are not the same thing, I suspect one is the 'user variables' and the other is the 'system variables'.

In any case, I fear this is not the place to discuss this particular thing.

[Jayman2000]

Because if %path% was corrupted, the only thing you need to fix to get back the old %path% value, is to... put that old value back into %path%. It's like, if you put the wrong wallpaper on your desktop, you don't need to buy a new computer. Just, put the old wallpaper back.

I agree. If the Path variable gets corrupted, then the only thing that you need is set the Path variable back to its old value. Your simile is very accurate. Fixing a wrong Path variable is very similar to fixing a wrong wallpaper.

That being said, I think that your explanation is missing an important nuance. In your simile, the user has to remember the old wallpaper. If the user does not remember which wallpaper was the old one, then the user will not be able to put the old wallpaper back. That was the situation that I was in after I had figured out the SETX syntax errors. I could tell that my Path had been changed, but I didn’t know what its original value was. I did a system restore in order to figure out what the original value was.

Additionally, I disagree with the strategy of removing %VCPKG_ROOT% and C:\Program F from the corrupted Path. Removing those two items would not get me my old Path back. Looking at one of the screenshots that I posted earlier, I can see that removing those two items would result in a Path variable that contains 16 items. Looking at the other screenshot that I posted earlier, I can see that my old Path variable contained only 6 items.

I agree that doing a system restore is overkill in this situation. The fact that I had to do a system restore was frustrating. Do you know of a better way to figure out the original value of Path after making a mistake like this?

%path% does not have any special characters or some special, weird purpose: it's just a set of locations where the command line will look for executables. When you type curl, for example, on the command line, it runs curl.exe that it finds at c:\windows\system32\ because if you look in the screenshot you put above, that directory is one of the directories in %path%. If there is a curl.bat in the current directory you are in, then this .bat file will run instead of the .exe in \windows\system32. You can check what will run with where curl. This, is how if you write 'devenv' in command line, you actually run devenv*.com* while if you run "visual studio" from the start menu, devenv*.exe* runs.

Thank you for providing this information. I already knew how Windows determines the absolute paths of external commands, but that explanation confirmed that my understanding is correct.

Coincidentally, the two screenshots you put in your comment, I think they are not the same thing, I suspect one is the 'user variables' and the other is the 'system variables'.

I disagree. It’s been a while, but if I remember correctly, both of those screen shots are from the user variables section. I tried recreating the scenario that lead to those two screenshots, and I got similar results.

In any case, I fear this is not the place to discuss this particular thing.

Why not?