Remove DCLR_DOTNET_HOST_PATH cmake parameter, use dotnet from PATH

[Copilot]

The DCLR_DOTNET_HOST_PATH cmake option fails when the path contains spaces on Unix systems.

Changes

• src/coreclr/runtime.proj: Removed -DCLR_DOTNET_HOST_PATH cmake argument
• src/coreclr/clrdatadescriptors.cmake: Changed from ${CLR_DOTNET_HOST_PATH} to dotnet directly

The build system already places dotnet on PATH via dotnet.sh and InitializeDotNetCli, making the explicit path parameter unnecessary. This eliminates the quoting issue and aligns with the existing comment in clrdatadescriptors.cmake stating "this just uses dotnet from the PATH."

Original prompt

---

This section details on the original issue you should resolve

<issue_title>DCLR_DOTNET_HOST_PATH cmake option doesn't support spaces in path</issue_title>
<issue_description>If there are spaces in the path on unix they seem to get dropped and the build fails.</issue_description>

Comments on the Issue (you are @copilot in this section)

@agocke I wonder whether this option is necessary at all. If we're using the dotnet.sh script to download a custom dotnet it should be placed on the path. I don't think we should need to pass this down explicitly.

• FixesDCLR_DOTNET_HOST_PATH cmake option doesn't support spaces in path #122210

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[am11]

Why not simply change COMMAND ${CLR_DOTNET_HOST_PATH} ${CDAC_BUILD_TOOL_BINARY_PATH} ... to COMMAND "${CLR_DOTNET_HOST_PATH}" "${CDAC_BUILD_TOOL_BINARY_PATH}" ...? We shouldn't be using "dotnet from PATH", it fails when building in a new container scenarios (in a self-contained manner; where dotnet is not installed).

[agocke]

The problem isn’t in this file, it’s all the way up the chain of our Shell scripts. They aren’t preserving the quotes properly.

In the container scenario, dotnet.sh should be placing dotnet on the path, so I don’t see why it wouldn’t work.

[am11]

The problem isn’t in this file, it’s all the way up the chain of our Shell scripts. They aren’t preserving the quotes properly.

That's what cmake will take care of, we just need to quote first two path args. On this same line, we have CONTRACT_BASELINE_DIR which can also have space but that doesn't fail because it's quoted.

[agocke]

That's what cmake will take care of, we just need to quote first two path args.

I know you haven't validated this because I did, and that doesn't work.

[am11]

@agocke, do you mean having spaces in CDAC_BUILD_TOOL_BINARY_PATH without quotes and CONTRACT_BASELINE_DIR with quotes cause no problem but having CLR_DOTNET_HOST_PATH with or without quotes causes problem? That's strange.

[agocke]

having spaces in CDAC_BUILD_TOOL_BINARY_PATH without quotes and CONTRACT_BASELINE_DIR with quotes cause no problem

They may -- in my repro the paths do not have spaces. But my Mac does have spaces in the dotnet path, and it's broken.

[Copilot]

Pull request overview

This PR removes the DCLR_DOTNET_HOST_PATH cmake parameter that fails when paths contain spaces on Unix systems. The build system already ensures dotnet is available in PATH through dotnet.sh and InitializeDotNetCli, making the explicit path parameter redundant.

• Removes the cmake argument that passes DOTNET_HOST_PATH to the build system
• Updates the cmake command to use dotnet directly from PATH instead of the variable

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/coreclr/runtime.proj	Removes the -DCLR_DOTNET_HOST_PATH cmake argument from the build configuration
src/coreclr/clrdatadescriptors.cmake	Changes from using ${CLR_DOTNET_HOST_PATH} variable to directly invoking dotnet from PATH

[agocke]

@max-charlamb@rcj1 it looks like this was added for CDAC. Was this specifically working around a problem you ran into, or just trying to catch edge cases?

[am11]

The quoting issue was fixed by #124562.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[am11]

It was superseded by #124562.