You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[mono] new Sdk that selects mono runtime components (#54432)
* Work in progress: new Sdk that selects mono runtime components
* Add props and targets description to the components doc
* condition the _MonoRuntimeAvailableComponents by RuntimeIdentifier
* [cmake] Write a component-manifest.props file during build
If we're not building a mono aot cross compiler, generate a
component-manifest.props file in artifacts/obj/mono/<host>/ that indicates if
the host will use static or dynamic components, and a list of the available
components, and the properties for constructing their names.
* Build Microsoft.NETCore.App.Runtime.Mono.<RID>.Sdk shared framework nuget
It seems to also generate a symbols nuget. And in the nuget there's a
tools/mono-sdk-what-is-this.deps.json file from the
SharedFrameworkHostFileNameOverride property. It would be nice to exclude that
stuff.
* put the compoonent-manifest.targets into the Sdk
* delete WIP in mono/nuget/
* fixup static component names in component-manifest.targets
* delete fixed fixme
* add missing $
* fix whitespace
* [cmake] switch to configure_file instead of file(CONFIGURE)
* add missing trailing slashes in .props.in file
* Add new Sdk packs to the workload manifest
* rework component-manifest.targets to use ItemGroups; move to new SDK
* Rename shared framework to Microsoft.NETCore.App.Runtime.Mono.<RID>.Props.Sdk
And only include component-manifest.props, not the targets
* Update manifest to include the new Props.Sdk and MonoTargets.Sdk
* Move RuntimeConfigParserTask into Microsoft.NET.Runtime.MonoTargets.Sdk
Consolidate all platform-independent tasks and targets into a single Sdk
* Add iossimulator-x86 props
* update components design doc
* Fix typo
* improve docs
* Add _MonoRuntimeComponentDontLink target output
* Drop component-manifest.props into runtime pack build/ directory
Remove from the Microsoft.NETCore.App.Mono.Props.Sdk workload nuget
* remove Microsoft.NETCore.App.Mono.Props.Sdk
* Import component-manifest.props from the runtime pack
Move the MonoTargets.Sdk import to each target platform that we support
* Fix typos
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Apply suggestions from code review
Co-authored-by: Ankit Jain <radical@gmail.com>
* Add JsonToItemsTaskFactory
* fix whitespace
* Do some validation earlier in _MonoComputeAvailableComponentDefinitions
* Read component-manifest.json using the JsonToItemsTaskFactory
and bundle it in Microsoft.NET.Runtime.MonoTargets.Sdk
* remove ResolvedRuntimePack import from WorkloadManifest.targets
it's too early, and we have the JsonToItemsTaskFactory now to read the manifest
* Generate component-manifest.json in CMakeLists.txt
* Fix some copy-paste nits
* Use RuntimeFlavor==mono for runtime pack build directory
instead of TargetsMobile. We want the build files (mono-components.json)
in every mono runtime pack, not just on mobile targets
* Apply suggestions from code review
Co-authored-by: Ankit Jain <radical@gmail.com>
* rename component-manifest to RuntimeComponentManifest
* fixup nullability annotations
* fix whitespace
* fix formatting
* Misc fixes to JsonToItemsTaskFactory
* Rename MonoRuntimeComponentManifestReadTask
from MonoRuntimeComponentsReadManifestTask
* undo nullability annotation
Build doesn't like it for some reason (probably net472)
* fix incorrect task parameter name
* Remove Identity metadata from dictionary at json parsing time
Also improve nullability a bit by making the properties immutable
* Throw correct json deserializer exceptions
* Catch JsonException in an async function
We get nice error messages now like
```
src/mono/nuget/Microsoft.NET.Runtime.MonoTargets.Sdk/Sdk/RuntimeComponentManifest.targets(8,5): error : Failed to deserialize json from file 'artifacts/bin/mono/iOSSimulator.x64.Release/build/RuntimeComponentManifest.json', JSON Path: $.items._MonoRuntimeAvailableComponents[2], Line: 14, Position: 1 [component-manifest.sample.proj]
src/mono/nuget/Microsoft.NET.Runtime.MonoTargets.Sdk/Sdk/RuntimeComponentManifest.targets(8,5): error : JsonException: The JSON value could not be converted to System.Collections.Generic.Dictionary`2[System.String,System.String]. Path: $.identity | LineNumber: 0 | BytePositionInLine: 16. Path: $.items._MonoRuntimeAvailableComponents[2] | LineNumber: 14 | BytePositionInLine: 1. [component-manifest.sample.proj]
src/mono/nuget/Microsoft.NET.Runtime.MonoTargets.Sdk/Sdk/RuntimeComponentManifest.targets(8,5): error : InvalidOperationException: Cannot get the value of a token type 'Number' as a string. [component-manifest.sample.proj]
src/mono/nuget/Microsoft.NET.Runtime.MonoTargets.Sdk/Sdk/RuntimeComponentManifest.targets(8,5):
error :
[component-manifest.sample.proj]
```
* fixup comments
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Ankit Jain <radical@gmail.com>
@@ -265,16 +265,66 @@ To implement `feature_X` as a component. Carry out the following steps:
265
265
## Detailed design - Packaging and runtime packs
266
266
267
267
The components are building blocks to put together a functional runtime. The
268
-
runtime pack includes the base runtime and the components and additional
269
-
properties and targets that enable the workload to construct a runtime for
270
-
various scenarios.
271
-
272
-
In each runtime pack we include:
273
-
274
-
- The compiled compnents for the apropriate host architectures in a well-known subdirectory
275
-
- An MSBuild props file that defines an item group that list each component name and has metadata that indicates:
276
-
- the path to the component in the runtime pack
277
-
- the path to the stub component in the runtime pack (if components are static)
278
-
- An MSBuild targets file that defines targets to copy a specified set of components to the app publish folder (if components are dynamic); or to link the runtime together with stubs and a set of enabled components (if components are static)
279
-
280
-
** TODO ** Write this up in more detail
268
+
runtime pack includes the base runtime and the components. The mono workload
269
+
includes the runtime pack and additional tasks, properties and targets that
270
+
enable the workload to construct a runtime for various scenarios.
271
+
272
+
For the target RID, we expose:
273
+
274
+
-`@(_MonoRuntimeComponentLinking)` set to either `'static'` or `'dynamic'` depending on whether the
275
+
current runtime pack for the current target includes runtime components as static archives or as
276
+
shared libraries, respectively.
277
+
-`@(_MonoRuntimeComponentSharedLibExt)` and `@(_MonoRuntimeComponentStaticLibExt)` set to the file
278
+
extension of the runtime components for the current target (ie, `'.a', '.so', '.dylib'` etc).
279
+
-`@(_MonoRuntimeAvailableComponents)` a list of component names without the `lib` prefix (if any)
280
+
or file extensions. For example: `'hot_reload; diagnostics_tracing'`.
281
+
282
+
Each of the above item lists has `RuntimeIdentifier` metadata. For technical reasons the mono
283
+
workload will provide a single `@(_MonoRuntimeAvailableComponent)` item list for all platforms. We
284
+
use the `RuntimeIdentifier` metadata to filter out the details applicable for the current platform.
285
+
286
+
- The target `_MonoSelectRuntimeComponents` that has the following inputs and outputs:
287
+
- input `@(_MonoComponent)` (to be set by the workload) : a list of components that a workload wants to use for the current
288
+
app. It is an error if this specifies any unknown component name.
289
+
- output `@(_MonoRuntimeSelectedComponents)` and `@(_MonoRuntimeSelectedStubComponents)` The names
290
+
of the components that were (resp, were not) selected. For example `'hot_reload;
291
+
diagnostics_tracing'`. Each item has two metadata properties `ComponentLib` and
292
+
`ComponentStubLib` (which may be empty) that specify the name of the static or dynamic library
293
+
of the component. This is not the main output of the target, it's primarily for debugging.
294
+
- output `@(_MonoRuntimeComponentLink)` a list of library names (relative to the `native/`
295
+
subdirectory of the runtime pack) that (for dynamic components) must be placed next to the
296
+
runtime in the application bundle, or (for static components) that must be linked with the
297
+
runtime to enable the components' functionality. Each item in the list has metadata
298
+
`ComponentName` (e.g. `'hot_reload'`), `IsStub` (`true` or `false`), `Linking` (`'static'` or
299
+
`'dynamic'`). This output should be used by the workloads when linking the app and runtime if
300
+
the workload uses an allow list of native libraries to link or bundle.
301
+
- output `@(_MonoRuntimeComponentDontLink)` a list of library names (relative to the `native/`
302
+
subdirectory of the runtime pack) that should be excluded from the application bundle (for
303
+
dynamic linking) or that should not be passed to the native linker (for static linking). This
304
+
output should be used by workloads that just link or bundle every native library from `native/`
305
+
in order to filter the contents of the subdirectory to exclude the disabled components (and to
306
+
exclude the static library stubs for the enabled components when static linking).
307
+
308
+
Generally workloads should only use one of `@(_MonoRuntimeComponentLink)` or
309
+
`@(_MonoRuntimeComponentDontLink)`, depending on whether they use an allow or block list for the
310
+
contents of the `native/` subdirectory.
311
+
312
+
Example fragment (assuming the mono workload has been imported):
Condition="'$(MonoGenerateOffsetsOSGroups)' == '' and ('$(TargetsMacCatalyst)' == 'true' or '$(TargetsiOS)' == 'true' or '$(TargetstvOS)' == 'true' or '$(TargetsAndroid)' == 'true' or '$(TargetsBrowser)' == 'true')"/>
0 commit comments