[CMake] Effective CMake - warning on bad practices

[cen]

I finished watching "Effective CMake" talk by Daniel Pfeifer from last
year and it seems to me it is the "GO TO" resource for best practices. A
quick scan of my CMakeLists.txt files and sure enough, I use
include_directories() and other "dont's". The problem is that none of
the things mentioned in the talk:

a) give any warnings when running cmake

b) are mentioned as bad practice in the docs


What I would prefer is that everytime a bad practice is used a big red
warning would be printed by CMake so I could see it and correct it.

Since CMake is apparently very slow deprecating things a solution
appeared in my mind after seeing the function wrap functionality. How
about a file called Effective.cmake which contains something like
(pseudocode):

function(include_directories input output)

    message(DEPRECATION "Use target_include_directories() instead."

    _include_directories(...)

endfunction()

function(set input output)

    if (${ARG0} STREQUAL "CMAKE_CXX_FLAGS")

        message(DEPRECATION "You probably shouldn't use this directly")

    endif

    _set(...)

endfunction()

...


then include(Effective.cmake) in your CMakeLists.txt to enable all
warnings. The effort here is to compile a list of existing bad practices
and wrap them (if such a thing is possible).


Does this approach seem reasonable? Is there an effort with similar
goals out in the wild which I should know about?



Best regards,

cen
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://

[Craig Scott]

Post by cen
I finished watching "Effective CMake" talk by Daniel Pfeifer from last
year and it seems to me it is the "GO TO" resource for best practices. A
quick scan of my CMakeLists.txt files and sure enough, I use
include_directories() and other "dont's". The problem is that none of
a) give any warnings when running cmake
b) are mentioned as bad practice in the docs
What I would prefer is that everytime a bad practice is used a big red
warning would be printed by CMake so I could see it and correct it.
Since CMake is apparently very slow deprecating things a solution
appeared in my mind after seeing the function wrap functionality. How
about a file called Effective.cmake which contains something like
function(include_directories input output)
message(DEPRECATION "Use target_include_directories() instead."
_include_directories(...)
endfunction()
function(set input output)
if (${ARG0} STREQUAL "CMAKE_CXX_FLAGS")
message(DEPRECATION "You probably shouldn't use this directly")
endif
_set(...)
endfunction()
...
then include(Effective.cmake) in your CMakeLists.txt to enable all
warnings. The effort here is to compile a list of existing bad practices
and wrap them (if such a thing is possible).
Does this approach seem reasonable? Is there an effort with similar
goals out in the wild which I should know about?

I would strongly advise against overriding built-in commands. The use of
undocumented behavior to try to call the previous original implementation
is not robust and can lead to infinite recursion. See the following article
for an explanation of why:

https://crascit.com/2018/09/14/do-not-redefine-cmake-commands/

I'm not aware of any efforts currently underway to add such a feature to
CMake itself. I think there is certainly a growing interest among users for
this sort of capability though.

Regarding guidance in the official CMake docs, they do try to avoid being
too opinionated, but things that are formally deprecated are usually
documented as such. Some commands still have their uses, even if they
should mostly be avoided, so they don't get the deprecation treatment.
Contributions to improve the docs are always welcome (and a big shout-out
to Joachim Wuttke who has been putting in a great effort lately in this
area).