[
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.
Ian
On 10/11/2018 22:29, Daniel Santos wrote:
Hello,
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.
Thanks,
Daniel
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Eclipse Paho Project Lead & Mosquitto Committer
