public API?
- Original Message -
From: zeromq-dev-boun...@lists.zeromq.org
To: zeromq-dev@lists.zeromq.org
Sent: Sat Oct 02 14:11:09 2010
Subject: [zeromq-dev] Making language bindings work with both maint andmaster
Hi all,
We have to think of a way to make language bindings work with
On 10/02/2010 09:59 PM, gonzalo diethelm wrote:
> My suggestion was to have #define macros to identify the version of 0MQ
> against which a binding is being compiled. Something like ZMQ_MAJOR,
> ZMQ_MINOR, etc. Or a single #define ZMQ_VERSION to 20101002 (MMDD).
Yeah, something like that. Let'
On Sat, Oct 2, 2010 at 9:01 PM, Martin Sustrik wrote:
> On 10/02/2010 09:59 PM, gonzalo diethelm wrote:
>> My suggestion was to have #define macros to identify the version of 0MQ
>> against which a binding is being compiled. Something like ZMQ_MAJOR,
>> ZMQ_MINOR, etc. Or a single #define ZMQ_VERS
Another approach is to tag the binding's baseline with the version
that it matches. That way if we want to use 2.0.8, we just update to
that tag. If there is a version specific fix, we can always create a
small branch for that version.
Joshua
On 10/2/2010 4:34 PM, Mikko Koppanen wrote:
> On
Joshua,
That may actually work.
Thoughts anyone?
Martin
On 10/03/2010 03:12 AM, Joshua Foster wrote:
>Another approach is to tag the binding's baseline with the version
> that it matches. That way if we want to use 2.0.8, we just update to
> that tag. If there is a version specific fix, we
On Sun, Oct 3, 2010 at 6:18 AM, Martin Sustrik wrote:
> Joshua,
>
> That may actually work.
>
> Thoughts anyone?
>
Hi,
my 2 cents:
this might be more work the bindings maintainers and the users of the
bindings. What I assume users want is to download a single source
package of the bindings and
Keeping track of versions and the changes would end up being more work if it
was managed in code. While it may be a little simpler for someone to just
download a package that just works (which should be the latest), it would make
the code start fragmenting with if/else for the versions:
if versi
At Sat, 02 Oct 2010 22:01:57 +0200, Martin Sustrik wrote:
> > Why would this not work with some bindings? Are those not compiled using
> > the C public API?
>
> Nope. The two I've mentioned redeclare the ABI of the library in a
> native way.
CFFI includes groveller which is able to generate lis
Hi all,
> I think each language would have a preferred way to maintain such bindings,
> and to tie the main library and the bindings like that may work for
> one language,
> but would cause severe pain for others. I'd vote for a much looser coupling
> of between the main library and the bindings,
I'm not sure why "master" and "maint" are featured here -- are we talking
about the scenario where version X was released, but before version X + 1 is
released and master still has the version number X ?
If the above is correct, why don't zmq simply up the internal version number
to X + 1 upon the
On Mon, Oct 4, 2010 at 7:29 AM, Daisuke Maki wrote:
> Oh wait, or are you saying that currently there's no way to figure out the
> version of zmq before compiling the bindings?
> If that's the case I'd rather have a command line utility "zmq-config",
> rather than a typedef so I can detect it even
Yeah, I know, I let that slip by on purpose. I guess I didn't fool anyone ;)
--d
2010/10/4 Mikko Koppanen :
> On Mon, Oct 4, 2010 at 7:29 AM, Daisuke Maki wrote:
>> Oh wait, or are you saying that currently there's no way to figure out the
>> version of zmq before compiling the bindings?
>> If t
sust...@250bpm.com said:
> Hi all,
>
> > I think each language would have a preferred way to maintain such bindings,
> > and to tie the main library and the bindings like that may work for
> > one language,
> > but would cause severe pain for others. I'd vote for a much looser coupling
> > of betw
m...@kotelna.sk said:
> The only thing I'm not sure of is what is the best kind of version macro(s)
> to define... I'll have a think about it and look at the various options;
> will get back to this tomorrow.
Having thought about this a bit more and looked at the various proposals on
this thread I
At Mon, 4 Oct 2010 17:28:47 +0200, Martin Lucina wrote:
> Having thought about this a bit more and looked at the various proposals on
> this thread I'd like to propose the following syntax for version macros:
>
> 1) zmq.h would define ZMQ_VERSION to be some magic (opaque) constant that
> incorpor
15 matches
Mail list logo
