On Fri, Nov 23, 2018 at 11:07 PM cen <imba...@gmail.com> 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:
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).
--
Craig Scott
Melbourne, Australia
https://crascit.com
New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-cmake/>
--
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
