cmake-init VS pitchfork

https://github.com/friendlyanon/cmake-init This is how you do CMake properly. If you deviate from its install rules you are highly likely to do something wrong.

CMake itself is as declarative as a build systems need to be. For anything nontrivial, these "declarative" solutions all fall apart. Just use https://github.com/friendlyanon/cmake-init, learn CMake and you won't have any issues.

If you want something with a (mostly) Just Works experience then just use https://github.com/friendlyanon/cmake-init

For CMake basics check out the official "Getting started" tutorial: https://cmake.org/cmake/help/latest/guide/tutorial/index.html, as well as Introduction to Modern CMake. You can also get inspired by the CMake project generator cmake-init

You can just use https://github.com/friendlyanon/cmake-init to get a CMake + Conan C project ready to go with a short little command: cmake-init --c -e -p conan coolio

Just use cmake-init which sets you up with a variation of the pitchfork layout.

Link broken, should be https://github.com/vector-of-bool/pitchfork

I use a variation of thispitchfork github layout. I have found it a very useful structure for my projects. As for file names, I always have only one class per file with the file name matching the class name exactly.

Take a look at the pitchfork standard - a lot of projects follow this convention today: https://github.com/vector-of-bool/pitchfork

Consider using the pitchfork layout convention

This is what I was directed to in regards to this question and what I use to organise structure. I was told it's a good starting point so not sure if there is something better out there. https://github.com/vector-of-bool/pitchfork

A while ago I stumbled upon this pitchfork project layout, But for simple projects I have just one CMakefile with the few sources in one project inside. If this grows, I use this and put it in a subfolder of the new project and add_subdirectory it...