A simple project template for testing libraries in C++ using the LLVM toolset, Make and valgrind

• Have the LLVM toolchain installed eg clangd for IDE extensions , clang-format for code formating, lldb-vscode for debugging in spacemacs as well as lldb and clang-format extensions in vscode

Explanation by structure

1. The pipeline

• There is a simple CI/CD pipeline that initially sets a DEPLOYMENT flag to development so we can get a comprehensive list of warnings in the pipeline
• We also use Valgrind for memory leaks or issues, as well as cppuint for unit testing
• We need to export the LD_LIBRARY_PATH in BOTH the local (your pc) and remote (the pipeline) enviroments (I am currently doing that manually per working directory)
• Then we build with some production flags and finally deliver the library

2. .vscode/

• We need this folder in order to tell lldb-vscode how to act when debugging
• We use the ./vscode/jaunch.json to hook a launch process by invoking the test recipe (which builds the test executable to run the tests) from the Makefile (more on that later)
• We use the ./vscode/tasks.json to define the build task which builds a test executable with development flags

3. The src directory

• Each file shall have its correposnding header and a vice versa (I believe this logic gives a modern approach like C# or Java ehile it doesnt increase the actual complexity)
• Go wild, the build recipe will take care of the whole building process (more on that later)

4. the tests directory

• Follow the first principle as in the 3rd section
• The template is simple:
• a) make a class that extends the CPPUNIT_NS::TestCase
• b) declare the class inside the CPPUNIT_TEST_SUITE macro
• c) declare the setUp and tearDown member functions
• d) add all the functions that are supposed to test something in the protected label
• e) register them with the CPPUNIT_TEST macro
• f) close the definition of the CPPUNIT_TEST_SUITE macro with CPPUNIT_TEST_SUITE_END
• g) implement the functions!
• DO NOT TOUCH driver, or actually feel free to play around, but it shouldnt be changed

5. The weird Makefile

• Although the makefile is structured in a weird way eg traversing all the files upon each build, which makes it not suitable for big projects, it does remind of an abstration and thus making it easier to extend it
• It can distinguish the production and development env variables
• memory check with build the library, tests, run them and also generate a Valgrind report

6. The LLVM part

• There are a few solid configurations in order to boost your C++ knowledge by adding a lot of warnings and standards
• Nice to use a formatter for the whole project

Feel free to open a PR if you want to extend the template!