-
Notifications
You must be signed in to change notification settings - Fork 438
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
[BUILD] Alternative way of exporting symbols (generating .def file) #2476
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
|
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.
Thanks for this tooling.
This is a huge improvement to the existing build IMO:
- The idea to use a regexp to export a "loosely" defined symbol, without the full prototype specification, is a big help, especially for maintainers that do not have a windows machine locally (like me)
- Exporting all
XXX::Create()
methods at once instead of listing all flavors with different prototypes helps. I assume that if somehow we need to be more specific, there is always the possibility to provide less selective regexp with the full prototype then, if needed, so this is not a blocking feature. - opentelemetry-cpp should not export all symbols named opentelemetry::xyz, so it is very desirable to list explicitly which class/methods are part of the public API, instead of exporting everything
- This will work very well with different ABIs, like 32/64 bit flavors, and will also work very well with different STL, because "nostd::unique_ptr" can mean different things and can become different types affecting the final symbol name, when compiling with different STL levels (nostd::X can be anything like nostd::X, std::X, abseil::X, ...)
Suggestions:
Is it possible to simplify the input.src file further, so that:
External\s+\|\s+(\?Create@OStreamSpanExporterFactory@trace@exporter@v1@opentelemetry[^\s]*)\s+\((.*)\)$
is replaced by just:
Create@OStreamSpanExporterFactory@trace@exporter@v1@opentelemetry
with the makefile scripts adding the regexp magic sauce.
Also, please add a licence and copyright line in new files, to fix the CI break for make_def.ps1
Waiting on @open-telemetry/cpp-maintainers for more comments.
Looks good.
@marcalff thanks - I have tried to do what you suggested, moving part of the regex into the powershell-script (and added the copyright/license line). I also made this PR ready for review (no longer a draft) |
Not sure if helpful, but |
@malkia That's interesting - thanks for the tip :) However, I think I'd keep using |
Thanks @meastp for the PR. Could you please help compare the list of exported function w/o this PR? Trying to understand how much more symbols could be exported with the regexp. |
@ThomsonTan the regexes basically match functions by name with namespace, so the only additional exported symbols would be overloads of the functions that aren't exported today but propably should be, right? :) |
@meastp can you please take a look at the format of the CMakeLists.txt? |
@ThomsonTan done :) |
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.
Thanks for the contribution, LGTM.
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.
LGTM, thanks for the tooling.
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.
Thanks. This will help in maintaining the symbols better way.
The current way of generating opentelemetry_cpp.def requires manually adding every symbol that is to be exported to opentelemetry_cpp.src. For symbols that differ based on compilation options (e.g. 64bit / 32bit) they have to be added individually and guarded with a macro.
This is an alternative approach that provides some convenience (=less maintenance):
vswhere
(I currently select the first match, but vswhere searches can easily be more specifix, e.g. only x64 architecture binaries)dumpbin
toolinput.src
contains regex-statements (also macros (e.g. WITH_OTLP_HTTP etc)input.src
is preprocessed (as opentelemetry_cpp.src is today) intoinput.txt
input.txt
This is a proof-of-concept. Currently, I have tried to duplicate the symbols exported today (except, all overloads are also available as they match the regex, so all 9 overloads of TracerProviderFactory::Create will be exported, for example, which is useful).
One could for example simplify the input/regex part to export all symbols containing "opentelemetry" (and perhaps be able to provide regex for symbols that should be excluded, if there are any?)
I'm not familiar enough with all symbols available to tell what approach is better, although if we could eliminate the input file and just export all symbols matching "opentelemetry", it would require minimal future maintenance.
I'll keep this as a draft for now, very interested in your input :)
For significant contributions please make sure you have completed the following items:
CHANGELOG.md
updated for non-trivial changes