Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Contributing and coding standards?

Hi Daniel,

that's great news!  I'm just about to start looking at the embedded C project again, with the immediate goal of finished off the MQTT V5 support.  I'd also like to complete the threaded async version that I intended to write years ago.  (And proper example integration with at least one TLS library).

I can write up the coding standards I've followed.  What's wrong with tabs = 2 spaces? :-)  If we did use tabs, then you could set the indent to whatever you like when you look at it :-)

For each item you want to address, perhaps the best way to discuss is to open an issue, describe the problem and your plan, and then we, and any other interested party can add their comments.

One observation I have, is that I intended the project to be easily portable across operating systems and environments.  The risk of concentrating on one OS is that portability is lost, or hidden away.  I'd just like to be sure that isn't lost.


On 10/11/2018 22:29, Daniel Santos wrote:

I'm going to be using paho.mqtt.embedded-c for my project, but I want to do some clean-up first.  I'm having trouble finding the coding standards for this project.  Can anybody point me in the right direction?  I really hope it's not tabs = 2 spaces. :)

Among the things I want to address are building and installing both static and shared libraries on GNU/Linux (got that one working) and installing public header files.  I'm a bit uncertain on how to proceed with the later.  Should the installation of  embedded and standard c/c++ libraries be mutually exclusive or both be allowed to be installed on the same system?  If the later, what would be the best way to manage naming collisions?  Perhaps install headers into ${prefix}/include/mqtt/embed?

I would also like to clean up the general form of the c and c++ layers in regard to their headers, platform-specific inclusions, and choice of single vs multiple translation units.  I would like to treat the possibilities of -flto optimistically and allow for multiple TUs, while also dealing with present-day realities to support a single TU (I'm not having much luck with -flto and the C++ implementation at the moment).   Ideally, publicly installed client headers could just be included with some preprocessor define and the implementation gets included as well.

Advice and feedback appreciated.

paho-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Ian Craggs
icraggs@xxxxxxxxxx                 IBM United Kingdom
Eclipse Paho Project Lead & Mosquitto Committer

Back to the top