Skip to content

build: centralise the install logic for the Swift modules #2839

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

Merged
merged 1 commit into from
Aug 14, 2020

Conversation

compnerd
Copy link
Member

@compnerd compnerd commented Jul 5, 2020

Add support for installation for macOS targets to the CMake
installation. Centralise the logic for the installation of the files.
This properly handles the installation of the swiftdoc, swiftinterface,
swiftmodule and the runtime libraries across all the platforms in either
static or shared configurations.

Add support for installation for macOS targets to the CMake
installation.  Centralise the logic for the installation of the files.
This properly handles the installation of the swiftdoc, swiftinterface,
swiftmodule and the runtime libraries across all the platforms in either
static or shared configurations.
@compnerd
Copy link
Member Author

compnerd commented Jul 5, 2020

CC: @drodriguez @spevans

@compnerd
Copy link
Member Author

compnerd commented Jul 5, 2020

@swift-ci please test

@spevans
Copy link
Contributor

spevans commented Jul 15, 2020

Should sclf be installed on macOS?, I could see it breaking things especially if it was installed as Foundation. Its only really used on macOS for development and testing.

@compnerd
Copy link
Member Author

The logic to install the modules is completely generic. The SwiftSupport.cmake can be copied across repositories without alteration.

I believe that we setup the output names to use SwiftFoundation, so it shouldn't get installed as Foundation.

@lxbndr
Copy link
Contributor

lxbndr commented Jul 15, 2020

Could this logic potentially become a part of Swift support in CMake itself? I am not familiar with CMake policies related to such things, but it seems natural to handle target installation as part of language support. Would be really cool if we have it out of the box.

@compnerd
Copy link
Member Author

@lxbndr - I have avoided putting this into CMake itself intentionally. I have some work which will unify the Darwin and non-Darwin paths, which again will update this. At that point, we will have a unified installation style. At that point, it will be better to actually add support for Swift to the install command rather than rely on special handling and then we can completely remove SwiftSupport.cmake once we have a new enough CMake.

@spevans
Copy link
Contributor

spevans commented Jul 15, 2020

I have no objections to this patch - I just wanted to note that installing on macOS could cause issues. But since its CMake changes Im happy to leave them in @compnerd 's capable hands :)

@compnerd compnerd merged commit ca6cda5 into swiftlang:master Aug 14, 2020
@compnerd compnerd deleted the install-once branch August 14, 2020 17:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants