Skip to content
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

[swiftpm] For development, build a local copy of PackageDescription #405

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

Conversation

benlangmuir
Copy link
Member

When developing sourcekit-lsp, it is useful to be able to use a released
version of the swift toolchain. However, because we are using the latest
branch version of libSwiftPM, it may be that the PackageDescription
module packaged with the toolchain is incompatible with that libSwiftPM.
To prevent that problem, we now build our own copy of PackageDescription
and using that instead of the toolchain's. That change is made by
default to allow plain swift build and swift test invocations to
work without modification. When building as part of the swift toolchain,
we continue to use the toolchain's copy of PackageDescription, because
we know that it is built from the same sources as we are using for
libSwiftPM.

One situation that is not explicitly covered by the above is if
sourcekit-lsp is installed somewhere outside of a swift toolchain. In
that case by default it will try to find a local package description
module next to the sourcekit-lsp binary, but assuming that fails it will
fallback to searching the default toolcahin that it discovers at
runtime, as it does today. If this usecase turns out to be important we
can provide additional ways to control how to find the
PackageDescription module.

rdar://78548287

When developing sourcekit-lsp, it is useful to be able to use a released
version of the swift toolchain. However, because we are using the latest
branch version of libSwiftPM, it may be that the PackageDescription
module packaged with the toolchain is incompatible with that libSwiftPM.
To prevent that problem, we now build our own copy of PackageDescription
and using that instead of the toolchain's. That change is made by
default to allow plain `swift build` and `swift test` invocations to
work without modification. When building as part of the swift toolchain,
we continue to use the toolchain's copy of PackageDescription, because
we know that it is built from the same sources as we are using for
libSwiftPM.

One situation that is not explicitly covered by the above is if
sourcekit-lsp is installed somewhere outside of a swift toolchain. In
that case by default it will try to find a local package description
module next to the sourcekit-lsp binary, but assuming that fails it will
fallback to searching the default toolcahin that it discovers at
runtime, as it does today. If this usecase turns out to be important we
can provide additional ways to control how to find the
PackageDescription module.

rdar://78548287
@benlangmuir
Copy link
Member Author

@swift-ci please test

@benlangmuir benlangmuir requested a review from akyrtzi May 27, 2021 03:24
@benlangmuir
Copy link
Member Author

benlangmuir commented May 27, 2021

Marking this a draft until I can test both development builds and and installed toolchain on both Linux and macOS.

Edit: confirmed that it's not impacting the installed toolchain and that development builds work as expected on macOS and Linux.

I'd appreciate feedback on this approach, in particular

  • Are the module paths I'm checking for correct for all platforms (@compnerd will this work on Windows?)
  • I'm changing the default behaviour of swift build and swift test rather than making building PackageDescription opt-in. To me it's important that swift test is as simple as possible. It will still fallback to the existing path if it cannot find PackageDescription relative to the sourcekit-lsp binary.
  • Is specifying binDir an acceptable use of the libSwiftPM API? This is what swiftpm itself does during testing, but obviously what a project does for their own use is different from what they want to support. If there was a better way to customize the PackageDescription, I'd be happy to adopt that instead.

@compnerd
Copy link
Collaborator

I'll try to get a listing of the build tree.

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.

None yet

3 participants