Component file lists
dlyr opened this issue · comments
As discuss in #899, cmake source file lists could be probematic, and headless lib defines directly the file list in it's CMakeLists.txt
I open this issue to track source list management choices, and discuss alterantive.
The current evolution of component management make me think it can be better to have source list defined in the same place as the component, not in a general /cmake/ dir.
It's also good practice to list files explicitly and not using GLOB like stuff.
I like the idea to generate such file list with a script.
I don't get the mentionned problem : "prevent some IDE facilities (when adding a new class, the filelist must be updated manually)" is it fine to have the file list variable defined in some .cmake file or does it have to be in a CMakeLists.txt ?
We can have a script that generate the file list in CMakeLists.txt, but it makes huge lists for some components.
We can have file lists in Component base directory under src/Component, generated by a script.
We can stick to the current approach, each component have its file list in cmake/.
We can get rid of scripts, and let each component manage how the file lists are defined.
Comments welcom.
IMHO, having c++ files listed in a dedicated files is interesting to keep the cmake scripts of the components as short as possible, and readable.
I agree that having all the files in the cmake folder is not really nice, especially if we start to increase the number of components.
As such, I would be in favor of option 2:
We can have file lists in Component base directory under src/Component, generated by a script.
Here is my two cents on the several points exposed in this discussion :
-
it can be better to have source list defined in the same place as the component
- For me, this is the best practice to have. Keep related things together in the same place
-
It's also good practice to list files explicitly ...
- I fully agree with this. Doing this in a variable directly in the CMakeLists.txt or in a variable in a file included in the CMakeLists.txt is just a matter of readability when the file list become big. And we can always consider that big(n) is n>1 (among other recommendations about file list style) :p
-
... and not using GLOB like stuff.
- I also agree with this. It should be noted that the cmake documentation do not recommend to using GLOB to collect a list of source file (https://cmake.org/cmake/help/latest/command/file.html#glob). Moreover, I do not see the difference between GLOB like stuff and script that list files in (sub)folders. So I'm not in favor of a script to manage this list in the Radium-Engine source distribution.
Concerning the IDE facilities to manage automatically source list (in the in the CMakeLists.txt) when adding new file/class/ etc to the "project" , I recognize that it does not really matter, nor is different from the GLOB or script approach. It is just another way to write/maintain/execute a macro/script, but possibly simpler as it is integrated and provided by the IDE. (eg. right mouse click (or Command+N+C or ...) ... add new class ... enter the name ... start writing your class in the IDE generated files)
This is really IDE dependent. Some do not manage having files split into several set - like we have : source, headers, inlines, (e.g. VisualStudio or VSCode - except if using dedicated "scripts"), some will ask which variable to update when you add new files (like CLion), some do not bother and let you update your source list manually...
But whatever we decide for managing the cmake configuration of the Radium-Engine project, perhaps we could take inspiration of some "Modern cmake setup" like the one (among huge number of "modern cmake guide") at https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1
Unfortunately, there is no "official" (eg. written by the inventors/mainteners of the langage) cmake good practice recommandation as the one for C++ (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)
Let's do option 2.
Let's do option 2.
I only partly agree.
If I understand, option 2 is : We can have file lists in Component base directory under src/Component, generated by a script.
I agree with file list in Component base directory under src/Component but i do not understand the difference between a script and GLOB like stuff.
If we have to use a script, in which langage ? bash ? zsh ? python ? cmake ?
How to ensure the scripts is always correct on the several supported os/version/... ?
What this implies for users (Linux, macos, windows) ?
How to manage specificities of component source code hierarchy ?
I agree all these have answers but will require some kind of expertise for the developers on something they do not really use/know/understand ...
So, I'm not in favor of scripts, even if they ara really helpful for several of us, that will be another more thing to maintain, with the known difficulties of multi-os script maintenance (remind recent issues/PR related to unmaintained scripts).
Let the user do as he wants as long as conventions and formatting is respected.
Simple answer:
If you have a glob, then there is no cmake run on new file added.
If you have a script, you could use it or edit by hand directly (or let you ide do it for you).
We can remove from the script output the fact that the file is generated, or even I can remove the script from github and use it on my side ...
We can also use the script with guideline checks to check that script output corresponds to the commited file (even if set by hand) to ensure that file list is aphabetically ordered, whitout typo, nor missing files.