The above mentioned version is being released within the next day or two and has already been tagged and merged back to master at the authors github. this version also has removed the oem conan recipe in favor of assuming conan-center is doing a better job keeping it updated. Looking to adopt this new version as soon as possible for a critical project. make us proud!
Additionally the lead developer Ian Craggs has indicated an interest in helping steer this recipe to accommodate upcoming changes but isn't sure how to get involved on here... developers maintain their own mattermost channel that might be useful in bringing onboard...
paho.mqtt.c 1.3.2 was released by Ian Craggs 3 days ago... hoping this gets some priority
What is required to contribute a 1.3.2 update:
1.3.2 locally to recipes/paho-mqtt-c/config.yml and recipes/paho-mqtt-c/all/conandata.yml1.3.1 patches for 1.3.2 (see recipes/paho-mqtt-c/all/conandata.yml and recipes/paho-mqtt-c/all/patches/cd recipes/paho-mqtt-c/all/ && conan create . paho-mqtt-c/1.3.2@ you can create now a pull requestI'll nudge the Paho lead Ian Craggs to this thread since he had expressed interest in contributing to this project over here and getting things integrated properly...
I guess this also implies updating to the paho.mqtt.cpp/1.1.1 that is still in progress by Frank Pagliughi (@fpagliughi also on Paho Mattermost)...
I've requested as per step 1. Now to figure out the others...
Thanks for contributing! If you have any further questions don't hesitate to ask any time 馃槃
I should add that it's version 1.3.4 which has been contributed because 1.3.2 accidentally introduced a binary backward incompatibility with 1.3.1, and in the process of fixing it I made a mistake with 1.3.3. That's what you get for trying to do things quickly!
Appears setting the recipe option 'ssl' to True does not ultimately link the library with SSL support enabled. Also noticed regardless of the 'ssl', 'asynchronous' and 'shared' settings it always packages all variants of the library together and so it isn't clear which binary the consuming application ultimately is linking against.
Appears setting the recipe option 'ssl' to True does not ultimately link the library with SSL support enabled. Also noticed regardless of the 'ssl', 'asynchronous' and 'shared' settings it always packages all variants of the library together and so it isn't clear which binary the consuming application ultimately is linking against.
@keysight-daryl Could you please open a new issue relating it? It can be a bug in that recipe.
@keysight-daryl never mind, I saw your issue now: #1882
Most helpful comment
1862 is merged, can be closed now
Thanks for contributing! If you have any further questions don't hesitate to ask any time 馃槃