arm-gtest VS Bear

The learning curve is really not as steep as it may seem. Using Cmake actually makes the whole build process a lot easier and much more modular allowing you to easily swap in/out different components by including different cmake files or not. I made an example repo not so long ago that demonstrates this: link.

A few days ago I posted my sample project which uses the cmake approach for this. As u\embeddedartistry mentioned two output directories are configured, one for native compilation (unit test) and one for cross-compilation (target binaries etc.). I just created a small script that builds both targets with a single command and I find it very pleasant to work with so far. All with a single command you can: build unit tests, run the unit tests, build target binaries and flash binaries onto the target. You can also only run the tests or only flash of course. Essentially it contains different cmake files for each target which are included in the main cmake file so it's easy to swap in/out different libraries or targets.

https://github.com/tomasvr/arm-gtest Hey everyone, a while back I started learning about TDD and how it can be applied to embedded projects (book). I created a sample project which sets up the necessary environment and automates most of the boring stuff so that you can run unit tests natively and flash the target hardware with a single command. By default, the repository is configured for the stm32f1 (blackpill) MCU but it can be configured for other ARM-based MCU supported by libopencm3 as described in the readme. I hope it can be of use to someone!

Have you tried Bear? I used it for several projects and overall it works very well.

An update: I am now able to make everything work by generating `compile_commands.json` using compiledb. I'm aware that there is another tool Bear but for some reason it generates an empty `compile_commands.json` file for me.

Try https://github.com/rizsotto/Bear

Regarding the libraries, you might need to add it to clangd’s configuration. A convenient way is to have a compile_commands.json in your project (this is generated by some build tools like CMake, but if you don’t use them, have a look at bear).

Note that you need to have a compile_commands.json file. That file can easily be generated by CMake, Meson, etc. For other build systems checkout Bear https://github.com/rizsotto/Bear

make a 'gcc' command/executable that do nothing and make it first in your PATH and then run bear with make: https://github.com/rizsotto/Bear/issues/219 It is unfortunate that bear doesn't catch the output of the make command with '--dry-run' as it still prints the compile commands, it seems not that hard to support this and I think many ppl would benefit..

You could try to start with Bear: https://github.com/rizsotto/Bear In worst cases, I had to use strace to catch every gcc/g++ invocation and restructure the compile_commands.json out of the strace logs.

But it sounds like maybe you’re assuming for the purposes of using something like clangd (highly recommended for coding in cpp projects in general, you want to be using this in vscode or whatever else anyway, codelion notwithstanding I suppose) with neovim on a c++ project that you have to use cmake to produce a compilation database to use with neovim plugins (e.g. clangd via nvim-lsp et. al.). In this case, be aware that the https://github.com/rizsotto/Bear tool is a handy way to just tack it on to whatever command you’re using to run a c++ code build step, and it will give you a compile_commands.json, corresponding to the compiler commands it invoked, on a silver platter.

I guess your questionmarks are about installing "bear", he refers to this project: https://github.com/rizsotto/Bear

You just simply go to the root of your project, use bear and just open your C files. That's all.