|
Notes |
|
|
(0027481)
|
|
Brad King
|
|
2011-09-23 08:38
|
|
I cannot reproduce this. I created a "c:/Bar/FooConfig.cmake". Under key
HKEY_LOCAL_MACHINE\SOFTWARE\Kitware\CMake\Packages\Foo
I created value "blah" with data "c:/Bar". Then I ran CMake on the code
find_package(Foo)
and I got Foo_DIR=c:/Bar in the cmake-gui interface. Then i ran CMake on the code
find_package(FOO)
and I got FOO_DIR=c:/Bar in the cmake-gui interface. |
|
|
|
(0027482)
|
|
Brad King
|
|
2011-09-23 08:39
|
|
|
What registry value is your installer creating? |
|
|
|
(0027483)
|
|
Mourad
|
|
2011-09-23 09:06
|
|
My package name is "Foo 1.0 win64"
It get installed to : C:/Foo-1.0
The FooConfig.cmake is put into a subfolder "cmake" : C:/Foo-1.0/cmake/FooConfig.cmake
The Registry value get created into :
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Software\Kitware\CMake\Packages\Foo 1.2 win64
Its value is C:/Foo-1.0/cmake (without FooConfig.cmake) |
|
|
|
(0027484)
|
|
Brad King
|
|
2011-09-23 09:21
|
|
Your registry value is incorrect and not actually being used. That's why the directory name appears to matter.
Your package *name* is just "Foo". The *version* is "1.2 win64".
The documentation makes precise use of the term "registry key" v. "value":
On Windows a <package> may appear under registry key
HKEY_LOCAL_MACHINE\Software\Kitware\CMake\Packages\<package>
as a REG_SZ value, with arbitrary name, that specifies the directory
The *key* name should be
HKEY_LOCAL_MACHINE\Software\Kitware\CMake\Packages\Foo
and there should be a *value* in it called "1.2 win64" (or anything you want). The "value" should be of type REG_SZ and the data stored in it should be
C:/Foo-1.0/cmake |
|
|
|
(0027485)
|
|
Mourad
|
|
2011-09-23 09:56
|
|
Thank you Brad, it is working now with the registry.
I figured out that cmake was finding my Foo package because it is installed in :
<prefix>/<name>*/(cmake|CMake)/
And it seems, that the problem is here and not with the registry.
To sum up, if I have a valid registry key, FOO_DIR is correct. But if I remove the key, cmake still finds my Foo installation (C:/Foo-1.0/cmake), but then FOO_DIR is wrong ("C:" dissappears) |
|
|
|
(0027486)
|
|
Mourad
|
|
2011-09-23 09:59
|
|
|
It looks like <prefix> is not added to FOO_DIR. |
|
|
|
(0027487)
|
|
Brad King
|
|
2011-09-23 11:43
|
|
Okay, the remaining problem then is only the missing "C:". I tracked that down. It will happen only when there is a directory with the package name at the top of the current working drive when CMake runs. The path /Foo/cmake is actually a valid path on windows, but it is treated relative to the current working drive automatically. Most of the time this is "C:" so it appears to work.
The problem is that CMAKE_SYSTEM_PREFIX_PATH contains just plan "/" even on Windows. One can see the problem like this:
#list(REMOVE_ITEM CMAKE_SYSTEM_PREFIX_PATH /) # uncomment to fix
foreach(prefix ${CMAKE_SYSTEM_PREFIX_PATH})
message("prefix [${prefix}]")
endforeach()
unset(Foo_DIR CACHE)
find_package(Foo)
If one uncomments the list(REMOVE_ITEM) command the problem goes away.
It looks like the "/" prefix was added by:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2a782880#patch3 [^]
in order to preserve the CMAKE_FIND_ROOT_PATH behavior on MinGW added by:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dac78148 [^]
The "/" is useful as a prefix on Windows only when appended to a value of CMAKE_FIND_ROOT_PATH (usually for cross compiling). I think the fix is for the find_package command to ignore prefixes that do not start in a drive letter. |
|
|
|
(0027489)
|
|
Brad King
|
|
2011-09-26 11:29
|
|
|
|
|
(0027490)
|
|
Brad King
|
|
2011-09-28 15:33
|
|
|
|
|
(0041907)
|
|
Kitware Robot
|
|
2016-06-10 14:28
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|