Effective CMake - warning on bad practices

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Effective CMake - warning on bad practices

Klemen Ferjančič
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://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Effective CMake - warning on bad practices

Craig Scott-3


On Fri, Nov 23, 2018 at 11:07 PM cen <[hidden email]> wrote:
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?


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:


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).

--
Craig Scott
Melbourne, Australia


--

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://cmake.org/mailman/listinfo/cmake