MantisBT - CMake
View Issue Details
0015293CMakeCMakepublic2014-12-08 11:262015-05-04 09:05
Gavriloaie Eugen-Andrei 
Brad King 
urgentmajoralways
closedfixed 
Linux x86_64Debian7.0.5
CMake 3.0.2 
CMake 3.2CMake 3.2 
0015293: find_library does not account for directory modification between calls
I have a cmake-based project and as part of it I need to build and install a 3rd party library. For this purpose, I have created a shell script which builds and install that library in a certain location. This 3rd party library is autohell based (autotools, autoconf, etc).

Logical steps performed inside my cmake script are as follows:

1. Try to use FIND_PATH to locate the header files and FIND_LIBRARY to locate the library. Tolerate the not-found errors at this step
2. If (1) fails, than I execute that install script which properly installs the 3rd party lib in that location. I can clearly see the headers and the libs under that target folder
3. execute (1) again, this time not tolerating the errors. Now, FIND_PATH succeeded for the headers files but FIND_LIBRARY fails. Again, the *.a is in place.

Further more, if I delete all intermediate files generated by cmake (leaving the 3rd party lib intact) and execute cmake again, (1) is a success.

I suspect that cmake somehow caches the result of FIND_LIBRARY at (1) and uses it directly at (3), without really doing any search
I have attached the file which is doing the detect/install/detect-again steps
No tags attached.
? Find_usrsctp.cmake (1,659) 2014-12-08 11:26
https://public.kitware.com/Bug/file/5320/Find_usrsctp.cmake
? Find_usrsctp2.cmake (2,005) 2014-12-08 12:16
https://public.kitware.com/Bug/file/5322/Find_usrsctp2.cmake
txt CMakeLists.txt (2,856) 2014-12-08 12:46
https://public.kitware.com/Bug/file/5323/CMakeLists.txt
Issue History
2014-12-08 11:26Gavriloaie Eugen-AndreiNew Issue
2014-12-08 11:26Gavriloaie Eugen-AndreiFile Added: Find_usrsctp.cmake
2014-12-08 11:31Gavriloaie Eugen-AndreiNote Added: 0037406
2014-12-08 11:41Brad KingNote Added: 0037408
2014-12-08 11:42Brad KingDescription Updatedbug_revision_view_page.php?rev_id=1630#r1630
2014-12-08 11:51Gavriloaie Eugen-AndreiNote Added: 0037410
2014-12-08 12:14Gavriloaie Eugen-AndreiNote Added: 0037411
2014-12-08 12:16Gavriloaie Eugen-AndreiFile Added: Find_usrsctp2.cmake
2014-12-08 12:46Gavriloaie Eugen-AndreiFile Added: CMakeLists.txt
2014-12-08 12:48Gavriloaie Eugen-AndreiNote Added: 0037413
2014-12-08 15:43Brad KingNote Added: 0037419
2014-12-08 15:43Brad KingAssigned To => Brad King
2014-12-08 15:43Brad KingStatusnew => assigned
2014-12-08 15:43Brad KingTarget Version => CMake 3.2
2014-12-08 15:43Brad KingSummaryFIND_LIBRARY not working consistently => find_library does not account for directory modification between calls
2014-12-15 15:44Brad KingStatusassigned => resolved
2014-12-15 15:44Brad KingResolutionopen => fixed
2014-12-15 15:44Brad KingFixed in Version => CMake 3.2
2015-05-04 09:05Robert MaynardNote Added: 0038700
2015-05-04 09:05Robert MaynardStatusresolved => closed

Notes
(0037406)
Gavriloaie Eugen-Andrei   
2014-12-08 11:31   
cmake version in the issue was not correctly specified because that value was not found in the combo-box. Cmake version is "3.1.0-rc2" and is compiled and installed from sources.

before that I had a cmake 2.8.x and it was behaving identically, installed using debian's aptitude
(0037408)
Brad King   
2014-12-08 11:41   
From the find_library command documentation:

 http://www.cmake.org/cmake/help/v3.1/command/find_library.html [^]
 "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."

What is the value of the result variable after the first (failed) try?
(0037410)
Gavriloaie Eugen-Andrei   
2014-12-08 11:51   
Will try that immediately and update this.

Thank you for the swift reply
(0037411)
Gavriloaie Eugen-Andrei   
2014-12-08 12:14   
I've done:

UNSET(USRSCTP_INCLUDE_PATH)
UNSET(USRSCTP_LIBRARY_PATH)

just before executing the FIND_PATH and FIND_LIBRARY. Same behavior.

Also, this is a bit strange because on mac os x Yosemite with "cmake version 3.0.2" it works just fine with and without those UNSET calls

I have attached the updated version of the script as well.

Output for mac os x: (B - before, A - After)
...
-- ----B: USRSCTP_INCLUDE_PATH:
-- ----B: USRSCTP_LIBRARY_PATH:
-- ----A: USRSCTP_INCLUDE_PATH: USRSCTP_INCLUDE_PATH-NOTFOUND
-- ----A: USRSCTP_LIBRARY_PATH: USRSCTP_LIBRARY_PATH-NOTFOUND
...
-- ----B: USRSCTP_INCLUDE_PATH: USRSCTP_INCLUDE_PATH-NOTFOUND
-- ----B: USRSCTP_LIBRARY_PATH: USRSCTP_LIBRARY_PATH-NOTFOUND
-- ----A: USRSCTP_INCLUDE_PATH: [...]/include
-- ----A: USRSCTP_LIBRARY_PATH: [...]/libusrsctp.a

Output from debian:
...
-- ----B: USRSCTP_INCLUDE_PATH:
-- ----B: USRSCTP_LIBRARY_PATH:
-- ----A: USRSCTP_INCLUDE_PATH: USRSCTP_INCLUDE_PATH-NOTFOUND
-- ----A: USRSCTP_LIBRARY_PATH: USRSCTP_LIBRARY_PATH-NOTFOUND
...
-- ----B: USRSCTP_INCLUDE_PATH: USRSCTP_INCLUDE_PATH-NOTFOUND
-- ----B: USRSCTP_LIBRARY_PATH: USRSCTP_LIBRARY_PATH-NOTFOUND
-- ----A: USRSCTP_INCLUDE_PATH: [...]/include
-- ----A: USRSCTP_LIBRARY_PATH: USRSCTP_LIBRARY_PATH-NOTFOUND
(0037413)
Gavriloaie Eugen-Andrei   
2014-12-08 12:48   
I have attached a simple CMakeLists.txt

It emulates the creation of the 3rd party library in /tmp/3rdparty by simply touching "${3RDPARTY_ROOT}/install/include/usrsctp.h" and "${3RDPARTY_ROOT}/install/lib/libusrsctp.a"
(0037419)
Brad King   
2014-12-08 15:43   
It looks like we were caching directory listings without considering the directory modification time. This should fix it:

 find_library: Fix repeat call after changing directory content
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ce331bab [^]
(0038700)
Robert Maynard   
2015-05-04 09:05   
Closing resolved issues that have not been updated in more than 4 months.