[getdns-users] [PATCH] remove GETDNS_COMPILATION_COMMENT

[Robert Edmonds]

Daniel Kahn Gillmor wrote:
> We could also add a version info function without breaking backward API
> compatibility, if the concern is that the cost of making a context and
> parsing the response is too expensive.

I recently added version info capabilities to a C library that I
maintain.  I based it on how libevent2 does it, which is to export
library functions that return the version number as a string or encoded
into a 32-bit integer.  libevent2 also exposes the same values as
library headers.

[...]
    /**
       Get the Libevent version.

       Note that this will give you the version of the library that you're
       currently linked against, not the version of the headers that you've
       compiled against.

       @return a string containing the version number of Libevent
    */
    const char *event_get_version(void);

    /**
       Return a numeric representation of Libevent's version.

       Note that this will give you the version of the library that you're
       currently linked against, not the version of the headers you've used to
       compile.

       The format uses one byte each for the major, minor, and patchlevel parts of
       the version number.  The low-order byte is unused.  For example, version
       2.0.1-alpha has a numeric representation of 0x02000100
    */
    ev_uint32_t event_get_version_number(void);

    /** As event_get_version, but gives the version of Libevent's headers. */
    #define LIBEVENT_VERSION _EVENT_VERSION
    /** As event_get_version_number, but gives the version number of Libevent's
     * headers. */
    #define LIBEVENT_VERSION_NUMBER _EVENT_NUMERIC_VERSION
[...]
    /* Version number of package */
    #define _EVENT_VERSION "2.0.21-stable"
[...]
    /* Numeric representation of the version */
    #define _EVENT_NUMERIC_VERSION 0x02001500
[...]

So you get the version number in two different forms (string/numeric),
and for both the headers that were used at compile time as well as the
runtime library.

I'm not saying it's a good idea to rely on these for anything, but this
seems to cover the use cases commonly requested by library users, at
least IME.

+1 to reproducible builds.

-- 
Robert Edmonds
edmonds at debian.org