Open ghale opened 5 years ago
An alternative approach to handling the model map: https://github.com/gradle/gradle-native/issues/305#issuecomment-458671161
Alternatively, we could also calculate the mapping from artifact -> module name separately and inject this into the transform as a parameter (on the consumer side).
Or it might just be simpler to add support for the transform getting hold of the artifact metadata, given we're already making deep changes in that stuff. One question here is whether the library's published coordinates (the id) are the best choice as the convention for the module name. Possibly the library base name is a better option.
Could we get the artifact's attributes and then we could pack in whatever is needed?
We can inject ResolvedArtifactResult
, which provides a bunch of information about the artifact, including the attributes.
This is a follow up to #305.
We currently have a custom file collection in
DefaultSwiftBinary
that maps incoming C++ headers to module map files by extracting the module id of the artifact and then mapping that to the header directory. We should replace this with an artifact transform, but first we'll need some way to inject theComponentArtifactIdentifier
to the transform so that we can extract the module id.Once we do this, we should be able to retire
NativeDependencyCache
.