Many fixes to CMakeLists and dsdl compiler

[thirtytwobits]

Massive integration here, sorry. These changes are to kick start CI builds and other formal mechanisms which will govern on going development. Included are:

Goodies

1. Full docker support – uavcan/libuavcan is now a container in our dockerhub repository. I also have a .travis.yaml file that should enable CI builds using this container. Once this PR is merged I'll enable travis builds for the bluesky branch and will probably have a PR or two to get it all working.
2. CMake scripts to support multi-target builds – ci.sh will build "native" (i.e. whatever "this" platform is) and arm-none-eabi.
3. A working ST32H build of our unit tests – The tests don't yet actually work on target but they are compiling and we have very little work left to make this a complete solution. I'm currently working with an NXP FAE to enable this on the S32K146 per our plans to use that as our official embedded test platform. When I do that I'll remove the ST32H files.
4. A working S32K146 build of our unit tests – This build produces binaries that can be loaded and run on a S32K146EVB and will report gtest results on LPUART1.
5. Arm-none-eabi build of googletest/googlemock – It can be done. It has been done.
6. pydsdlgen integration
7. doxygen build
8. no submodules – sorta. Switched to using CMake external projects for our external dependencies (dsdl types and googletest). This means that after a clone you only have to mkdir build; cd build, cmake .. to get a full set of working makefiles and all our dependent sources.
9. lcov integration started – but not completed. I'll make this a priority to get coverage reports and codacity integration allowing us to monitor the quality of the ongoing work.
10. clang-format build-check – Builds fail on violations of our .clang-format rules.
11. saturating add/subtract supporting all stdint types without compiler intrinsics – This logic should be portable to all architectures that use twos complement to represent signed integers. We may decide to support optional intrinsics where available (e.g. on arm we could use SSAT USSAT for everything up to (u)int32. We'd need to fall back to our software implementation for (u)int64).
12. parameterized tests for libuavcan – This change establishes parametrized tests as a set of first-class test artifacts we will export with the library. Users can chose to implement these for their target to verify any code that may be sensitive to different compilers and/or architectures. See libuavcan/include/test/ptest_time.hpp for our first such artifact. The idea is to allow platform verification suites to be developed in our platform specific driver repositories.
13. Scott thinks he understands cmake now – but is still unsure why.

Still TODO

Things I still want to accomplish from a build and test standpoint are:

1. clang-tidy – Build-time linting.
2. on-target test automation – Finish the "flash, run, report" part of the on-target test story. This may also include switching to buildkite as a CI provider to allow for connected hardware.
3. doxygen warnings as errors – Get the public headers cleaned up enough to force us to follow our documentation rules.
4. coverage reports – Mentioned above: lcov reporting to codacity.
5. documentation hosting – Find a solution for automatically pushing doxygen HTML to a public server.

[pavel-kirienko]

oh boy

[pavel-kirienko]

(You may have noticed that I am using this PR as an opportunity to criticize some of my own code that I wrote years ago)

[pavel-kirienko]

Switched to using CMake external projects for our external dependencies (dsdl types and googletest). This means that after a clone you only have to mkdir build; cd build, cmake .. to get a full set of working makefiles and all our dependent sources.

This is cool but there's more to life than CMake.

Could you please briefly describe in a few sentences how would one integrate libuavcan v2.0 into a Make-based build process? I am picturing this:

• embed the libuavcan header files into the build tree (submodule, subtree, or copy-paste)
• #include <uavcan/uavcan.hpp>
• embed the DSDL source files into the build tree
• pip install pydsdlgen
• invoke pydsdlgenj (truly rolls off the tongue) from the Makefile

Am I missing anything here? Please let's not get unnecessarily consumed by CMake.

[thirtytwobits]

For your cmake comment: your bullet points are correct; that's basically what you need to do as a library consumer. I think there's a lot more user-facing documentation to be produced along this line in the future. I could also add a Makefile integration section below the section on pydsdlgen cmake integration (you can pronounce it /pie-d'ess-delshen/ if you want to claim it's French).

[thirtytwobits]

I'd like to merge this so I can finish hooking up CI. Can we agree this change isn't toxic and then we can continue the review with follow-up pull requests?

[pavel-kirienko]

saturating add/subtract supporting all stdint types without compiler intrinsics

I forgot to ask: what do we need this for?

[thirtytwobits]

I needed it for the duration math and then I went down a hole implementing it. I'm assuming it will become important for supporting saturated integer types in dsdl?

[pavel-kirienko]

I'm assuming it will become important for supporting saturated integer types in dsdl?

Not sure. Maybe not, unless you have a different approach to their support than what I have in mind. Basically, saturation is performed during serialization once per field, unless the field is of a standard bit length (8, 16, 32, 64) in which case it requires no additional handling.

[thirtytwobits]

Crap, I forgot about #187

One more push with the removal of the C-only flags in native and changing the nascent "porting" namespace to be "platform"