-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Mono toolchain workload #51327
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
Mono toolchain workload #51327
Conversation
We were originally publishing the MonoAOTCompiler nuget and having Blazor, iOS, and Android include it as part of their workload. Unfortunately, the workload spec does not allow multiple pack references from different manifests. To get around this 1-1 relationship, we can supply a containing workload that can be consumed via the extends key. Resolves dotnet/sdk#16700
lewing
left a comment
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.
Added some thoughts. More to come
src/mono/nuget/Microsoft.NET.Sdk.Mono.Toolchain.Manifest/WorkloadManifest.targets
Outdated
Show resolved
Hide resolved
src/mono/nuget/Microsoft.NET.Sdk.Mono.Toolchain.Manifest/WorkloadManifest.targets
Outdated
Show resolved
Hide resolved
b273dbd to
13827a7
Compare
src/mono/nuget/Microsoft.NET.Sdk.Mono.Toolchain.Manifest/WorkloadManifest.json.in
Outdated
Show resolved
Hide resolved
13827a7 to
d1e0623
Compare
| <Import Project="$(NuGetPackageRoot)\microsoft.dotnet.build.tasks.packaging\$(MicrosoftDotNetBuildTasksPackagingVersion)\build\Microsoft.DotNet.Build.Tasks.Packaging.props" /> | ||
|
|
||
| <PropertyGroup> | ||
| <WorkloadTasksAssemblyPath>$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'WorkloadBuildTasks', 'Debug', '$(NetCoreAppToolCurrent)'))WorkloadBuildTasks.dll</WorkloadTasksAssemblyPath> |
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.
Why Debug ?
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.
@akoeplinger Do you recall why it's always debug?
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.
We always build all tasks in debug. I believe the reason for that was that one of the subsets modified the configuration property which caused the tasks to not build correctly in mixed configurations. Also hardcoding to one configuration avoids a rebuild when you switch configurations when building the repo.
src/mono/nuget/Microsoft.NET.Sdk.Mono.Toolchain.Manifest/WorkloadManifest.targets
Outdated
Show resolved
Hide resolved
.../Microsoft.NET.Sdk.Mono.Toolchain.Manifest/Microsoft.NET.Sdk.Mono.Toolchain.Manifest.pkgproj
Outdated
Show resolved
Hide resolved
|
cc @grendello from Android pov |
src/mono/nuget/Microsoft.NET.Sdk.Mono.Toolchain.Manifest/WorkloadManifest.json.in
Outdated
Show resolved
Hide resolved
src/mono/nuget/Microsoft.NET.Sdk.Mono.Toolchain.Manifest/WorkloadManifest.json.in
Outdated
Show resolved
Hide resolved
src/mono/nuget/Microsoft.NET.Sdk.Mono.Toolchain.Manifest/WorkloadManifest.json.in
Outdated
Show resolved
Hide resolved
src/mono/nuget/Microsoft.NET.Sdk.Mono.Toolchain.Manifest/WorkloadManifest.json.in
Outdated
Show resolved
Hide resolved
src/mono/nuget/Microsoft.NET.Sdk.Mono.Toolchain.Manifest/WorkloadManifest.json.in
Outdated
Show resolved
Hide resolved
src/mono/nuget/Microsoft.NET.Sdk.Mono.Toolchain.Manifest/WorkloadManifest.json.in
Outdated
Show resolved
Hide resolved
|
Regarding b40c49b, are you assuming that the installer/resolver will fall back to |
|
I would recommend marking all these workloads as abstract so they're only able to be installed via the concrete platform SDK workloads that extend them. |
587c552 to
2b7d364
Compare
2b7d364 to
921f982
Compare
After a bunch of back and forth, we'll be explicit about what happens on osx-arm64. |
lewing
left a comment
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 enough to start producing packs.
I tested the aliasing we're using now with an arm64 runtime on an m1 and produced functional AOT builds |
|
This change broke our official builds: |
| --> | ||
| <NETStandardPatchVersion>0</NETStandardPatchVersion> | ||
| <MicrosoftNETRuntimeEmscripten2012Nodewinx64Version>6.0.0-preview.4.21212.1</MicrosoftNETRuntimeEmscripten2012Nodewinx64Version> | ||
| <MicrosoftNETRuntimeEmscriptenVersion>$(MicrosoftNETRuntimeEmscripten2012Nodewinx64Version)</MicrosoftNETRuntimeEmscriptenVersion> |
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.
Can you please move these two properties down to the other property group and add a comment to indicate which repo these properties are targeting? Similar to all the other properties in this file (see below).
| <Project Sdk="Microsoft.NET.Sdk"> | ||
| <PropertyGroup> | ||
| <TargetFramework>$(NetCoreAppToolCurrent)</TargetFramework> | ||
| <OutputType>Library</OutputType> |
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.
nit: you can remove this property. It's the default.
| <Target Name="PublishBuilder" | ||
| AfterTargets="Build" | ||
| DependsOnTargets="Publish" /> |
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.
Why do you need to publish the task?
| @@ -0,0 +1,46 @@ | |||
| <Project> | |||
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.
If this is a shipping package then it needs the copyright section: https://github.com/dotnet/arcade/blob/cc512d28c9368336a2893172cbd45dc27960e304/src/Microsoft.DotNet.Build.Tasks.TargetFramework.Sdk/src/build/Microsoft.DotNet.Build.Tasks.TargetFramework.Sdk.props#L1
| <Import Project="$([MSBuild]::GetPathOfFileAbove(Directory.Build.props))" /> | ||
|
|
||
| <PropertyGroup> | ||
| <PackageDescription>Internal toolchain package not meant for direct consumption. Please do not reference directly.</PackageDescription> |
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.
Consider setting <UseRuntimePackageDisclaimer>true</UseRuntimePackageDisclaimer> which adds the standard description for internal packages that we use everywhere else:
runtime/Directory.Build.targets
Line 54 in cd271c1
| <PackageDescription Condition="'$(PackageDescription)' == '' and '$(UseRuntimePackageDisclaimer)' == 'true'">$(RuntimePackageDisclaimer)</PackageDescription> |
| <Import Project="$(NuGetPackageRoot)\microsoft.dotnet.build.tasks.packaging\$(MicrosoftDotNetBuildTasksPackagingVersion)\build\Microsoft.DotNet.Build.Tasks.Packaging.props" /> | ||
|
|
||
| <PropertyGroup> | ||
| <WorkloadTasksAssemblyPath>$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'WorkloadBuildTasks', 'Debug', '$(NetCoreAppToolCurrent)'))WorkloadBuildTasks.dll</WorkloadTasksAssemblyPath> |
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.
Use NormalizePath instead. NormalizeDirectory is intended to be used for paths to directories where-as NormalizePath is for file paths.
| <Import Project="Sdk.props" Sdk="Microsoft.NET.Runtime.Emscripten.Node" /> | ||
| <Import Project="Sdk.props" Sdk="Microsoft.NET.Runtime.Emscripten.Sdk" /> | ||
| <Import Project="Sdk.props" Sdk="Microsoft.NETcore.App.Runtime.AOT.Cross.browser-wasm" /> | ||
| </ImportGroup> |
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.
nit: indentations in this file are off. We use two spaces in all our msbuild files in the repo.
First pass at a more comprehensive mono workload that includes wasm, the aot compilers, and the runtime config task.