Skip to content

Conversation

pavelsavara
Copy link
Member

@pavelsavara pavelsavara commented Oct 1, 2025

On top of #120359

  • refactor new eng/native.props
  • add host.native subset back for coreCLR browser
  • fix corehost/build.cmd
  • add CLR_ARTIFACTS_BIN_DIR
  • add NATIVE_JAVASCRIPT_BIN and move all JS outputs there
  • split System.Native.Browser-Rollup and System.Native.Browser-NpmInstall into it's own Common\JavaScript\CMakeLists.txt
  • make Rollup incremental
  • fix gcinfo and create wasm static lib
  • don't build browserhost for clr.runtime subset
  • split browserhost into libBrowserHost.a, so that it could be linked later on customer machine
  • make browserhost dependent on relevant .a files of libs.native+clr.runtime subsets, instead of CMake target and add_subdirectory

Fixes #120188

@pavelsavara pavelsavara added this to the 11.0.0 milestone Oct 1, 2025
@pavelsavara pavelsavara self-assigned this Oct 1, 2025
@pavelsavara pavelsavara added arch-wasm WebAssembly architecture area-Host os-browser Browser variant of arch-wasm labels Oct 1, 2025
@pavelsavara pavelsavara changed the title [browser] build [browser] build more coreCLR dependencies Oct 1, 2025
Copy link
Contributor

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

pavelsavara and others added 14 commits October 3, 2025 20:53
Co-authored-by: SingleAccretion <[email protected]>
- add host.native
- fix corehost/build.cmd
- add NATIVE_JAVASCRIPT_BIN and move all JS outputs there
- split System.Native.Browser-Rollup and System.Native.Browser-NpmInstall into it's own native\libs\Common\JavaScript\CMakeLists.txt
- make Rollup incremental
… later on customer machine

- make browserhost dependent on .a files of `libs.native+clr.runtime` subsets, instaed of CMake target and sub_direcotry
@pavelsavara
Copy link
Member Author

pavelsavara commented Oct 4, 2025

If browser isn't going to support the singlefilehost, just skip building it when targeting browser (preferred)

That's already done, I also prefer that.
I ask about singlefilehost for consistency sake (if it makes sense or not).

We used to build it separately and it caused a lot of pain.

@jkoritzinsky could you please share more details ? It seems unless I change my direction, I may suffer same pains.

For context:

  • mono on wasm is also linked from .a files in the last step of building runtime pack
  • the wasm product comes with wasm-tools workload that can re-link those same .a files on customer machine. We already suffer that.

@jkoritzinsky
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch-wasm WebAssembly architecture area-Host os-browser Browser variant of arch-wasm
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[browser][coreCLR] provide PRODUCT_VERSION_JS & CI_BUILD_JS
3 participants