[zeromq-dev] zmq_version

Steven McCoy steven.mccoy at miru.hk
Thu Jan 28 04:51:09 CET 2010


Another example, libevent,

http://www.wangafu.net/~nickm/libevent-book/Ref1_libsetup.html#_detecting_the_version_of_libevent

#define LIBEVENT_VERSION_NUMBER 0x02000300
#define LIBEVENT_VERSION "0.2.0.3-alpha"*const* *char*
*event_get_version(*void*);
ev_uint32_t event_get_version_number(*void*);


Provide #defines for compile time checks, numeric function for runtime
check, and string for informative display.

This means you will should to keep the micro version number rolling along
with whatever version suffixes you wish to use.

-- 
Steve-o

2010/1/28 Martin Sustrik <sustrik at 250bpm.com>

> Peter, Steven,
>
> My preference would be to use a function rather than global variable, the
> rationale being that there are already other functions in 0MQ ABI but no
> global variable yet. That way we'll avoid any troubles that global variables
> may possibly introduce on different platforms etc.
>
> Another question whether to expose the version as string or as tuple of
> integers. The string makes it impossible to compare two versions. Tuple of
> integers on the other hand freezes the versioning system forever. Currently
> there is major version, minor version, stability (alpha/beta etc.) and
> release ordinal, i.e. 2.0-beta3.
>
> Thoughts?
> Martin
>
> Peter Busser wrote:
>
>> Steven,
>>
>> Such an interface looks good to me. I am not sure, but I think that
>> CFFI can access foreign variables. Of course  the check version
>> function is a great idea.
>>
>> Groetjes,
>> Peter.
>>
>> 2010/1/27 Steven McCoy <steven.mccoy at miru.hk>:
>>
>>> 2010/1/27 Peter Busser <busserpeter at gmail.com>
>>>
>>>> Hi,
>>>>
>>>> I appreciate that there are libraries which provide a version as a C
>>>> macro. But as I have described on the dev mailing list, the Common
>>>> Lisp CFFI foreign function interface doesn't use header files. The
>>>> whole interface is specified in Lisp. In other words, not a single
>>>> line of C code is compiled. Therefore macros aren't very effective for
>>>> as far as the CL interface is concerned.
>>>>
>>>> Don't forget that a macro provides information about the version at
>>>> compile time, not at run-time.
>>>>
>>>
>>> I believe Lisp not using the header files means it avoids the problems
>>> that
>>> the macros have been written to solve.  However for your issue, both GLib
>>> and Protobuf provide numbers as global variables, apparently to resolve
>>> another problem with shared libraries,
>>>
>>> /* Glib version.
>>>  * we prefix variable declarations so they can
>>>  * properly get exported in windows dlls.
>>>  */
>>> GLIB_VAR const guint glib_major_version;
>>> GLIB_VAR const guint glib_minor_version;
>>> GLIB_VAR const guint glib_micro_version;
>>> GLIB_VAR const guint glib_interface_age;
>>> GLIB_VAR const guint glib_binary_age;
>>>
>>> const gchar * glib_check_version (guint required_major,
>>>                                  guint required_minor,
>>>                                  guint required_micro);
>>>
>>> --
>>> Steve-o
>>>
>>>  _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100128/edb4fa26/attachment.htm>


More information about the zeromq-dev mailing list