Hello,
I’m concerned about cmake version-race and project maintainability especially in deeply embedded project.
I have inherited certain habits/practices since cmake 2.6 which I’m reluctant to change. One of the reasons is because I don’t want people stuck with an older cmake-version disabled by their systems ability (or own willingness) to upgrade if not necessary. But another is personal strong unwillingness to mess with stuff that works. Once done, stuff should be left alone (as per old UN*X philosophy). But things aren’t always as easy as they seem and one can’t always be as anal as one would like…
So in short my question is about the “proper” (or best practice) use of project(…) and cmake_minimum_required(…). In addition, also the habit of having complete CMakeLists.txt in each source sub-directory. (I.e. I have a strong preference towards molecularity, yet some people fear the perceived extra maintenance).
Modularity:
To me modularity even beyond the obvious scope for coarse level big project, makes sense also for minuscule levels. It makes re-use even for wrap-around debugging much easier, especially in cross-build environments where setting up debugging can be a real pain, the ability to wrap-and-debug even a small parts can makes life much easier and save tons of time. What do you think of this practice? I’ll personally take the small extra lines penalty (mostly adding include_directories) as these lines don’t usually change anyway and can furthermore be abstracted using common_functions.cmake files. There is ONE irritating drawback however. Cmake isn’t very good at composing higher level libraries out of libraries from sub-project (think static, cross built ones. These are usually preferred to be ONE library, not a plethora). The ability to have system-specific ldtool re-composition easily
would be a deeply appreciated ability to add to Cmake.
Project(), version and VERSION:
project(…) first argument is “name”. This used to be sensitive to the same level directory-name and I’ve always used the exact same name, spelling and capitals and all. I don’t remember if issue was when build out-of-source, when cmake projects included each other or combination of both, but I’m 100% certain there was one. Confirming or correcting is appreciated as having several cmake projects called “src” when using cmake recursively seems… stupid.
project(…) can also take take the option VERSION which has caused much confusion, especially with recursive project files. I therefore avoid it altogether, as setting explicit VERSION* is just as easy and will make the CMakeLists.txt both future proof and cmake_minimum_required downgradeable if needed.
As mentioned, I usually make an effort to keep cmake_minimum_required as low as possible to not disable users, unless there IS an actual feature that is essential. Hence, my projects can include sub-modules where cmake_minimum_required is different. Is there any drawbacks with that?
I’ve assumed that cmake_minimum_required not only requires a certain version, but if set lower than the actual cmake version being in use, it will also set that version specific policies. Is that correct? I.e. the VERSION behavior and project name issue above will differ not only on which actual version of cmake itself, but also with how cmake_minimum_required is set. I have also assumed that when used recursively, the right policies will follow accordingly to each CMakeList.txt setting. Is this correct? I.e. policies change with CMakeLists.txt and aren’t defined on top-level.
Comments, discussion or references to best-practices deeply appreciated
Regards -Gajah