WIP: Loosen the internal assumptions around product types, letting libSwiftPM clients provide additional ones #3765
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This starts to unwind some of the hardcoding around product types, and lets libSwiftPM clients provide additional product types through add-on libraries loaded on top of
PackageDescription
.Note that this isn’t, yet, custom product types provided by package plugins (that will be a much larger effort). But it is a small step towards it.
The existing product types of executable, library, etc are still kept throughout libSwiftPM, but the way in which they are encoded in PackageDescription and read by libSwiftPM is now more generic. Additionally, other types with custom properties are supported. The custom properties are kept in encoded form so that libSwiftPM doesn’t need to understand their details. They can be defined and encoded by additional libraries loaded by the manifest on top of PackageDescription, and clients of libSwiftPM can unpack them using the same structure definitions as in that library. libSwiftPM of course unpacks the properties of its built-in types (currently only whether a library is static, dynamic, or automatic).
This also updates the manifest source generation to allow clients to generate source code fragments for custom product types. A future addition would be to automatically generate these source code fragments using Mirrors.
[One line description of your change]
Motivation:
[Explain here the context, and why you're making that change. What is the problem you're trying to solve.]
Modifications:
[Describe the modifications you've done.]
Result:
[After your change, what will change.]