VS2022 uses an invalid toolset for Linux

[xoorath]

The issue

Generated Visual Studio 2022 projects seem to be using the wrong platform toolset when targeting Linux. I'm specifying the toolset as clang in lua and I've also tried msc-clang, msc-clang-cl and msc-Clang for Windows Subsystem for Linux.

What I've tried and expected

My expectations is that clang or msc-clang or some similar option should select the Clang for Windows Subsystem for Linux platform toolset for the generated project file.

What's actually happening when Linux is the active target:

toolset value in lua	what I see in visual studio prop pages	what I expect to see
clang	Visual Studio 2022 (v143) (not installed)	Clang for Windows Subsystem for Linux
msc	Visual Studio 2022 (v143) (not installed)	invalid or Visual Studio 2022 (v143) (not installed)
msc-clang	clang (not installed)	invalid or Clang for Windows Subsystem for Linux
clang-cl	cl (not installed)	invalid or Clang for Windows Subsystem for Linux
msc-clang-cl	clang-cl (not installed)	invalid or Clang for Windows Subsystem for Linux

Minimal repro case

I have a simple minimal example with the following layout:

<project root>/premake5.exe
<project root>/main.cpp
<project root>/premake5.lua

main.cpp

#include <iostream>

int main(int argc, char** argv)
{
    std::cout << "hello world" << std::endl;
    return 0;
}

premake5.lua

workspace "wrong-template"
    configurations { "Debug" }
    platforms { "linux" }
    toolset "clang"


project "wrong-template"
    kind "ConsoleApp"
    language "C++"
    files {  "main.cpp" }

I'm invoking premake with .\premake5.exe vs2022.

My VS2022 version is:

Microsoft Visual Studio Community 2022 (64-bit) - Current
Version 17.14.18 (October 2025)

Premake5 version

premake5 (Premake Build Script Generator) 5.0.0-beta7

[samsinsane]

Thank you for such a thorough bug report. I haven't had a chance to use your minimal repro yet, but I did notice you're not specifying system "linux" in the Lua or --os=linux on the command line, so Premake will be generating a regular Windows VS project. Also, looking into the code, it looks like you'll need to specify toolchainversion. I'm not sure this requirement is documented anywhere, but you will see an error about this after specifying either system "linux" or --os=linux:

premake-core/modules/vstudio/vs2010_vcxproj.lua

Lines 3962 to 3994 in bb5f74f

	function m.linuxPlatformToolset(cfg)
	local tool, version = p.config.toolset(cfg)
	if not version then
	local value = p.action.current().toolset
	tool, version = p.tools.canonical(value)
	end
	local gcc_map = {
	["remote"] = "Remote_GCC_1_0",
	["wsl"] = "WSL_1_0",
	["wsl2"] = "WSL2_1_0",
	}
	local clang_map = {
	["remote"] = "Remote_Clang_1_0",
	["wsl"] = "WSL_Clang_1_0",
	["wsl2"] = "WSL2_Clang_1_0",
	}
	if cfg.toolchainversion then
	local map = iif(cfg.toolset == "gcc", gcc_map, clang_map)
	version = map[cfg.toolchainversion]
	end
	if version then
	m.element("PlatformToolset", nil, version)
	else
	p.error('Invalid toolchainversion (%s) for the selected toolset (%s).', cfg.toolchainversion, cfg.toolset)
	end
	end

I think all you'll need to add to your Premake5 is the following:

system "linux"
toolchainversion "wsl" -- or wsl2

I'll still try to make some time to test this out unless you beat me to testing that out.

---

@nickclark2016 looks like it might be time to migrate toolset version to a dedicated API, like toolchainversion which might be better renamed to toolsetversion. We want to allow users to specify versions Premake doesn't know about, but we also want to give users guidance when they're using invalid toolsets and I think splitting the versioning out would do that. What do you think?

[xoorath]

Thanks for catching that. I definitely got platforms and system confused.

The documentation for platforms says that value is not used outside of display in the IDE. That must no longer be the case from my tests. Maybe it's being used as a fallback for some things but isn't well tested?

The platforms listed here are just names to be displayed in the IDE, with no intrinsic meaning.

I'll try your suggestions shortly. Thank you.

[xoorath]

Alright, I've tried again adding system "linux" and subsystem "wsl2".

This is my premake5.lua now:

workspace "wrong-template"
    configurations { "Debug" }
    platforms { "linux" }
    system "linux"
    toolchainversion "wsl2"

    toolset "clang"


project "wrong-template"
    kind "ConsoleApp"
    language "C++"
    files {  "main.cpp" }

With this I am able to build and the property pages showed the platform toolset was "WSL2 Clang Toolset" as I expect.

This doesn't yet allow me to debug, though.

Edit: The following isn't especially useful info.

I'm noticing it's looking for /home/xo/[...] which is wrong, it should be looking in /mnt/c/Users/xo/[...]. The Linux user's home directory is thankfully separate from my Windows user home directory. I can't see any way to change this from within visual studio itself.

I tried creating another user in WSL, setting it as the default WSL user and adding it for remote debugging over SSH in Visual studio. For whatever reason even that results in Visual Studio expecting the build output under $HOME/[...].

[xoorath]

Okay, I see that files are being copied to the home directory which I imagine is an expected behavior... But there's a platform directory in that path which isn't matching the one expected by the debugger.

$ tree ~/projects/wrong-template/
/home/xo/projects/wrong-template/
├── bin
│   └── x86
│       └── Debug linux
│           └── wrong-template
├── main.cpp
└── obj
    └── x86
        └── Debug linux
            └── main.o

7 directories, 3 files
$ ~/projects/wrong-template/bin/x86/Debug\ linux/wrong-template
hello world

So that's working if I run the program manually. If I comment out platforms { "linux" } from my premake5.lua, re-generate and re-build the copied build output is a bit different but still not going to work.

$ tree ~/projects/wrong-template/
/home/xo/projects/wrong-template/
├── bin
│   └── x86
│       ├── Debug
│       │   └── wrong-template
│       └── Debug linux
│           └── wrong-template
├── main.cpp
└── obj
    └── x86
        ├── Debug
        │   └── main.o
        └── Debug linux
            └── main.o

9 directories, 5 files

The property pages for Debugging also appear to have an extra ) at the end of the remote deploy directory.

I can only seem to resolve this by setting the program value to $(RemoteRootDir)/$(ProjectName)/bin/x86/$(Configuration)/$(TargetName)$(TargetExtension)

All that to say... I'm unblocked but it's pretty weird! :D