Martin,
sust...@250bpm.com said:
> > 0. You don't really need the PACKAGE_VERSION_XXX macros? They looked (to
> > this noob) like a standard thing...
>
> Dunno. They were generated by hand.
No they weren't. They were done by hand in the MSVC-specific header file
because MSVC doesn't integrate with the autotools build that all other
platforms use. For the autotools build the AC_DEFINE_UNQUOTED(...) and
AC_SUBST(PACKAGE_VERSION) results in the values being correctly propagated
to where they're needed.
> The file in question is used only by MSVC build. MinGW and Cygwin builds
> use the standard autotools-generated platform.hpp
I'm not sure what to do about this; the problem is a "plain" MSVC build
can't even rely on something like "sed" to be present. If we had a tool
like that then we could make the MSVC build use a "template" platform.hpp
on which variable substitution would be done before the build starts (AFAIK
it is possible to run commands as part of a MSVC project build process?).
Does anyone have any ideas? If we could unify as much as possible of the
MSVC build that would be really nice.
> > 2. I believe there is still a reference to hard-coded version numbers in
> > configure.in:
> >
> > AC_INIT([zeromq],[2.1.0],[zeromq-...@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.
> > 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.
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.
-mato
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
