C static library wrapped with a binary xcframework and Swift PM

Using Swift
, ,
1

I have a large C++ / CMake code base, complete with a C API. I'm looking to wrap this as a pre-built binary xcframework, and delivered via a Swift package.

I have this working, along with a relatively permissive modules.modulemap file, but only in the case where I have curated the header files carefully to have #include directives pointing to other headers files in a relative manner.

The example modules.modulemap file:

framework module COOLKit {
  umbrella header "COOLKit.h"
  module * { export * }
  export *
}

An example of the Headers folder for this framework looks like the following, called COOLKit:

├── COOLKit.h
└── cool
    ├── additions.h
    ├── cpp.h
    ├── exported
    │   ├── callbacks.h
    │   ├── structs.h
    │   ├── results.h
    │   └── image.h
    └── cool.h

Each header file, if referring to another one, does so relatively, so e.g. structs.h may do the following

#include "../cpp.h"

Ordinarily, though, the original code has all been written in such a way that a common, root include path is specified, and the above should ideally just read

#include "cool/cpp.h"

… but this fails with SwiftPM when it emits the module during build: 'cool/cpp.h' file not found

Specifying paths in terms of the root framework, does work:

#include <COOLKit/cool/cpp.h>

… however I'm keen to avoid this requirement, as changes to includes in the original C++ library would be extensive.

Is there a way forward where I can keep #include statements as is and work from the root of the Headers folder within the framework as the search path to work from?

2

One approach I've tried is instead of using an umbrella header, declare an umbrella directory instead.

Unfortunately, by design, it will harvest all headers and read them as C-headers. This breaks, of course, unless all headers guard with #ifdef __cplusplus around C++ code. This, likewise, is also something I don't want to apply to the original C++ source code.

Until Swift / C++ interoperability lands with Swift 5.9, it seems I'm a little out of luck?

3

An update:

I opted to use an approach of writing my own header modification tool that would go through the entire file tree and modify header files to work as if written in terms of the original root framework:

#include <COOLKit/path/to/header/file.h>

This works, and isn't too problematic.