I tried to use
set(CMAKE_FIND_DEBUG_MODE FALSE) and it was working for several runs with find_path, find_package, find_jar. However after several runs I see no effect on find_path, find_jar (still works on find_package). I do not see it in CMakeCache.txtbut still I removed build dir and rebuilt. So how is the debug print controlled?
find_jar is not listed among supported find_ at CMAKE_FIND_DEBUG_MODE but I seen it was working giving debug output and till output no longer produces after a few runs (few seemingly unrelated code changes) . Is find_jar debug output controlled by CMAKE_FIND_DEBUG_MODE ?
I tried to use
find_...() command uses a cached value rather than actually trying to find something, it may not produce any output.
find_jar() is not a built-in command, it is a function defined by the
UseJava module. It is implemented in terms of the
find_file() command, which is why you may have seen debug output related to it.
Thank you. Could you please explain "uses a cached value ". I looked at CMakeCache.txt and there is no CMAKE_FIND_DEBUG_MODE set there. So it is not cached, I presume. So you probably meant that find_library (or other find_) does not even run if result already exist in cache like when libpq.so was found and libpq.so file did not change then find_library detects if libpq.so file has not changed it does not run the rest of find_library ?
However I am looking at the case when find_library does not find libpq.so and thats why I am trying to debug it with CMAKE_FIND_DEBUG_MODE . So I assume cmake shoud run find_library. Then why there is no debug printouts?
I see very inconsistent results with find . For instance if jar file name is ext_v1.jar the find_jar ( javaJAR NAMES ext PATHS…) sometimes fails . In such case I give it full name ext_v1 (both cases without extention .jar) then find_jar find file ok. After this I chnage back to shorten name ext and find_jar succeeds. On a fresh install it does not work again. So is there a way to force deterministic behavior?
Which variable in cache could control this?
With find_library I see sometime it requires to add prefix lib to the library name in NAMES argument even though when I am lucky and CMAKE_FIND_DEBUG_MODE debug output is provided, I see that (lib) is listed as considered option so adding lib prefix to NAMES argument should not be required and indeed sometimes find_library succeeds without lib prefix, but running again on new install it would fail again.
find_package() commands will save the result of a successful search in a cache variable. The docs for the
find_library() command explain it this way:
A cache entry named by
<VAR>is created to store the result of this command. If the library is found the result is stored in the variable and the search will not be repeated unless the variable is cleared. If nothing is found, the result will be
<VAR>-NOTFOUND, and the search will be attempted again the next time find_library is invoked with the same variable.
Regarding how to better understand what’s going on for
find_jar(), perhaps you can satisfy your own questions by looking at the way it is implemented. It’s actually not all that complex, consisting mostly just of a series of
if-else conditions before calling
find_file(). You can see the relevant logic here:
With find_library I see sometime it requires to add prefix lib to the library name in NAMES argument
The main case I’m aware of where you may want to explicitly include
lib in the library name with
find_library() is if you want to force it to prefer finding a static library. This can be done in a platform-dependent way on unix-based systems by listing the full filename of the library, like
libsomething.a, but this won’t work on Windows (static and shared libraries use the same
something.lib file name, so you can’t tell them apart). It may not work on other less common systems too (e.g. I think AIX uses
.a even for shared libraries, at least in some cases). Ordinarily, apart from this particular scenario, you’d let CMake add a
lib prefix by itself, which is probably what you are seeing it doing in the debug output.