Skip to content

WIP: Loosen the internal assumptions around product types, letting libSwiftPM clients provide additional ones #3765

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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

abertelrud
Copy link
Contributor

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.]

@abertelrud abertelrud self-assigned this Sep 27, 2021
@abertelrud abertelrud marked this pull request as draft September 27, 2021 00:46
@abertelrud abertelrud added DO NOT MERGE WIP Work in progress labels Sep 27, 2021
@abertelrud abertelrud force-pushed the eng/client-extensible-product-types branch from 055c678 to 57ab329 Compare September 27, 2021 00:49
@abertelrud abertelrud changed the title WIP: Loosen the assumptions around product types, letting clients provide additional ones WIP: Loosen the internal assumptions around product types, letting libSwiftPM clients provide additional ones Sep 27, 2021
@abertelrud abertelrud force-pushed the eng/client-extensible-product-types branch 3 times, most recently from d760f10 to b5e2108 Compare October 4, 2021 00:14
@abertelrud abertelrud force-pushed the eng/client-extensible-product-types branch from b5e2108 to 765100a Compare October 25, 2021 01:00
…ts provide additional ones

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 plugin-provided product types (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 the details of them.  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.
@abertelrud abertelrud force-pushed the eng/client-extensible-product-types branch from 765100a to 4379c88 Compare February 2, 2022 06:18
@abertelrud abertelrud added next waiting for next merge window and removed DO NOT MERGE labels Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
next waiting for next merge window WIP Work in progress
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant