-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Precompile prefix headers fails on Consumer because the -Swift.h
file includes an absolute path from Producer
#140
Comments
Hello @samuelsainz, I tried to reproduce an error but it works all the time. Posted a sample project here: |
Hey @polac24, thank you for building the project to troubleshoot this, super useful! The difference I am seeing with that project vs. ours is that If I check the I am checking the next file: I am trying to figure it out why is that happening in our project and not in that sample project 🤔 any ideas? |
Thanks, that ringed a bell - I exposed an enum from ObjC and that led to Sidenote: That is absolutely a bug, but I am curious how could that work on previous version of XCRemoteCache (mentioned v0.3.10). Such a scenario was considered and we has never modified |
Cool! So that was it—I tried adding some imports to the bridging header but I didn't realize I had to add code in the files for the bridging header to be actually imported. Answering your last question: I don't know to be honest, but I was able to produce and consume with that version. I had Precompile prefix header enabled—I was actually testing this fix. I can test again that version to see if it works, I will let you know |
@polac24 you're right. I tried with that version and didn't work either. I can't explain why it did work before and it is not working now, I didn't change anything in our project since I've been working on a branch that I haven't updated—but I will fix the issue description. |
Good to hear it was not a regression. I have a draft PR, but still, need to polish it a bit. FYI: #141 |
Hey @polac24, I have tested the PR #149, thank you for quickly addressing it btw. I see that the error is fixed when using that branch, but I am experiencing another issue probably related: When I build just the app it finishes successfully. That path to the app target Bridging Header is the absolute path in the producer side. I'm not finding where is taking that path from and how could I make it relative instead of absolute. The Bridging Header of the main app is set in the Build Settings relative to the Sources folder: Do you know what could be causing this? Thanks in advance! |
If you extend the red error message with a hamburger icon, there should be a chain of import. It could help you to troubleshoot from which file the producer's header is still imported. |
I tried to reproduce it (no success), so probably your case is quite unique and it would be hard to guess all details like:
Reproduce that in a sample project could help: https://github.com/polac24/XCRCBridgingPCH |
Hi @polac24, I've tried to reproduce it in this fork (https://github.com/samuelsainz/XCRCBridgingPCH) but I'm facing a problem: When I run the consumer for the sample project it always fail to cache the App target with the next error:
Since I can't consume the cached App target I can't reproduce the issue, because it recompiles the App target and also the Test target. Do you know why I am getting that error? |
@polac24 Hey, looking at the I removed the import of that file in the App target so it doesn't depend on it anymore and I was able to consume the cached App artifact—the fingerprints are equal now. Is this an expected behavior? Having said that, I wasn't able to reproduce the original error yet, I will let you know If I make any progress. |
Hi @polac24! Sure, enjoy your well deserved vacations. For when you come back from vacations—I have reproduced the issue in this sample project https://github.com/samuelsainz/XCRCBridgingPCH. You have to build for testing when producing and consuming. |
Hi @samuelsainz! I reproduced an issue with Xcode 13.3 and 14.0 (beta 2) and seems it that .swiftmodule file embeds type definitions from bridging headers along the absolute path to the bridging header file it was taken from. Even if on a consumer side we fix the generated However, if you look closer, the compiler generates a warning, which most likely is causing this kind of an edge case:
Unfortunately, that behaviour is still present in Xcode 14 so in order to get rid of that error, you could apply the fix suggested in Apple's forum (a change in
With that, the error and warning go away and in your tests you still can use |
Hey @polac24, sorry for the delay. I'm afraid that that doesn't work for us, because in our case the App target has both Swift and Objective-C code. I saw that warning as well. If I am understanding this right, not having that Implicit import of the Bridging-Header would solve our issue, right? But I didn't find a way to disable that either |
Me neither, looks that this swiftlang/swift#5977 has never got a follow-up PR so the bridging header is always explicitly imported. Until Swift fixes that, this scenario will not be covered in XCRemoteCache. |
My integration setup
[ x ] CocoaPods cocoapods-xcremotecache plugin
[ ] Automatic integration using
xcprepare integrate ...
[ ] Manual integration
[ ] Carthage
Expected/desired behavior
With the last version in master branch, the consumer mode is failing when precompiling prefix headers with the next error:
After looking into the
-Swift.h
file, I have confirmed that there is an import with an absolute path created by the producer.The /AppName/AppName/ path is where all the sources are and also the Podfile, the project, the workspace, etc.
Minimal reproduction of the problem with instructions
I can reproduce it 100% of the time just trying to build on consumer mode.
Environment
gem list cocoapods-xcremotecache
>Others
I am running this on CI so I don't have the producer/consumer logs—but let me know if they're relevant and I can get them.
I wasn't getting this error with v0.3.10The text was updated successfully, but these errors were encountered: