I have an Xcode project with a main app target, and a dext target which builds a DriverKit driver which is embedded in the main app. That all works, if I build the DriverKit target first, then switch to the app target and build that. The app and the driver work.
If I make the Driver target a dependency of the App target, building the Driver fails because a header is not found, thus building the app fails.
This doesn't make much sense - why does building a target as a consequence of dependence on another target produce a different result from building the same target manually?
Has anyone else seen behavior like this? Have any hints on how to fix it?
I've tried comparing the detailed build logs, but they don't shed much light - the lines are very long and the build steps appear to be executed in a different order. One strange thing I notice is that although I am building on an M1 Mac, with "build active architectures only" set to YES for both targets, in the Driver-target-only case, Driver.cpp is compiled for arm64, while in the failure case, Driver.cpp is compiled for x86_64. That doesn't make any sense to me either.
I fixed this.
The problem was a header file called Driver_public_shared.h, which was included in my Driver.cpp file. It lives on disk beside Driver.cpp.
By default, header files have Project membership, so they are not copied into the resulting output bundle.
If I give Driver_public_shared.h either Public or Private memberships of the dext target, it appears in the dext in the Headers or PrivateHeaders directory, and I can compile the delivery app, with the driver as a dependency.
Interestingly, the header appears in the build folder in the dext in Products/Debug/Debug-driverkit. But the dext which is embedded in the delivery app has no Headers directory. That's fine by me, I didn't want to deliver any headers as part of the driver, but I don't understand why there had to be a Headers folder in some circumstances and not others, nor do I understand why it is removed when embedding the dext.