Distinguish "Greeter" as the name of the CMake project and as the name of files/directories/classes
nerrons opened this issue · 8 comments
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.
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?
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.
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?
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 beinclude/greeter/*.h?
Exactly! I hope that would clarify things a bit.
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:
- 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.
- 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. - Add a new self-removing command in
cmake/tools.cmakethat would allow to customise the project. E.g. after cloning you could runcmake -S. -Bbuild -DRENAME_CPP_STARTER=MyProjectto automatically rename project and include paths.
Personally, I like both approaches 1. and 3.
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.
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!