Are system library targets actually supported?

So according to the API documentation, system library targets are supported in Swift Package Manager:

I was also able to find this in evolution:

And I was able to find a link to this version of the SPM Usage doc which details how to use the feature:

However, the current version of the doc doesn't contain any usage of system library targets, and only discusses system library packages.

Is this feature currently supported? If not, is there a reason it's not in the documentation?

I cannot speak to the documentation. I used SE-0208 to write mine. I can confirm that in Swift 5.2 (and I'd presume earlier based on SE-0208) that system library targets are actually supported.

Here is an example of the Package.swift and module.modulemap I used to convert libgpiod into a system library.

// swift-tools-version:5.2
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "foo",
    products: [
        .library(name: "SwiftGPIO", type: .dynamic, targets: ["SwiftGPIO"]),
    ],
    dependencies: [
        // Dependencies declare other packages that this package depends on.
        // .package(url: /* package url */, from: "1.0.0"),
    ],
    targets: [
        // Targets are the basic building blocks of a package. A target can define a module or a test suite.
        // Targets can depend on other targets in this package, and on products in packages which this package depends on.
        .target(name: "SwiftGPIO",
            dependencies: ["Clibgpiod"]),
        .systemLibrary(
            name: "Clibgpiod",
            pkgConfig: "libgpiod",
            providers: [.apt(["libgpiod-dev"])]),
    ]
)
module Clibgpiod [system] {
  header "/usr/include/gpiod.h"
  link "gpiod"
  export *
}
2 Likes

Note that this module map will only work on systems where the header is present at the exact location specified, and will thus render header search paths ineffective. If someone wanted to use a package containing this module map, but had gpiod.h in, for example, /usr/local/include, they'd have to fork and change the module map.

A more portable approach is to include a shim header that contains just #include <gpiod.h> and reference that in the module map.

Thank you for confirming!

That is definitely true this is not a portable solution. At least at this time my goal was not to actually share it with anyone. The Package.swift I posted here has most of the actual executable and libraries redacted. I was just trying to share the parts that I know work with the libgpiod-dev provided with Ubuntu.

It is now clear to me that I did not actually say that I tested it on Ubuntu. I am sorry for any confusion that may have caused.