[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [paho-dev] paho.mqtt.c library status
|
Hello Ian,
Sorry for taking too much time to answer. But I was on vacation.
2017-02-08 16:58 GMT-06:00 Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>:
> Hello Guilherme,
>
> thanks for the information, and the contributions you have made.
>
> I do want the Autotools to 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.
I'm glad you're still considering to include the Autotools. I guess it
will help many people, especially those more familiar with Autotools
than to CMake. BUT, if you think it's more trouble than helpful, you
don't have to merge it.
Regarding on how to maintain the build systems, what do you think
about a script to check if the libraries generated by the different
build systems are compatible (exported symbols, size, etc)? Also, once
I'm done with Paho MQTT C++ unit tests, I'll start the unit tests for
Paho MQTT C. Thus, most linking problems can be detected during
testing.
>
> 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.
Well, I'm far from being a CMake expert. But I have a couple of
virtual machines in which I test the builds. And I've noticed that
most platforms have its peculiarities that mess with the build. Thus,
IMHO the project could simply guarantee those that you've mentioned.
Like the C++ standard which guarantees the behavior of a subset of
statements and anything else is undefined behavior.
Best regards,
Guilherme
