Ceedling + CMake

[JoseAmador95]

The company I work for uses both Ceedling and CMake for unit tests and build system, respectively. Since there is significant overlap between both, would you consider making Ceedling be driveable from CMake?

Mostly, I would like to have matching build options in both build systems, so taking the compile options from compile_commands.json instead of the project.yml would be ideal. We cannot live without CMock, it is too good. However, making the autocompletion work and build options match CMake is a big task.

I have tried to integrate Unity and CMock in a way similar to what CMake would do, but I think my implementation lacks the magic Ceedling puts on top of Unity + CMock (the test runner generation, autodiscovery, auto-mock with a header prefix, etc...).

This is my current implementation, https://github.com/JoseAmador95/cmake_toolbox.

The actual test files are fully compatible with Ceedling.

[Letme]

Why don't you drop CMake and just use Ceedling for release build as well? I am still using make for release builds as well - simply because make all is more familiar to my fingers, but am interested in what is your experience.

[JoseAmador95]

The company I work for has a bunch of reusable code that we manage with CMake. We use it as a simplified package manager.

Also, we manage a lot of build configurations for our projects. We need to support different targets, toolchains and user-level configuration that CMake supports quite well (regardless of the painfully steep learning curve).

I don't think we are dropping CMake anytime soon. Ceedling would be a downgrade in terms of build system configuration.

[CJCombrink]

We also have this exact setup.
Our project supports many platforms and build configurations and the library is provided to another team using predominantly cmake for hardware integration.

Our tests use ceedling (unity, cmock, etc) but in many instances we have to duplicate project settings in both cmake and ceedling to support our customers (internal) and testing, and this is error prone and counter productive.

The current setup is that ceedling is configured to (re)build the project and tests and then run the tests.

With the migration to ceedlng 1.0 we are now trying to move the building of the library exclusively to cmake and only the tests to ceedling and then link against the cmake library. This works to some extent but now the issue of duplication is becoming even worse.

The ideal would be to get the ceedling magic from within CMAKE directly. I don't know how this would look but perhaps a way to define a list of test files (or glob using cmake) and pass that to cmake_ceedling which then creates a cmake target(s) for unity and cmock which will then inherit the cmake project settings. This is very much in line with what @JoseAmador95 has linked in his cmake_toolbox.

Related would be to integrate test discovery and running into ctest.

PS: I come from a C++ background and I am familiar with protocol buffers, they do something similar although it is an IDL but using a protobuf_generate cmake function it generates source and header files from a list of proto files. I think the same can apply.

[CJCombrink]

@JoseAmador95

This is my current implementation, https://github.com/JoseAmador95/cmake_toolbox.

After writing my previous comment I went through your repo and this is almost 100% what we need.
Maybe just upgraded to the latest unity and cmock, but for the rest it looks like all we would need