(0037815)
Brad King (manager)
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 (reporter)
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 (manager)
2015-01-26 15:11

Which CMake generator (-G) are you using?

(0037826)
Lectem (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (manager)
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 (reporter)
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 (manager)
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 (manager)
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 (reporter)
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 (manager)
2016-01-04 11:51

Closing resolved issues that have not been updated in more than 4 months.

Issue History
Date Modified	Username	Field	Change
2015-01-23 19:18	Lectem	New Issue
2015-01-26 11:07	Brad King	Note Added: 0037815
2015-01-26 14:29	Lectem	Note Added: 0037820
2015-01-26 15:11	Brad King	Note Added: 0037822
2015-01-26 18:46	Lectem	Note Added: 0037826
2015-01-27 08:41	Brad King	Note Added: 0037830
2015-01-27 09:16	Lectem	Note Added: 0037834
2015-01-27 13:02	Brad King	Note Added: 0037842
2015-01-27 13:10	Brad King	Note Added: 0037843
2015-01-27 16:13	Lectem	Note Added: 0037846
2015-01-28 10:20	Brad King	Note Added: 0037850
2015-01-28 10:21	Brad King	Status	new => acknowledged
2015-01-28 10:21	Brad King	Summary	find_path MinGW not working while find_library does => find_path, find_file, and find_library should get prefixes from PATH
2015-02-19 09:47	Brad King	Relationship added	related to 0015409
2015-02-19 09:49	Brad King	Assigned To	=> Brad King
2015-02-19 09:49	Brad King	Status	acknowledged => assigned
2015-02-19 09:49	Brad King	Target Version	=> CMake 3.3
2015-02-19 10:04	Brad King	Note Added: 0038003
2015-02-19 10:04	Brad King	Status	assigned => resolved
2015-02-19 10:04	Brad King	Resolution	open => fixed
2015-02-19 10:04	Brad King	Fixed in Version	=> CMake 3.3
2015-06-25 09:46	Dave Yost	Note Added: 0038977
2016-01-04 11:51	Robert Maynard	Note Added: 0040079
2016-01-04 11:51	Robert Maynard	Status	resolved => closed

Notes
(0037815) Brad King (manager) 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 (reporter) 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 (manager) 2015-01-26 15:11	Which CMake generator (-G) are you using?

(0037826) Lectem (reporter) 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 (manager) 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 (reporter) 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 (manager) 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 (manager) 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 (reporter) 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 (manager) 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 (manager) 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 (reporter) 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 (manager) 2016-01-04 11:51	Closing resolved issues that have not been updated in more than 4 months.