-
-
Notifications
You must be signed in to change notification settings - Fork 333
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
Fix: Easy use of Swift classes in Objective-C projects #4585
Changes from 8 commits
45051d2
d49a897
9b1110b
f7bb137
92e5406
3d1eefa
4beb23d
8d4eeeb
e505cad
1de1e30
d9640b5
27cb6eb
7ac9d69
921f562
c7624bc
ca9343d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -42,11 +42,13 @@ FOUNDATION_EXPORT const unsigned char SentryVersionString[]; | |
# import <Sentry/SentrySpanProtocol.h> | ||
# import <Sentry/SentrySpanStatus.h> | ||
# import <Sentry/SentryStacktrace.h> | ||
# import <Sentry/SentrySwift.h> | ||
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.
I can now access 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. Yes, it does for Objc project. If you think this is a problem we close the PR, I tried other ways to solve this without success, its this or nothing (until we find something else). Also, this will be a big problem for some users with special projects, like this one: #4543 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.
Murphy's law: "Anything that can go wrong will go wrong." So someone will use these classes. They always do. If I'm not mistaken, there is no difference between an actual public class in ObjC and an accidentally public class as 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. Also, didn't we want to move the SR code into its own module / SPM / Cocoa package? Maybe this would help here. 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.
Yes, this would be a solution.
You can't, both are public.
No, its an auto generated header by Xcode 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. I would appreciate it if we didn't make all the Swift classes public to fix this issue, especially if we plan on converting more code to Swift. So even though moving the SR code to its extra package seems like a lot of work to fix this, it's the right thing to do, IMO. It would also reduce the size of the sentry-cocoa lib. |
||
# import <Sentry/SentryThread.h> | ||
# import <Sentry/SentryTraceContext.h> | ||
# import <Sentry/SentryTraceHeader.h> | ||
# import <Sentry/SentryTransactionContext.h> | ||
# import <Sentry/SentryUser.h> | ||
# import <Sentry/SentryUserFeedback.h> | ||
# import <Sentry/SentryWithoutUIKit.h> | ||
|
||
#endif // __has_include(<Sentry/Sentry.h>) |
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.
This is how we test if the SDK is working with objc.
Before this PR compiling iOS-ObjectiveC with this change would cause an error.