Sibi Siddharthan <sibisiddharthan.github@xxxxxxxxx> writes: > Yes, this is trivial, but doing so is bad practice in general and > difficult to maintain. Can you substantiate "bad" and "difficult" in the above sentence? They are so subjective words and sounds more of your "opinion" than generally accepted "fact". > Won't it be better just to copy the CMakeLists.txt to the root > directory for configuring. I do not know it is better or not compared to using directly from a subdirectory. But it is easy to see that it is a bad practice to keep the source of truth in contrib/cmake/CMakeLists.txt and use it by copying it to the top of the working tree. The reason would be obvious once you imagine what happens when those who are helping to improve CMake support find that they need to make changes. It is too easy to edit the one they copied to the top of the working tree until they manage to get it working, and then forget to copy it back to contrib/cmake/ before committing the change [*1*]. Compared to that, the way Konstantin showed, which is just to be at the top of the working tree and run the cmake command with a single argument, which is the path to the CMakeList.txt file, looked quite simple and straight-forward to an untrained eye that hsan't seen a real use of CMake. But there must be reasons, coming from lessons learned by using CMake with a CMakeList.txt file in a subdirectory and suffering the consequences of doing so, that makes you say it is a bad practice and difficult to maintain. It needs to be spelled out to help those who do not know CMake understand. Thanks. [Footnote] *1* Creating a symlink CMakeLists.txt at the top of the working tree that points into contrib/cmake/CMakeLists.txt (and it needs to be done only once) would avoid such a problem, but if your filesystem does not let you use a symlink, copying a skeletal CMakeLists.txt that nobody is expected to modify to the top of the working tree might be an acceptable workaround. The sole purpose of that skeletal CMakeLists.txt at the top of the working tree would be to include the "real" thing in contrib/cmake/ directory (I am assuming that CMake is capable of including a CMakeLists.txt file that exists elsewhere in another CMakeLists.txt file). With either of these arrangements, it is much less likely for the user to accidentally edit a "wrong" copy and forgets to update the real thing---the real thing stored in contrib/cmake will be the only one that would be edited.
