SwiftPM: Is it possible to specify OpenSSL as a dependency?

I have an Xcode Swift project that depends on OpenSSL. (It clones the repo and calls a build script to produce binary then copies a custom module map file.)

Is there a way to add an external build target (following the standard Configure, make, make install) as a dependency in SwifPM? If we could do this, a lot of open source C projects would be easily converted and being used in Swift.
@Thanks!

No. (Not yet at least.)

But that doesn’t mean you cannot use open source C libraries. I usually:

  1. Fork the C repository.
  2. Branch from a release version.
  3. Generate any normally transient files and check them in.
  4. Add a Package.swift.
  5. Tag a semantic version (on the fork).
  6. Declare the fork package as a dependency.
  7. (Optional) Pester the upstream repository to start providing the Package.swift themselves.
1 Like

Thanks for your reply, Jeremy. I'd rather stick with Xcode for now. :grin:
Just an idea: For SwiftPM and Swift to attract more users, I guess we needs to absorb the standard way of compilation and CMake.
OpenSSL has hundreds of .c files. Depending on the configuration, many .c files are not included in the compilation. It's not trivial to tell Clang how to compile for various platforms and configurations correctly. Even if I took time to configure for macOS now, I'd have to maintain the modification with OpenSSL evolution. it'll be nice if we could just "steal" the good things that people has been doing and put into SwiftPM.
Remember at some points, Julia did some really good things. Python just steals and puts in a C library called import Julia. This is how Python tends to destroy these poor little things before they had a chance to grow and how it gets those smart people in Ruby and other languages into the Python community.
I really think Swift is great because it works so well with Objective-C and C. It gives us a much better way of doing old things. Hope we'll steal CMake into SwiftPM. :crazy_face:

I answered your question according to the present state of things, but since you are now talking about your hopes for the future of the package manager, you might also want to take a look at this thread:

1 Like
Terms of Service

Privacy Policy

Cookie Policy