After reconsidering how the zmq_has API is intended to be used, I think using it at build time to expose parts of the API, as it is currently done, is a flawed approach:
The C ABI for the features probable by zmq_has is always present, so we can (and should) always expose it. The affected methods, when the corresponding feature is not present in libzmq, will, like their C counterparts, just fail with ENOTSUP.
Thus, all feature probing at build time should be removed, the whole API should be always exposed, and the documentation of the affected parts should be updated to indicate that they may fail with when the corresponding feature is not present in the libzmq present.
This will get rid of all the cross-compilation issues, and allow Rust code to handle missing features at runtime, like C code could would.
The feature-probing was introduced originally in commit d8cb8ee0 ("Binding update for ZMQ v4.1") in 2016, and was probably intended to cope with potentially missing C ABI, allowing for rust-zmq to work with a range of different libzmq versions, including ones that expose a subset of the C ABI that was supported by rust-zmq. Tying it to the zmq_has runtime probe was a mistake, I realize now, from the very outset.
Thus, going forward, after resolving this issue, rust-zmq will expose only functionality supported by the C ABI of the minimum libzmq version it requires, and will never conditionally disable parts of its API for older C ABI versions.
This affects at least issue #179 and the discussion in PR #247.
After reconsidering how the
zmq_hasAPI is intended to be used, I think using it at build time to expose parts of the API, as it is currently done, is a flawed approach:zmq_hasis always present, so we can (and should) always expose it. The affected methods, when the corresponding feature is not present in libzmq, will, like their C counterparts, just fail withENOTSUP.Thus, all feature probing at build time should be removed, the whole API should be always exposed, and the documentation of the affected parts should be updated to indicate that they may fail with when the corresponding feature is not present in the libzmq present.
This will get rid of all the cross-compilation issues, and allow Rust code to handle missing features at runtime, like C code could would.
The feature-probing was introduced originally in commit d8cb8ee0 ("Binding update for ZMQ v4.1") in 2016, and was probably intended to cope with potentially missing C ABI, allowing for rust-zmq to work with a range of different libzmq versions, including ones that expose a subset of the C ABI that was supported by rust-zmq. Tying it to the
zmq_hasruntime probe was a mistake, I realize now, from the very outset.Thus, going forward, after resolving this issue, rust-zmq will expose only functionality supported by the C ABI of the minimum libzmq version it requires, and will never conditionally disable parts of its API for older C ABI versions.
This affects at least issue #179 and the discussion in PR #247.