Skip to content

Conversation

compnerd
Copy link
Member

Change PackageDescription to static which will enable SPM to avoid having to deal with Path alteration to execute the manifest on Windows. This also means that we no longer have to worry about the DT_RUNPATH/LC_RPATH on Linux and Darwin respectively.

Partially correct CompilerPluginSupport to build statically and no longer install. This is meant to be statically incorporated into PackageDescription which currently is not performed. This still raises the issue of public API surface as the static module is not visible externally (i.e. is not re-exported).

compnerd added a commit to compnerd/swift-installer-scripts that referenced this pull request Aug 16, 2023
Adjust the packaging rules to remove the shared library to support
migrating to static library forms for this.  This should avoid the need
to adjust the path when executing the compiled manifest.
@neonichu
Copy link
Contributor

neonichu commented Oct 4, 2023

@compnerd is this still relevant?

@compnerd
Copy link
Member Author

compnerd commented Oct 5, 2023

Yeah, I think that we still want to do this - it avoids the need to alter the path and simplifies trying to debug certain things.

@compnerd
Copy link
Member Author

@swift-ci please test

Change `PackageDescription`, `CompilerPluginSupport`, and
`PackagePlugin` to static which will enable SPM to avoid having to deal
with `Path` alteration to execute the manifest on Windows.  This also
means that we no longer have to worry about the `DT_RUNPATH`/`LC_RPATH`
on Linux and Darwin respectively.
@compnerd
Copy link
Member Author

@swift-ci please test

@jakepetroules
Copy link
Contributor

@compnerd I think you need to rebase this before it's ready for review?

@dschaefer2
Copy link
Member

Ankit made these dynamic to help with debugging.

Allow developing SwiftPM without the bootstrap script

This will allow building and using the swiftpm binary that was built
using swiftpm.

Not sure what scenarios he was referring to. But we should make sure we can still debug SwiftPM and it'll use these libraries from the dev environment as we change them.

@compnerd
Copy link
Member Author

But we should make sure we can still debug SwiftPM and it'll use these libraries from the dev environment as we change them.

@dschaefer2 I suspect that this was due to the interpreted form of the manifest which has long since changed to the executable form and that avoids any multiply defined symbols.

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.

4 participants