-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Silence build warnings when used in Xcode 26 via SwiftPM #725
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
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These files don't control header visibility in SPM, as far as I know. Did this somehow silence the warnings for you? Wouldn't
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The key change needed to support SwiftPM was ensuring this header was imported by FLEX.h, since it's a public header. Adding to FLEX.h fixes the error However, once I added the header to FLEX.h, the normal Xcode project build (not SwiftPM) failed, because FLEXFileBrowserController.h wasn't marked public in the project, despite being imported in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we instead update this code to conditionally use
UIScreen.screenwhen available? i.e.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maddeningly, wrapping in an
@availablecheck isn't sufficient to silence the deprecation warnings triggered via the SwiftPM import.Something like this would work though, which at least keeps the diagnostic override contained to one spot:
I'm not sure if using
UITraitCollection.currentTraitCollectionwill work consistently for all uses ofFLEXFlooretc. An alternative would be to pull it from the UIApplication singleton'sconnectedScenes, but that will be more cumbersome.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't want this to be true, but it would not surprise me. Lemme play around with this in an example project and see if I can reproduce it