[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [paho-dev] paho.mqtt.c library status
|
Frank,
I have the CMake builds working now for Travis and AppVeyor, including
tests and TLS thanks to various contributions which I have built on.
These cover Linux, Mac and Windows OSes, which is my primary goal.
Now that they are working, the CMake builds seem to work well, including
for Windows. Plus they are used for the CI testing, so considering
CMake builds as the primary seems a reasonable choice.
Ian
On 01/04/17 20:38, Frank Pagliughi wrote:
Hello Ian,
Was a decision made on which build systems(s) will be used with the C
library? If multiple ones, will any one be considered more "official"
than the others?
Frank
On 02/08/2017 05:58 PM, Ian Craggs wrote:
Hello Guilherme,
thanks for the information, and the contributions you have made.
I do want the Autotools build to make it into the master branch, I
just have to work out how to maintain all the different build
systems. Thanks for the offer of maintaining the Autotools build.
One of the things I need to understand is for the CMake build, as it
is meant to be cross-platform, how many platforms do I need to check
that the build works for in the automated builds and regression
tests. I hope that Linux, MacOS and Windows is sufficient... all the
embedded platforms would be too much, just for me.
Ian
On 02/01/2017 11:37 PM, Guilherme Maciel Ferreira wrote:
Hello Ian,
Juergen made a change in the Autotools branch that allows it to build
out of the source. Thus the Autotools does not have to replace the
Makefile.
Now, the Autotools branch is also tested by Travis CI. So we don't
risk to break the build.
In case the Autotools build makes its way into the main branch, I'm
pleased to keep maintaining it. Right now I'm working adding some unit
tests to Paho MQTT C++.
Best regards,
2017-01-26 17:26 GMT-06:00 Ian Craggs
<icraggs@xxxxxxxxxxxxxxxxxxxxxxx>:
Hello,
thanks for asking about the C client, I've been meaning to explain
for a
while. The project is not abandoned, but I've had difficulty
finding the
time to look at it since the release last year including automatic
reconnect
and publishing while connected. I've been focussed on work for the
IBM
Watson IoT Platform development for a while, but in the open source
world
I'm spread somewhat thinly too:
Eclipse Paho
project leading - managing contributions, etc
C client
embedded MQTT C client, including for mbed
embedded MQTT-SN C client
MQTT test material
I have thought that the MQTT clients would stabilize functionally
at some
point, and that the current C client is close to that point in
terms of
features, but not in other aspects of course. If anyone disagrees
on that
point I'd be happy to hear :-)
My difficulties began when some alternative build mechanisms were
contributed, which is good, but results in a greater maintenance
effort. I
had originally provided build mechanisms for three platforms: Make
for Linux
and MacOS, and Visual Studio for Windows. Then CMake followed
later by
Autotools builds were contributed, and at one point it was
suggested that I
drop make. I'm not familiar with CMake or Autotools, but of course
could
become so with some effort. It was suggested that CMake could be
used for
Windows too.
I would rather not maintain so many build mechanisms. I want to
keep Make,
because it needs little maintenance, and I use it in the automated
tests for
Linux. If we include alternative build mechanisms they should
really also
be used in continuous integration tests too, to make sure any
changes do not
break those builds. For Windows, I think that keeping Visual Studio
builds is essential, as that is the natural build environment.
So there is a significant amount of effort needed to sort out the
automated
build and testing of the project, in addition to the functional
defects. In
the near future, there is also the question of a C client for MQTT
V5, which
we will need to start. I intend to write that one in the style of
the MQTT
embedded clients so that they are more flexible in function and use.
I'm open to suggestions of how to handle the proliferation of build
mechanisms. If anyone is interested in the idea of becoming an
Eclipse Paho
committer to help me with the C client, especially in the area of
build and
test, then please let me know.
I will be attempting to find some time to look at the C client
soon, in any
case. Any and all thoughts, advice and/or help are very much
appreciated.
Thanks
Ian
On 26/01/17 17:11, Guilherme Maciel Ferreira wrote:
Hello Sylvain,
As far as I know, the project is not abandoned. But for some reason
(that I'm not aware of) things stopped.
Have you reported your issue?
Best regards
2017-01-26 3:11 GMT-06:00 Sylvain Miermont
<sylvain.miermont@xxxxxxxxx>:
Hello
I'm using the paho.mqtt.c library for a project and everything was
working
fine until I tried to use TLS. I went to the forum, the project bug
tracker,
the Github issues list and pull requests, and found some issues
that might
be similar but no solution in sight.
Is the project abandoned?
Sylvain
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx
Eclipse Paho Project Lead; Committer on Eclipse Mosquitto
Tech Lead in IBM Watson IoT Platform