cc @compnerd

@swift-ci please test

cc @compnerd

@compnerd what do you think of these changes?

If we wanted to in the future ship System as a binary with toolchains ala corelibs and Darwin/Glibc overlays, would we have the distinction between source and binary distribution on all platforms?

thanks @compnerd

I think that this should be fine - I can see this causing some issues for the installers, but we can deal with that subsequently (the manifest needing to be updated).

👍

by "installers" you mean Windows installers?

I'm still unhappy with the change - I don't think that this should be called SystemPackage on anything but macOS - the library name should be libSystem.so or System.dll on non-macOS targets (it has to be different on macOS to avoid the conflict with libSystem). That said, I don't think that we need to hold this up for dealing with the name.

As you probably know, my goal is to integrate SwiftSystem into SwiftPM and given that the toolchain build uses CMake we need to make that work. I have no strong opinion about how to achieve it other that the current CMake setup does not work in this context so needs to be fixed. Do you a different approach you want to propose as an alternative to this PR and the downstream ones in TSC, SwiftP, LSP, etc?

The change to SwiftSystemConfig.cmake.in though is important - it isn't doing what it is supposed to do.

done, please confirm this is fine now

@swift-ci please test

thanks @compnerd

I think that this should be fine - I can see this causing some issues for the installers, but we can deal with that subsequently (the manifest needing to be updated).

👍

by "installers" you mean Windows installers?

Yes. There will be changes needed in swift-installer-scripts to update the manifest. But that should happen at the same time as updating the tag.

I'm still unhappy with the change - I don't think that this should be called SystemPackage on anything but macOS - the library name should be libSystem.so or System.dll on non-macOS targets (it has to be different on macOS to avoid the conflict with libSystem). That said, I don't think that we need to hold this up for dealing with the name.

As you probably know, my goal is to integrate SwiftSystem into SwiftPM and given that the toolchain build uses CMake we need to make that work. I have no strong opinion about how to achieve it other that the current CMake setup does not work in this context so needs to be fixed. Do you a different approach you want to propose as an alternative to this PR and the downstream ones in TSC, SwiftP, LSP, etc?

Yes, I understand that. I think that changing the name doesn't need to hold this up for now - this is matching the behaviour in Package.swift. I'm suggesting that the target name be changed much like it is in Foundation:

#if os(iOS) || os(macOS) || os(tvOS) || os(watchOS)
import SwiftSystem
#else
import System
#endif

The change to SwiftSystemConfig.cmake.in though is important - it isn't doing what it is supposed to do.

done, please confirm this is fine now