SwiftPM does not create a .dll file

[ksluder (Kyle Sluder)]

@compnerd

I am not suggesting that Windows should not have these features available to them

Sorry, I could have been clearer that I was agreeing with you.

[dima_kozhinov (Dmitry Kozhinov)]

@dima_kozhinov

Am I missing something?

Back to my original question:
Is there any way to build a shared dynamic library using SwiftPM?
Do I just need to add a stub executable file target somewhere in the Swift.package or this is not possible at all?

[Alejandro (Alejandro Alonso)]

When you declare a library product, you can specify a dynamic library:

products: [
  .library(name: "...", type: .dynamic, targets: ["..."])
]

and this will (on macOS) produce a .dylib in the build folder.

[dima_kozhinov (Dmitry Kozhinov)]

@Alejandro

type: .dynamic

Thank you very much!
Works on a Mac, works on Windows.

[jrose (Jordan Rose)]

Mostly I meant that people use SwiftPM to make executables. Which it can do perfectly fine, depending on the “object library” targets in other packages.

(Personally I think if SwiftPM wants to be used for building any sort of distributable binary, it should put them outside of its secret build directory, but that’s just not what it does today.)

[dima_kozhinov (Dmitry Kozhinov)]

Maybe swift package init should produce a package for an executable by default. I always wondered why this is not the case.

Or it could still produce a package for a library, but a dynamic one. That would make much more sense for using swift build on it.

Just my personal opinion.

[ksluder (Kyle Sluder)]

@jrose

Mostly I meant that people use SwiftPM to make executables.

Is this actually true? How many SwiftPM packages are dependencies of executables versus executables themselves? Surely the default being “library” wasn’t arbitrary.

[jrose (Jordan Rose)]

Yeah, that’s fair. Apple is used to there being an order of magnitude more apps than libraries, but that may not translate to a general principle, and Xcode being able to consume SwiftPM packages muddies the statistics a lot. Apps and executables are the leaves of the tree* of All Dependencies In The World, the stdlib is the root, and everything in the middle is a library.

* technically a forest, with no-stdlib libraries and now the embedded variant of the stdlib, not to mention if you count different platforms as different stdlibs, but close enough

[hassila (Joakim Hassila)]

@Max_Desiatov

It isn't as easy is that. Specifically "Linux" is not a single well-defined platform. Just for the Swift runtime and stdlib we have to account for their dependencies such as libc and libc++ flavors and versions, which put constraints on the Linux kernel version.

Yeah, when I mean 'platform', I don't mean 'Linux' here in the general sense, I mean e.g., Ubuntu 22.04.3 LTS, a very specific distribution and patch version.

@Max_Desiatov

If any of your code or its dependencies (even transitive ones) use swift-corelibs-foundation or swift-corelibs-dispatch (the latter is required for Swift Concurrency), we would have to account for all of their dependencies and their versions (libcurl, libxml2, and so on). If there's a mismatch anywhere, we either have to track and diagnose it, or leave users to obscure and hard to debug bugs and linker/loader errors.

Here maybe I'm missing something, if e.g., libcurl or limbxml2 are statically linked into e.g., swift-corelibs-foundation and are being used as an internal supporting library and not as a currency type in the actual API exposed by Foundation, why would it matter?

@Max_Desiatov

At that point it's not the same-toolchain-and-platform constraint, it's the same-state-of-your-unique-system-installation constraint. SwiftPM can't currently reliably track dependencies outside of your build graph, where a simple apt-get install can break your dynamic Swift library.

Even the "same-state-of-your-unique-system-installation" would be highly useful for our use case - deployment on a heterogenous cluster where all nodes really will be the same - the same would go for someone deploying on e.g. standardised EC2 containers or similar, where you know that the nodes will be identical - even if it would be an opt-in with caveat/warning documentation, it'd be something we'd be happy to use.

An environment variable "PLEASE_ENABLE_XCFRAMEWORK_FOR_LINUX_WE_WILL_BE_VERY_CAREFUL=1" would be good to avoid having to roll a separate toolchain ;-)

[hassila (Joakim Hassila)]

@compnerd

My current recommendation for your use case would be to use CMake which has support for building packages with static and dynamic linking as needed and offers greater control over the build. There are examples at GitHub - compnerd/swift-cmake-examples: Swift example projects and I am more than happy to have additional examples added to the repository for reference.

Thanks Saleem, much appreciated - we'll have a look if that could be an option for us.