[browser] build browserhost in host.native subset

[pavelsavara]

• refactor new eng/native.props
• add host.native subset back for coreCLR browser
• fix corehost/build.cmd
• add CLR_ARTIFACTS_BIN_DIR, CMAKE_BUILD_LIBRARIES_CONFIGURATION
• add STATIC_LIB_DESTINATION and move all JS outputs there
• split System.Native.Browser-Rollup and System.Native.Browser-NpmInstall into it's own Common\JavaScript\CMakeLists.txt
• 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

[dotnet-policy-service]

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

[pavelsavara]

For subset host.native that is building corehost/browserhost I disconnected it from building it's own libs and runtime and now it depends you to build libs.native+clr.runtime subsets earlier. That should also happen in correct order if you build clr+libs subsets .

Bear with me, this is still work in progress. I know it's large change, but hopefully I will merge large part of it as #120359. You can ignore changes under src\tests\** for this PR

@jkoritzinsky - Jeremy, could you please share your thoughts ?
Context: browserhost is also statically linked like singlefilehost, but it grows significantly different. So it's not a code reuse. Also emscripten+typescript is making coreclr native build quite slow, so I didn't want to add more to that.
Why is singlefilehost built as part of coreclr ?

runtime/src/coreclr/CMakeLists.txt

Line 93 in 51ca4ba

add_subdirectory(${CLR_SRC_NATIVE_DIR}/libs libs-native)

runtime/src/coreclr/CMakeLists.txt

Line 69 in 51ca4ba

add_dependencies(runtime singlefilehost)

@janvorli prefers consistency over speed for corerun, so I keep it building native libs as add_subdirectory as it was for singlefilehost. Because corerun for WASM needs to statically link System.Native-Static, System.Native.Browser-Static, etc

cc @akoeplinger

[jkoritzinsky]

singlefilehost is built as part of CoreCLR as it's significantly easier to build all of the components at once instead of shuffling them between machines. We used to build it separately and it caused a lot of pain.

If you wish, there's two options I'd recommend for wasm:

• If browser isn't going to support the singlefilehost, just skip building it when targeting browser (preferred)
• Introduce a new "component" in the coreclr native build for singlefilehost, and update clr.runtime to automatically include it everywhere but browser (only should be done if we're planning on eventually supporting singlefilehost for browser)

[pavelsavara]

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]

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]

This sort of implicit dependency can be really finicky.
In particular, I'm not a fan of CLR_ARTIFACTS_BIN_DIR and CMAKE_BUILD_LIBRARIES_CONFIGURATION

@jkoritzinsky I'm not fan either but I don't have better idea. Let's discuss options or invent something else

A) ideally we would have only one CMake root for all native builds, on all targets.

• we have 6 or more CMake roots: coreclr, libs, host, mono, mono cross, runtime tests ... what else ?
• we have to manually sync build flags among them, that sucks
• there are multiple flavors of batch files starting those native builds, some of them are really ugly
• but lot of other things would probably break when we try to refactor this
• I feel that's not on critical path for WASM right now. Other volunteers ?

B) singlefilehost style, static linking of host and libs within coreclr root:

• this is poor version of A)
• does it matter that singlefilehost doesn't respect any of the libs.native and host.native CMake root arguments ?
• for example, this setup doesn't respect -lc Release which is necessary for src/tests. Interpreter doesn't run in Release yet.
• are we going to install lib and host .a files from that root, so that we could link them later out-of tree ?
• if so, are we need to match with liveBuild/runtime pack expectations for libs
• if not, we are shipping .a files which are not used/tested by default build.
• are we going to eliminate libs.native and host.native on WASM because they would go un-used ?
• slow inner loop for corerun

C) what I'm doing in this PR. 3 cmake roots and loose dependency via msbuild

• this is what Mono does: link .a files later
• if you are testing with browserhost in your inner loop you need to make sure that you re-build dependencies yourself.
• that is also benefit at the same time, you don' have rebuild libs if you only make changes to host. Or typescript only.
• compiler flags may drift apart with time.
  • I plan to introduce further unification to single place, probably eng/native.props like on this PR.
• inner loop builds of corerun are faster
• it produces all the .a files that would be necessary for the workload build on customer machine
• CLR_ARTIFACTS_BIN_DIR & CMAKE_BUILD_LIBRARIES_CONFIGURATION are smell. Is there better style ?

cc: @jkotas @AaronRobinsonMSFT @janvorli @akoeplinger thoughts ?

I will take non-controversial changes from this PR into different PR in the meantime and focus this PR only on this topic.

[pavelsavara]

This is almost same changes but whole native libs + browserhost happens in clr.runtime subset and CMake root.

#120666

[jkoritzinsky]

A) ideally we would have only one CMake root for all native builds, on all targets.

• we have 6 or more CMake roots: coreclr, libs, host, mono, mono cross, runtime tests ... what else ?
• we have to manually sync build flags among them, that sucks
• there are multiple flavors of batch files starting those native builds, some of them are really ugly
• but lot of other things would probably break when we try to refactor this
• I feel that's not on critical path for WASM right now. Other volunteers ?

This is something I see as possible in the future, but due to the fact that the Mono CMake tree is designed fundamentally differently from the rest of the CMake trees makes unification difficult.

B) singlefilehost style, static linking of host and libs within coreclr root:

• this is poor version of A)
• does it matter that singlefilehost doesn't respect any of the libs.native and host.native CMake root arguments ?
• for example, this setup doesn't respect -lc Release which is necessary for src/tests. Interpreter doesn't run in Release yet.

This is not a problem, as the Debug/Release versions of the native libs shouldn't differ in contract (so combining debug libs.native in the host with release managed libs should be fine, or we aren't sufficiently testing singlefilehost in CI).

• are we going to install lib and host .a files from that root, so that we could link them later out-of tree ?

Don't we need to do this anyway for linking the out-of-tree browserhost (built in our CMake in browserhost/host)?

• if so, are we need to match with liveBuild/runtime pack expectations for libs
• if not, we are shipping .a files which are not used/tested by default build.
• are we going to eliminate libs.native and host.native on WASM because they would go un-used ?

My preference would be to build the browserhost in the CoreCLR CMake, and browserhost/host in the host.native CMake (similar split to singlefilehost vs apphost), but we could also put it all into the CoreCLR CMake and turn off host.native.

For libs.native, how does Mono WASM get the native libs binaries?

• slow inner loop for corerun

C) what I'm doing in this PR. 3 cmake roots and loose dependency via msbuild

• this is what Mono does: link .a files later

Does Mono always link the .a files later (and never build a pre-linked-together browserhost equivalent)?

• if you are testing with browserhost in your inner loop you need to make sure that you re-build dependencies yourself.
• that is also benefit at the same time, you don' have rebuild libs if you only make changes to host. Or typescript only.

If the innerloop for making a runtime change would be clr.runtime+host.native, that would be slower than just clr.runtime. For the other changes, Ninja (or Make)'s up to date checks should prevent over-rebuilding and keep the innerloop fast.

• compiler flags may drift apart with time.

  • I plan to introduce further unification to single place, probably eng/native.props like on this PR.

Generally, we've kept flags consistent by centralizing on eng/native/configurecompiler.cmake and the other .cmake files in that folder (again, Mono is the odd one out here).

• inner loop builds of corerun are faster

corerun builds should already be extra fast if you build clr.hosts (builds corerun and all dependencies, only copies updated corerun to output dir).

• it produces all the .a files that would be necessary for the workload build on customer machine
• CLR_ARTIFACTS_BIN_DIR & CMAKE_BUILD_LIBRARIES_CONFIGURATION are smell. Is there better style ?

[pavelsavara]

My preference would be to build the browserhost in the CoreCLR CMake, and browserhost/host in the host.native CMake (similar split to singlefilehost vs apphost), but we could also put it all into the CoreCLR CMake and turn off host.native.

I don't follow. If you want to build whole browserhost in CoreCLR CMake, without going for .a files, you need to compile and link all parts there, Including browserhost/host.

Creating browserhost/host .a file inside the host.native CMake is possible, but it makes it the only exception for no gains in clarity or speed.

Does Mono always link the .a files later (and never build a pre-linked-together browserhost equivalent)?

Yes, mono links all native libs in .a files that were built separately.

Generally, we've kept flags consistent by centralizing on eng/native/configurecompiler.cmake and the other .cmake files in that folder (again, Mono is the odd one out here).

Ok, I will explore that in some of the future PRs. The challenge is that we also have to share same compiler/linker flags on customer machine when there is no CMake at all.