TheLartians / ModernCppStarter

🚀 Kick-start your C++! A template for modern C++ projects using CMake, CI, code coverage, clang-format, reproducible dependency management and much more.
https://thelartians.github.io/ModernCppStarter
The Unlicense
4.33k stars 381 forks source link

Distinguish "Greeter" as the name of the CMake project and as the name of files/directories/classes #82

Closed nerrons closed 3 years ago

nerrons commented 3 years ago

Hi TheLartians

First of all thanks for this great project; it really simplifies things quite a bit.

One thing might be confusing for beginners though: the name "Greeter" is used both as the name of the CMake project and as the name of several files/directories/classes. Although you can technically distinguish these two by the capitalization of the first letter it still opens possibilities for mistakes.

One side effect in renaming the project name is also missing from the README: one needs to change #include <greeter/version.h> to #include <NewProjName/version.h> in .cpp files as well.

Do you think changing the project name to something like "YourProject" is better? I can make the PR.

TheLartians commented 3 years ago

Hey @nerrons, thanks for the suggestion! I do see how the naming can be confusing and lead to mistakes. I hoped that most problems should be easy to find thanks to the compiler's error message, e.g. after renaming a file. Tbh I'm not really sure how renaming the project to "YourProject" would help, as users would still run into the same issues?

nerrons commented 3 years ago

Hey @nerrons, thanks for the suggestion! I do see how the naming can be confusing and lead to mistakes. I hoped that most problems should be easy to find thanks to the compiler's error message, e.g. after renaming a file. Tbh I'm not really sure how renaming the project to "YourProject" would help, as users would still run into the same issues?

Then they can fearlessly replace all YourProject to whatever they want without breaking anything. Now they probably still have to look at each occurrence and try to figure out what they mean.

TheLartians commented 3 years ago

Ah, so if I understand correctly, you suggest separating the CMake target name from the include destination? E.g. in CMake, the target would be called MyProject, but the include files would still be include/greeter/*.h?

nerrons commented 3 years ago

Ah, so if I understand correctly, you suggest separating the CMake target name from the include destination? E.g. in CMake, the target would be called MyProject, but the include files would still be include/greeter/*.h?

Exactly! I hope that would clarify things a bit.

TheLartians commented 3 years ago

Yeah, I see how it would make iterative renaming easier. However, imo it's a good convention for libraries to use the project name in the include paths, which is kind-of enforced in the starter's structure. Removing it could lead to more derived projects changing both independently. Perhaps we can resolve the issue another way. Some ideas:

  1. Recommend using case-sensitive replace in the Readme and explain the naming scheme. Would be the easiest approach but requires users to read the readme carefully.
  2. Move all project-specific settings such as the project name and include path into a separate configuration file config.cmake. This would make it easier to get started with a new project, but would make the main CMakeLists less readable and discourage new users from learning / changing the actual CMake.
  3. Add a new self-removing command in cmake/tools.cmake that would allow to customise the project. E.g. after cloning you could run cmake -S. -Bbuild -DRENAME_CPP_STARTER=MyProject to automatically rename project and include paths.

Personally, I like both approaches 1. and 3.

nerrons commented 3 years ago

I agree with your concerns about having include path names consistent with project names for libraries. Thanks for that point.

Regarding approach 3 it feels like we're doing too much, aren't we? We gonna have another target to maintain while what it accomplishes is just a few ⌃F's (or ⌘F's). It's also good for beginners to actually read before they start and at least go through the main CMakeLists.txt's at least once.

TheLartians commented 3 years ago

Agreed that 3 may be a bit overkill, so it seems 1 is the best option moving forward. If you want to go ahead and add the disclaimer to the Readme, I'd be happy to review the PR!

nerrons commented 3 years ago

I changed the README a little bit in #84, please take a look 😄