[zeromq-dev] [PATCH] Add VERSION macros

[gonzalo diethelm]

> > > 2. I believe there is still a reference to hard-coded version
numbers
> in
> > > configure.in:
> > >
> > >      AC_INIT([zeromq],[2.1.0],[zeromq-dev at lists.zeromq.org])
> >
> > Autotools still needs to know the version number. If has to be
changed
> > at 2 places each time new version is produced: zmq.h and
configure.in
> 
> -1
> 
> The MSVC build is "special" as usual, but at least(!) for all other
> platforms the version number should come from one single place, which
up
> till now has been configure.in which generated the autotools macros.
> 
> So, let's not make it worse than it is. The version number must come
from
> a
> single place, with a special exception for MSVC until we figure out
some
> better approach.

Perhaps we could have a file zmq_version.h (whatever) with ONLY these
three lines:

#define ZMQ_VERSION_MAJOR 2
#define ZMQ_VERSION_MINOR 0
#define ZMQ_VERSION_PATCH 10

This would be the only place where the version is maintained. Then this
file would be manually included from the MSVC build, and it could be
automatically processed by autoconf (using awk, cut, whatever) to
generate the second argument to AC_INIT().


> > > 3. It might be a good idea to be able to fetch the value of
> ZMQ_VERSION
> > > (the 20010) by calling a function, so that the caller (bindings)
don't
> > > have to re-implement that logic. Perhaps a fourth parameter to
> > > zmq_version(), or as its return value?
> >
> > I actually like the fact that the integer representation of version
is
> > hidden to applications. That allows us to change the algorithm in
the
> > future if the current one proves insufficient.
> 
> Agreed.

Let me point out that in some bindings (including Java), there are
choices to be made about the version that will be based on both the
preprocessor constants (basically, in the C++ glue code) and on the
runtime values. For instance, the Java Socket.getType() function would
do something like:

  int getType() {
    if (ZMQ.version() < ZMQ.make_version(2,0,10)) return -1;
    return callRealGetSockOpt(TYPE);
  }

I still believe it is easier, more transparent and more readable to do
it this way. I can do this anyway in Java because I can export the
results of the macros through C++ functions, but maybe other bindings
will not have access to the macros at run time (or it might be
cumbersome to do so).


> One thing that may be useful (and is of course trivial) would be to
also
> define ZMQ_VERSION_{MAJOR,MINOR,PATCH} in addition to the
> ZMQ_VERSION(m,m,p) construct. Preferences differ and some people
> may wish to just use this variant of the macros.

I am not sure what this would buy us. Can you expand?

-- 
Gonzalo Diethelm