We have been experimenting with a SPM build plugin to dynamically generate source files for a package. The output of the plugin is 2 files, sqlite3.c and sqlite3.h. The c file is successfully built and linked, however, the header file is not available to the application with a dependency on the package. If we add a .h file to the outputFiles in the plugin, Xcode just generates a warning about unknown file type for the .h.
Hi @stevapple - thanks for taking a look at this. There is a modulemap file present, in this case it is exposing a bridging header which then references sqlite3.h. I also agree that under normal circumstances the sqlite3.h file would exist under the include directory for the target sources. However, in this case sqlite3.h is being generated dynamically by the build plugin. Due to the sandbox, the plugin can't write anything back to the module directory structure.
The code is instead specifying the output files as such:
This works for the c file, which is built accordingly into the module, but the inclusion of a .h in the output file list results in the following warning:
no rule to process file '/Users/xxx/Library/Developer/Xcode/DerivedData/sqlcipher-osx-swift-demo-abwythneycizmxftzbhpwlrzreav/SourcePackages/sqlcipher/sqlcipher/AmalgamationPlugin/gen/sqlite3.h' of type 'file' for architecture 'x86_64'
@stevapple don't you have ideas if it's possible to include .h output file into sources? Or may be you know somebody to invite into conversation who can help?
One of the issues we need to tackle here before being able to support C-family languages is exactly what you're describing, how to expose header files.
@rakuyoMo I'm not aware of any update on this issue. From the comment that @NeoNacho made a couple years ago, it sounds like the team is aware that it is not particularly useful to support plugin-generated c files without also allowing corresponding headers. However, I don't think there has been a change to fix this underlying issue.