My SwiftPM package pull in its C dependency via a git submodule. SwiftPM fetches the submodule automatically when building from the command line, and so my file VERSION.TXT is available in the submodule directory. I parse this file to populate macros via .cSettings, e.g., .define("RELEASE_DATE", to: "\"\(parseFile())\"", nil).
This works well from the command line, but when trying to add the package to Xcode, the submodule is NOT loaded before trying to resolve the package, so the VERSION.TXT file doesn't exist and, of course, setting the macro fails.
While I can continue to use it as a local repo, that's not very nice for other users. Am I overlooking an existing solution to this? Please assume that I can't change the upstream C repository.
Too late. Although, as a workaround, I simply fail reading the file with some default version information, use that for the defines, and at some point after the submodule is pulled, .define is called again and works.
In my case, problem worked-around. I wonder if it wouldn't be better, though, to apply the C settings until after all of the submodules are pulled, and then this wouldn't happen.
Does this now actually work when submodules aren't involved? I've tried to read a version number from an in-repo file and gave up on getting it to work when installing via Xcode because the package's files weren't accessible with the sandbox rules that Xcode ran the package with (while it worked fine via the command line, as that doesn't do the sandboxing).
I was actually wondering about this myself, for OR-Tools (written in C++). I eventually decided that a package with a Git submodule was the best approach, but haven’t gotten around to trying it.
Are submodules best-practice for dependencies without SPM support?