-
Notifications
You must be signed in to change notification settings - Fork 309
Export C++ symbols #1920
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: main
Are you sure you want to change the base?
Export C++ symbols #1920
Conversation
Signed-off-by: Darby Johnston <[email protected]>
Codecov Report✅ All modified and coverable lines are covered by tests. ❌ Your changes status has failed because you have indirect coverage changes. Learn more about Unexpected Coverage Changes and reasons for indirect coverage changes. Additional details and impacted files@@ Coverage Diff @@
## main #1920 +/- ##
==========================================
+ Coverage 84.11% 85.00% +0.88%
==========================================
Files 198 181 -17
Lines 22241 13074 -9167
Branches 4687 1206 -3481
==========================================
- Hits 18709 11113 -7596
+ Misses 2610 1778 -832
+ Partials 922 183 -739
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 115 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
LGTM. I wonder if |
Signed-off-by: Darby Johnston <[email protected]>
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.
Couple of questions! Thanks for putting this together though. Did you check to see if the DSO sizes or load times change at all after this?
I checked and the sizes were the same, but I exported all of the symbols so I didn't expect any difference. Hopefully it's a feature we can take more advantage of in the future, for example the C++ OTIOZ PR has some code that might not need to be part of the public API. |
Co-authored-by: Stephan Steinbach <[email protected]> Signed-off-by: Darby Johnston <[email protected]>
Signed-off-by: Darby Johnston <[email protected]>
Signed-off-by: Darby Johnston <[email protected]>
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.
Hi Darby can you please separate the fabs from the GenerateExportHeader functionality? the fabs diff is easy to land, introducing a new meta-source generator needs some discussion. I'm not aware of any projects that use this facility, and I'd like to understand why that is.
#1919 describes in detail why this is needed. It's a problem we are facing with Kdenlive on clang based builds ie. macOS and FreeBSD. As it causes crashes it's a critical bug for us. There are workarounds, but these are, well workarounds and no proper fixes. Further description of the Kdenlive issue can be found here: https://invent.kde.org/multimedia/kdenlive/-/issues/1992 |
@meshula provided some sample code for replacing the GenerateExportHeader functionality, I'm going to try integrating it and will change this PR to a "draft" while I work through it. |
Fixes #1919
This change uses the CMake GenerateExportHeader functionality to explicitly export C++ symbols. In addition to fixing #1919, this can also potentially make the use of OTIO shared libraries more efficient.