I'm wrapping couple of upstream C libraries (XXX in the example below) into swift modules and all works great with the following setup:
Package.swift Sources/XXX Sources/XXXSwift/XXXSwift.swift
where XXX is a git submodule of third party C library cloned into my swift module's repo from upstream git sources. This way I can easily track new releases from upstream without touching their code.
In the meantime such packages can be then turned via
swift package generate-xcodeproj into projects that can be used as subproject in Xcode. When C library XXX contains either include/XXX.h or include/XXX/XXX.h everything is fine and working great.
But I have one C library that just publishes a couple of XXX/include/YYY.h files defining various features, without defining one big umbrella file, mainly because the library is intended to be used piece by piece by including only what is necessary. The swift package manager (I think) is not finding the umbrella header and therefore is not creating a clang module (I think) and Xcode later fails to compile swift sources that need access to the C code with the error:
error: no such module 'XXX' import XXX
I know I can workaround this by creating my own module.modulemap for XXX defining what header files should be included, but I struggle to find the right place where to put it.
I know the module.modulemap should be placed in XXX/include/ but given that XXX/include is cloned from a third party git I do not necessarily have a right to put it there without forking XXX into my own repo and adding necessary modifications.
What's the best practice to swift-ify a third party C code without upstream modifications these days?
Where does SPM look for module.modulemap for XXX?
sorry if I'm missing something obvious and thanks for your help,