Expose library/utility functions to tools#860
Merged
bradh352 merged 12 commits intoc-ares:mainfrom Aug 22, 2024
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The tools like
adigandahostcan take advantage of some of the library functions within c-ares. We can't really split these library functions into a helper library without possibly breaking users. Technically if we could guarantee they rely on pkg-config or cmake helpers we could make it work ... we can revisit that in the future, maybe if we make a c-ares 2.0 where people might expect more breakage (but I still wouldn't want to break API/ABI).So what this does is it just exports some symbols in headers that aren't distributed so end users aren't meant to use the symbols, but any utilities or tests built by c-ares can. It does clutter up some of the namespace, but all these symbols are guaranteed to be prefixed with
ares_so there shouldn't ever be symbol clashes due to this for end users and its not so many symbols that it should affect any load times.There will be zero API/ABI guarantees for these symbols. They can change from release to release, this is ok since they are not public.
I'm not entirely thrilled with doing this solution, but I want to avoid thing like hand-written parsers, such as is used in #856.
Authored-By: Brad House (@bradh352)