You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, there is no (good/simple) way to have a SwiftPM Package depend on a binary library that is not a system library.
See here for an MWE.
A partial workaround was proposed in Slack.
Use case: use a custom-built cryptography library; ship it as part of the developed application or library.
I'm admittedly mostly naive in the issues of native compilation, but the way I understand it, the current workflow (system libraries aside) is
build the dependency package and
put the resulting .dylib in .build/debug to link against.
This should be easy to replace by
copy the dependency library into .build/debug to link against.
From what I can tell, replacing the current command <name.dylib> (which recursively compiles the library to create .build/debug/libname.dylib) with the following should already be enough:
On the frontend, SwiftPM would have a Dependency protocol which the current Package and a new Binary(library: String, header: String, ...?) would implement; Package.dependencies would then be of type Array<Dependency> (instead of Array<Package>).
Additional Detail from JIRA
md5: 8aed5d0a92f99204c3931feab8c5a00d
Issue Description:
Currently, there is no (good/simple) way to have a SwiftPM Package depend on a binary library that is not a system library.
See here for an MWE.
A partial workaround was proposed in Slack.
Use case: use a custom-built cryptography library; ship it as part of the developed application or library.
I'm admittedly mostly naive in the issues of native compilation, but the way I understand it, the current workflow (system libraries aside) is
This should be easy to replace by
From what I can tell, replacing the current command
<name.dylib>
(which recursively compiles the library to create.build/debug/libname.dylib
) with the following should already be enough:On the frontend, SwiftPM would have a
Dependency
protocol which the currentPackage
and a newBinary(library: String, header: String, ...?)
would implement;Package.dependencies
would then be of typeArray<Dependency>
(instead ofArray<Package>
).Relates to SR-648 and SR-2048.
The text was updated successfully, but these errors were encountered: