Skip to content
  • Brad House's avatar
    Expose library/utility functions to tools (#860) · 7f19f162
    Brad House authored
    
    
    The tools like `adig` and `ahost` can 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: default avatarBrad House <(@bradh352)>
    7f19f162