<div dir="ltr">I think this approach also makes sense.  Never a bad thing to follow precedence.<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 9, 2015 at 4:21 AM Willem Toorop <<a href="mailto:willem@nlnetlabs.nl">willem@nlnetlabs.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks Robert,<br>
<br>
I think I prefer this.  If everybody here agrees I can put version<br>
functions and defines in getdns_extra.h.  We can always move them to<br>
getdns.h if the API list likes it this way too.<br>
<br>
-- Willem<br>
<br>
<br>
Op 08-07-15 om 21:57 schreef Robert Edmonds:<br>
> Daniel Kahn Gillmor wrote:<br>
>> We could also add a version info function without breaking backward API<br>
>> compatibility, if the concern is that the cost of making a context and<br>
>> parsing the response is too expensive.<br>
><br>
> I recently added version info capabilities to a C library that I<br>
> maintain.  I based it on how libevent2 does it, which is to export<br>
> library functions that return the version number as a string or encoded<br>
> into a 32-bit integer.  libevent2 also exposes the same values as<br>
> library headers.<br>
><br>
> [...]<br>
>     /**<br>
>        Get the Libevent version.<br>
><br>
>        Note that this will give you the version of the library that you're<br>
>        currently linked against, not the version of the headers that you've<br>
>        compiled against.<br>
><br>
>        @return a string containing the version number of Libevent<br>
>     */<br>
>     const char *event_get_version(void);<br>
><br>
>     /**<br>
>        Return a numeric representation of Libevent's version.<br>
><br>
>        Note that this will give you the version of the library that you're<br>
>        currently linked against, not the version of the headers you've used to<br>
>        compile.<br>
><br>
>        The format uses one byte each for the major, minor, and patchlevel parts of<br>
>        the version number.  The low-order byte is unused.  For example, version<br>
>        2.0.1-alpha has a numeric representation of 0x02000100<br>
>     */<br>
>     ev_uint32_t event_get_version_number(void);<br>
><br>
>     /** As event_get_version, but gives the version of Libevent's headers. */<br>
>     #define LIBEVENT_VERSION _EVENT_VERSION<br>
>     /** As event_get_version_number, but gives the version number of Libevent's<br>
>      * headers. */<br>
>     #define LIBEVENT_VERSION_NUMBER _EVENT_NUMERIC_VERSION<br>
> [...]<br>
>     /* Version number of package */<br>
>     #define _EVENT_VERSION "2.0.21-stable"<br>
> [...]<br>
>     /* Numeric representation of the version */<br>
>     #define _EVENT_NUMERIC_VERSION 0x02001500<br>
> [...]<br>
><br>
> So you get the version number in two different forms (string/numeric),<br>
> and for both the headers that were used at compile time as well as the<br>
> runtime library.<br>
><br>
> I'm not saying it's a good idea to rely on these for anything, but this<br>
> seems to cover the use cases commonly requested by library users, at<br>
> least IME.<br>
><br>
> +1 to reproducible builds.<br>
><br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@getdnsapi.net" target="_blank">Users@getdnsapi.net</a><br>
<a href="http://getdnsapi.net/mailman/listinfo/users" rel="noreferrer" target="_blank">http://getdnsapi.net/mailman/listinfo/users</a><br>
</blockquote></div></div>