build: bring CMake build up to date #6007
Conversation
compnerd
requested review from
abertelrud,
neonichu,
tomerd and
elsh
as code owners
|
@swift-ci please test |
Add CMake based build support for the missing components as the Windows build depends on this still. This allows us to work towards enabling the swift package collection and registry functionality.
|
@swift-ci please test Windows platform |
Convert the `PackageCollectionsModel` and `PackageCollectionsSigning` modules static. `PackageCollectionsModel` is used only by `PackageCollectionsSigning` and `PackageCollections` and `PackageCollectionsSigning` is only used by `PackageCollections`. We can collapse the two modules down, statically linking it into `PackageCollections` at no cost. This reduces the packaging complexity as we have fewer libraries to redistribute with the toolchain.
These are used by two consumers: - unified swift-package-manager multi-call binary - single purpose tools Since the single purpose tools and the multi-call binary are serving the same purpose and will never be shipped at the same time, these libraries can be fully internalised without increasing the size of the package. In effect we reduce the distribution set without increasing size.
|
@swift-ci please test Windows platform |
|
Thanks @compnerd I believe @neonichu was working to reduce the amount of modules that are built with CMake as part of the effort to do a minimal CMake bootstrap build, then build the rest with SwiftPM so that not all dependencies need to be included in the CMake build. This PR seems to bring back some of those dependencies. I know we ran into some issues making the minimal bootstrap work on Windows, but its seems like maybe better investment of our effort is to make that work, so we can scale out dependencies better. Should we rekindle that discussion / effort? |
|
Sure, I think that we should do that, but in the meantime, we should get the package registry and package collections bits enabled for Windows so that we can keep parity for 5.8 (alternatively, we could remove that support from the other targets if you prefer). |
|
the challange is that the package registry module is about to get a couple more new dependencies that would also need to get CMake support so we are trying to avoid spending the time on all that, if we can spend the time on the "proper" fix. would be good to evaluate how much effort / how far we are from the "proper" fix so we can decide which is more pragmatic to do |
|
@compnerd I believe we has agreed to bring it into 5.8 but not main is that we address this more deeply by doing the minimal-bootstrap on windows. I would much rather see the energy go there. if we cannot do this int time, we can pull this into 5.9 too but I rather not pull it into main. |
|
@neonichu and I spoke about this, it turns out that we are significantly far away from what we need to do in SPM to enable the building of the artifacts on Windows (likely will miss 5.9). But that means that in the mean time, main misses functionality, which means we cannot test/use that |
|
@compnerd since we did not resolve the issue on main yet, should we create a version of this for 5.9? |
|
@tomerd - yes, I believe so. I'll try to get to this in the next day or two. Thank you for the reminder! |
|
@tomerd I think that we might've missed this for 5.9? And now we need to do it again for 5.10. Can we please just merge this into main because it keeps getting dropped and there is functionality that is being dropped on Windows. Alternatively, can we drop the functionality on macOS and Linux? |
|
@compnerd would you have a moment to resolve conflicts? |
Add CMake based build support for the missing components as the Windows build depends on this still. This allows us to work towards enabling the swift package collection and registry functionality.