[browser] build browserhost in host.native subset

[pavelsavara]

• add host.native subset back for coreCLR browser
• don't build browserhost for clr.runtime subset
• make browserhost dependent on relevant .a files of libs.native+clr.runtime subsets, instead of CMake target and add_subdirectory
• update eng/liveBuilds.targets
• introduce CORERUN_LIBS_ONLY to make libs build smaller when used from coreCLR CMake
• added CLR_ARTIFACTS_BIN_DIR, CMAKE_BUILD_LIBRARIES_CONFIGURATION, CMAKE_NET_CORE_APP_CURRENT_VERSION, CMAKE_BUILD_RUNTIME_CONFIGURATION
  • alternatively we can build the path SHARED_LIB_DESTINATION and SHARED_CLR_DESTINATION in MSBuild and pass that instead.

Contributes to #120206

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[jkoritzinsky]

For Linux and Windows, we were hitting issues with linker incompatibilities and a ton of complexity because of the flags we pass around and the fact that we shuffle pieces between different machines in the PR builds.

For wasm, we already have an established path of shipping static libs, so I'm not as concerned that we'll hit the same problem.

If you're able to pre-link everything with the new host like how we do the singlefilehost, I'd recommend that. If you can't, then splitting it is fine.

[pavelsavara]

@jkoritzinsky I rebased this PR on top of option B) that was already merged into main branch.

Now it should be easier to discuss option C)

I don't insist it needs to be done this way, but it's much closer to what customers would run if they link the .a files on their dev environment using workload (LLVM/emcc).

It also makes coreCLR CMake innner dev loop significantly faster. Emcc linking is slow and this way we only link corerun but not corehost in there. Effectively in half of the time.

I also updated the top description.

[Copilot]

Pull Request Overview

This PR restructures the browser (WASM) build for CoreCLR to separate the browserhost build into the host.native subset, aligning it with the standard build pattern. Previously, browserhost was built within the CoreCLR runtime subset, which violated the architecture where host components should be built separately.

Key Changes:

• Restored host.native subset for CoreCLR browser builds
• Removed browserhost from clr.runtime subset
• Changed browserhost dependencies from CMake targets to static library file paths
• Introduced CORERUN_LIBS_ONLY flag to reduce native library build scope when building for CoreCLR

Reviewed Changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/coreclr/CMakeLists.txt	Moved browser-specific build configuration from the runtime subset to the libs-native section and removed browserhost as a runtime dependency
src/native/corehost/browserhost/CMakeLists.txt	Changed from CMake target dependencies to explicit .a file dependencies; updated paths to use SHARED_LIB_DESTINATION and added new install targets
src/native/corehost/browserhost/sample/CMakeLists.txt	Updated sample paths from STATIC_LIB_DESTINATION to SHARED_LIB_DESTINATION
src/native/libs/CMakeLists.txt	Added conditional compilation guards using CORERUN_LIBS_ONLY to exclude non-essential libraries
src/native/libs/System.Native/CMakeLists.txt	Added dependency declarations for timezone data libraries
src/native/libs/Common/JavaScript/CMakeLists.txt	Added installation of package.json to sharedFramework
eng/native/configurepaths.cmake	Added CLR_ARTIFACTS_BIN_DIR variable definition
eng/native.props	Added CMake arguments for version and configuration information
eng/liveBuilds.targets	Updated artifact paths and file collections to reflect the new browserhost location in host.native subset
eng/Subsets.props	Added host.native to default CoreCLR browser subsets and reorganized libs.native subset definition

[pavelsavara]

I think we can do this as a first pass and revisit in the future. I really don't like that this introduces a dependency from the native builds on the managed builds (we already have the reverse for NativeAOT), but that's something we could address in a future PR (ie the B1 alternative above).

I see the pain point with the dependency direction. If the changes to generated entrypoints are rare, we can keep the generated entrypoints in the repo (B1) and add a step after native and managed are built? This step would compare generated ones with the repo ones, fail the build if they differ and request manual update to the sources in the repo.

We don't have to rush this PR, if we think we are going to return do B1 anyway.

Before I close this, does any of you feel that C) with pre-generated wasm-pinvoke.c in git would be better than B1 ?
I feel like that for local build time reasons, but I don't insist.

[jkotas]

pre-generated wasm-pinvoke.c in git would be better than B1

I would avoid pre-generated wasm-pinvoke.c in git.

I feel like that for local build time reasons, but I don't insist.

This should not be that bad if the generation is done in incremental build friendly fashion.

If you are touching on that the incremental builds are slow, I think it is a general problem that we have been introducing by representing more dependencies correctly in the build system. It makes the incremental builds slower and slower. It has been very apparent in some of the inner loop experiences under libraries.

I think the solution for that is to introduce gestures that one can use to skip the slow dependency checks, such as --no-dependencies switch for dotnet build.

[pavelsavara]

Well, my current incremental experience on windows.

PS D:\runtime> .\build.cmd -bl -os browser -subset clr.runtime -c Debug
Determining projects to restore..

...

[5/13] Building C object gc/unix/CMakeFiles/gc_pal.dir/D_/runtime/artifacts/obj/_version.c.o
  [6/13] Building C object hosts/corerun/CMakeFiles/corerun.dir/D_/runtime/artifacts/obj/_version.c.o
  [7/13] Linking CXX static library dlls\mscoree\coreclr\libcoreclr_static.a
  [8/13] Building CXX object corehost/hostmisc/CMakeFiles/hostmisc.dir/utils.cpp.o
  [9/13] Linking CXX static library corehost\hostmisc\libhostmisc.a
  [10/13] Linking CXX executable hosts\corerun\corerun.js
...
[12/13] Linking CXX executable corehost\browserhost\dotnet.native.js
Time Elapsed 00:00:44.14

• This is second run of this command in the row, with no changes on disk in between.
• Something touched _version.c and that triggers compilation
• That triggers 2x linking of the final app corerun and corehost
• Emcc linking is the slowest part. This is why I don't want to link 2 apps in my inner loop.
• Overall 44 seconds on brand new i7 HP laptop - for no change.

[janvorli]

It seems this is yet another time when the version.c is compiled unconditionally, triggering relinking. We should fix that.

[SingleAccretion]

Emcc linking is the slowest part

Side note: this is because of #119639. Adding -sWASM_BIGINT=1 will make it much faster.

[pavelsavara]

My current understanding is that B1 would not be the final solution because of libs R2R and so we would do late linking .a files.
This is a step toward that direction. It should also help Radek to implement pinvoke gen in lib.sfx.

Is there further feedback or we could merge this ? @jkotas @jkoritzinsky @radekdoulik

[jkoritzinsky]

I'm fine with this in its current state.

[pavelsavara]

/ba-g CI timeout