-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[wasm] WasmApp.targets: Separate obj
, and bin
parts of the build process
#47253
Conversation
Tagging subscribers to this area: @directhex Issue Details
|
.. to the targets. - New property: `NativeAssets`, populated by `@(WasmNativeAsset)` - Remove property `MicrosoftNetCoreAppRuntimePackRidDir` - Also, add the `icudt.dat` file from the targets
WasmAppBuilder has (non-obvious) logic to: 1. if AOT'ing, then use the *generated* dotnet.{js,wasm}; 2. else use the one from the runtime pack This depends on Publish having copied those files from the runtime pack to the publish directory, and then comparing paths in the builder to decide which one to use. Instead, make this the intention obvious, and clear.
We were getting these from the publish directory, instead we can get them directly from the runtime pack. This includes icudt.dt, and dotnet.timezones.blat .
.. where we can emit the generated native files. Since these files are meant only for generating the final `dotnet.wasm`, we don't want them to put them in the bin directory.
.. instead of trying to find them in the build dir. This build directory will become a directory for intermediate build output in upcoming commits.
- Instead of having a special $(WasmMainAssemblyPath), and then adding it to the wasm assemblies ourselves - let the user project add all the relevant assemblies to `@(WasmAssembliesToBundle)`, which is usually as simple as `$(OutDir)\*.dll`. - This helps to simplify lot of things. - And we just need the main assembly filename for generating the run-v8.sh script.
Based on the changes in previous commits, we can now remove `$(WasmBuildDir)`, and replace that with an internal `$(_WasmIntermediateOutputPath)`. This path will have all the build artifacts generated that aren't required in the app bundle. Earlier, we were using the publish directory for that, which resulted in it being littered with unncessary files, and files getting copied to the app bundle from unclear sources, and for non-obvious reasons.
… correctly reflect the value
obj
, and bin
parts of the build process
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsWe want to use a separate directory for intermediate build outputs, that aren't needed TL;DR version:Changes:
Details:Though it is a bit tricky, because the current targets assume:
What does this PR change?
Effectively:
|
@lambdageek Would you be able to check that this doesn't break your mbr samples? |
Whats the problem with keeping these in the publish/ dir ? It's not used for actually publishing the app. |
It is cleaner to separate bin/obj. This helps make the internal dependencies clearer. With this PR, the publish dir is used just for the assemblies, so effectively, we can use any directory for that, for eg, after a regular build instead of a full publish. |
src/mono/wasm/debugger/tests/debugger-test/debugger-test.csproj
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, as long as the mbr sample still works.
Windows test failures seem to be - #47374 . |
We want to use a separate directory for intermediate build outputs, that aren't needed
in the app bundle, and reduce unclear internal dependencies during a build.
TL;DR
Changes:
$(WasmBuildDir)
removeda.
$(WasmMainJS)
,b. and
@(WasmAssembliesToBundle)
Details:
Though it is a bit tricky, because the current targets assume:
that they are being run after
Publish
that the publish directory has:
libmono*
),that the targets emit all the intermediate output files like
driver.o
, or the bitcode files, into the samedirectory
And there are assumptions about where to pick which files from (eg. whether to take
dotnet.wasm
from the runtime pack, or from the publish dir), based on unclear rules.
What does this PR change?
libmono*
,icudt.dat
) are always takenonly from the runtime pack
$(WasmBuildDir)
is removed completely. Instead, we use an intermediate path based on$(IntermediateOutputPath)
$(WasmAppDir)
Effectively:
To generate a wasm app for a project, the minimum you need to set:
a.
$(WasmMainJS)
,b. and
@(WasmAssembliesToBundle)
The targets don't depend on publish dir at all
(in a future PR, we could remove triggering based on
Publish
target also)