MantisBT - CMake
View Issue Details
0015370CMakeCMakepublic2015-01-23 19:182016-01-04 11:51
Lectem 
Brad King 
normalminoralways
closedfixed 
MinGWWindows7
CMake 3.1 
CMake 3.3CMake 3.3 
0015370: find_path, find_file, and find_library should get prefixes from PATH
I couldn't get most of my libraries detected with find_package.
I figured out that the libraries files were found but not the headers.

For example :

find_path(GLEW_INCLUDE_DIR GL/glew.h)
will not work while
find_library(GLEW_LIBRARY glew32)
does.


FIND_PACKAGE(GLEW)

Does also set GLEW_LIBRARY and GLEW_LIBRARIES but not GLEW_INCLUDE_DIR.
FIND_PACKAGE(GLEW)
IF(GLEW_FOUND)
  MESSAGE(STATUS "GLEW found.")
  MESSAGE(STATUS "Detected GLEW path is : ${GLEW_LIBRARIES}")
ENDIF(GLEW_FOUND)
IF(GLEW_LIBRARIES)
  MESSAGE(STATUS "Detected GLEW_LIBRARIES path is : ${GLEW_LIBRARIES}")
ENDIF(GLEW_LIBRARIES)
IF(GLEW_INCLUDE_DIRS)
  MESSAGE(STATUS "Detected GLEW_INCLUDE_DIRS path is : ${GLEW_INCLUDE_DIRS}")
ELSE(GLEW_INCLUDE_DIRS)
  MESSAGE(STATUS "Couldn't find GLEW_INCLUDE_DIRS")
ENDIF(GLEW_INCLUDE_DIRS)
No tags attached.
related to 0015409closed Brad King FindOpenSSL does not find correct libraries with MinGW 
Issue History
2015-01-23 19:18LectemNew Issue
2015-01-26 11:07Brad KingNote Added: 0037815
2015-01-26 14:29LectemNote Added: 0037820
2015-01-26 15:11Brad KingNote Added: 0037822
2015-01-26 18:46LectemNote Added: 0037826
2015-01-27 08:41Brad KingNote Added: 0037830
2015-01-27 09:16LectemNote Added: 0037834
2015-01-27 13:02Brad KingNote Added: 0037842
2015-01-27 13:10Brad KingNote Added: 0037843
2015-01-27 16:13LectemNote Added: 0037846
2015-01-28 10:20Brad KingNote Added: 0037850
2015-01-28 10:21Brad KingStatusnew => acknowledged
2015-01-28 10:21Brad KingSummaryfind_path MinGW not working while find_library does => find_path, find_file, and find_library should get prefixes from PATH
2015-02-19 09:47Brad KingRelationship addedrelated to 0015409
2015-02-19 09:49Brad KingAssigned To => Brad King
2015-02-19 09:49Brad KingStatusacknowledged => assigned
2015-02-19 09:49Brad KingTarget Version => CMake 3.3
2015-02-19 10:04Brad KingNote Added: 0038003
2015-02-19 10:04Brad KingStatusassigned => resolved
2015-02-19 10:04Brad KingResolutionopen => fixed
2015-02-19 10:04Brad KingFixed in Version => CMake 3.3
2015-06-25 09:46Dave YostNote Added: 0038977
2016-01-04 11:51Robert MaynardNote Added: 0040079
2016-01-04 11:51Robert MaynardStatusresolved => closed

Notes
(0037815)
Brad King   
2015-01-26 11:07   
The find_path command documents an elaborate sequence of search paths it checks:

 http://www.cmake.org/cmake/help/v3.1/command/find_path.html [^]

You'll have to trace through the documented steps to see why it does not succeed in your environment for this header. The reason the command places GLEW_INCLUDE_DIR into the cache is to allow it to be manually configured when the header is in some non-standard location.
(0037820)
Lectem   
2015-01-26 14:29   
I couldn't find out why it isn't found in my environment.
I have C:\MinGW\bin in my path and MINGW_PATH=C:\MinGW
My libs are all located in C:\MinGW\include for the headers and C:\MinGW\lib for the .a
I don't see what else I could set for it to be detected without having issues with Visual.
Did I miss something ?
(0037822)
Brad King   
2015-01-26 15:11   
Which CMake generator (-G) are you using?
(0037826)
Lectem   
2015-01-26 18:46   
I tried with "MinGW Makefiles" (with and without C:\MinGW\msys\1.0\bin in PATH) and "MSYS Makefiles"
(0037830)
Brad King   
2015-01-27 08:41   
The find_package command, in "config" mode, knows how to search in prefixes discovered from each "<prefix>/bin" entry in the PATH environment variable. This could be generalized to work for the other find commands too.

Meanwhile you can add CMAKE_PREFIX_PATH=c:\MinGW to your environment.
(0037834)
Lectem   
2015-01-27 09:16   
FIND_PACKAGE(GLEW)

Isn't working even with CMAKE_PREFIX_PATH=C:\MinGW in my environment.

I do have the header ( C:\MinGW\include\GL\glew.h)

If I use FIND_PACKAGE(GLEW CONFIG) it obviously can't find the package config file since cmake only ships it as a module package.
(0037842)
Brad King   
2015-01-27 13:02   
Re 0015370:0037834: I cannot reproduce that. The code

 find_path(GLEW_INCLUDE_DIR GL/glew.h)

fails for me by default but works when I add CMAKE_PREFIX_PATH=C:\MinGW to my environment.

Of course as a workaround to all this locally you can always add -DGLEW_INCLUDE_DIR=c:/MinGW/include to your command line, or set the variable in cmake-gui by hand. This is the intended approach to specify the location of things in non-standard places, but can be used here too.
(0037843)
Brad King   
2015-01-27 13:10   
Are you sure find_library is finding the ".a" library file in c:/MinGW/lib and not a ".dll" in c:/MinGW/bin?
(0037846)
Lectem   
2015-01-27 16:13   
That was it, I actually had the .dll in c:/MinGW/bin !
I didn't think it would be a problem.

Would it possible to have CMAKE detect MinGW installation path or use some variable like MINGWDIR or MINGW_PATH when using MinGW/MSYS Makefiles generators ?

I believe C:\MinGW is a standard installation directory, and Qt users would only need to override those variables.
(0037850)
Brad King   
2015-01-28 10:20   
Re 0015370:0037846: By "standard" I meant "within the places CMake normally looks". What I'm saying in 0015370:0037830 is that commands other than find_package should use the PATH to get prefixes. That should subsume this use case.
(0038003)
Brad King   
2015-02-19 10:04   
I've implemented this here, with test cases:

 Teach find_(library|file|path) to get prefixes from PATH
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ffc06c12 [^]
(0038977)
Dave Yost   
2015-06-25 09:46   
I don't understand this fix is for find_package to look for the include dir in PATH. I would expect find_package to look for the include dir in CPATH.

I have a similar problem finding boost. The boost library's include dir is in CPATH, but find_package doesn't find it. The boost library tree has no bin dir, and if it did, there would be nothing in it.
(0040079)
Robert Maynard   
2016-01-04 11:51   
Closing resolved issues that have not been updated in more than 4 months.