The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15448 ====================================================================== Reported By: nagger Assigned To: ====================================================================== Project: CMake Issue ID: 15448 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-03-16 14:32 CET Last Modified: 2015-03-16 14:32 CET ====================================================================== Summary: find_path() after mark_as_advanced() Description: It not clear to me if the following is a bug in CMake or just an invalid use: (I tested this for CMake 2.8.11, 3.0.1 and 3.2.1.)
set(my_path "anyvalue") find_path(my_path NAMES CMakeLists.txt HINTS ${CMAKE_CURRENT_LIST_DIR}) mark_as_advanced(my_path) find_path(my_path NAMES CMakeLists.txt HINTS ${CMAKE_CURRENT_LIST_DIR}) message("my_path: '${my_path}'") # my_path is empty here! 1st FIND_PATH() uses only the non-cached variable and does not create the cache-variable * this is not described in the docs ** the docs should also describe when and how the cached-variable and the non-cached variable is read and written ** same goes for all find_*-commands MARK_AS_ADVANCED() for an undefined cache-variable creates the cache-var with and empty value and type 'UNDEFINED' * Is this a bug(?) * It could use the value of the non-cached variable (if there is one) * or it should not set the VALUE-property of the cached variable * or set the type to 'STRING' The 2nd FIND_PATH() does not use the non-cached variable as in the first call, but clears the variable without search for the path * For me this looks like a bug! Steps to Reproduce: See attached self-contained CMakeLists.txt with a lot of test cases (T1 .. T8) and its output at the end of the file. For me T1 and T2 is a bug, at least it should act as in T5 or in T7. And T9 also seems like a bug since the docs say: "[...] the search will not be repeated unless the variable is cleared" And T8 is inconsistent to the other tests: Its overwriting the cached value although the variable is set. Until now I thought that the cached value is always overwritten with the value of the variable. Is there any reason why it is not? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-03-16 14:32 nagger New Issue ====================================================================== -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers