System Library with Other Multiple Dependent Libraries

Using Swift
1

I'm in the process of converting our entire project over to SPM and I'm having issues with some of the test kit code we have built up around Spatialite. Spatialite is a sqlite3 extension that uses geos and other things to perform database queries and other functions geographically. My manifest looks like this:

/// System Library
.systemLibrary(
    name: "Spatialite",
    pkgConfig: "spatialite",
    providers: [
        .brew(["libspatialite"])
    ]
),

/// Test Kit
.target(
    name: "DatabaseTestKit",
    dependencies: [
        .target(name: "DatabaseStuff"), // the actual database layer we have written for production
        .target(name: "Spatialite")
    ],
    cSettings: [
        .headerSearchPath("include")
    ]
)

This test kit is used by other packages to perform their tests so I have DatabaseTestKit exposed in it's own product of the same name by this package. The problem is when I attempt to build it, it fails because Spatialite can't find sqlite3, one of its dependent C libraries.

As you can see here the library actually depends on 5 other libraries (all of which get downloaded to usr/local/Cellar/ when installing libspatialite). Do I have to do something special to get the Swift packages to include those libraries also? Whether that's flags on the system library target or whatever but right now it just can't seem to find what it needs.

The module map is simple:

module Spatialite [system] {
    header "shim.h"
    link "libspatialite"
    export *
}

And all shim.h has in it per this article is:

#include <spatialite.h>

Any help or insight is greatly appreciated.

2

Possibly something like this?

3

Possibly, the problem there is the systemLibrary target doesn't have a linkerSettings parameter.

4

The system library isn’t being compiled or linked. It is the client module being compiled that needs the linker flag.

It also might be worth checking that you actually have the SQLite headers. I’m less familiar with brew, but with apt-get, often there is a main package with only the runtime library, but a separate -dev variant that contains the necessary headers you need while you’re compiling. For instance, to use SwiftPM on Linux, you only need the sqlite3 package, but to compile it as a dependency, you also need the libsqlite3-dev package.

5

It looks like the SQLite headers aren't included in what comes down from homebrew, it's just pulled down as a separate homebrew package. As far as I can tell there is no -dev version of spatialite. But basically what you're saying is the consumer of the Spatialite target should be linking against the needed pieces?

I honestly don't think I'm even to the point where it is linking. It's pulling in the stuff from the .systemLibrary and then that is failing to build because the referenced spatialite.h uses sqlite3 but doesn't import it. Maybe that header is not meant to be imported like that?

I wish I understood more about the C building process maybe it would help to understand exactly where and why it's failing. I also wish the package manager build was reporting issues to the issue navigator in Xcode (or rather Xcode picking up on issues reported by SPM) but it's not a huge deal to just dig in the build log.