(0027481)
Brad King (manager)
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 (manager)
2011-09-23 08:39

What registry value is your installer creating?

(0027483)
Mourad (reporter)
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 (manager)
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 (reporter)
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 (reporter)
2011-09-23 09:59

It looks like <prefix> is not added to FOO_DIR.

(0027487)
Brad King (manager)
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 (manager)
2011-09-26 11:29

First some refactoring and cleanup to simplify the fix:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b0cd6305 [^]

Now the fix:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9149033c [^]

(0027490)
Brad King (manager)
2011-09-28 15:33

Bill disagrees with the fix, so I reverted the non-refactoring part:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0089cf69 [^]

Root-relative paths work fine when there is only one drive letter, which is very common.

(0041907)
Kitware Robot (administrator)
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.

Notes
(0027481) Brad King (manager) 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 (manager) 2011-09-23 08:39	What registry value is your installer creating?

(0027483) Mourad (reporter) 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 (manager) 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 (reporter) 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 (reporter) 2011-09-23 09:59	It looks like <prefix> is not added to FOO_DIR.

(0027487) Brad King (manager) 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 (manager) 2011-09-26 11:29	First some refactoring and cleanup to simplify the fix: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b0cd6305 [^] Now the fix: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9149033c [^]

(0027490) Brad King (manager) 2011-09-28 15:33	Bill disagrees with the fix, so I reverted the non-refactoring part: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0089cf69 [^] Root-relative paths work fine when there is only one drive letter, which is very common.

(0041907) Kitware Robot (administrator) 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.

Issue History
Date Modified	Username	Field	Change
2011-09-23 08:11	Mourad	New Issue
2011-09-23 08:38	Brad King	Note Added: 0027481
2011-09-23 08:38	Brad King	Assigned To	=> Brad King
2011-09-23 08:38	Brad King	Status	new => assigned
2011-09-23 08:39	Brad King	Note Added: 0027482
2011-09-23 09:06	Mourad	Note Added: 0027483
2011-09-23 09:21	Brad King	Note Added: 0027484
2011-09-23 09:56	Mourad	Note Added: 0027485
2011-09-23 09:59	Mourad	Note Added: 0027486
2011-09-23 11:43	Brad King	Note Added: 0027487
2011-09-23 11:44	Brad King	Summary	PACKAGE_DIR entry is wrong when the Registry is used to find a package => find_package produces path without drive letter if package is in c:/<package> directory
2011-09-26 11:29	Brad King	Note Added: 0027489
2011-09-26 11:29	Brad King	Status	assigned => resolved
2011-09-26 11:29	Brad King	Resolution	open => fixed
2011-09-28 15:33	Brad King	Assigned To	Brad King => Bill Hoffman
2011-09-28 15:33	Brad King	Note Added: 0027490
2011-09-28 15:33	Brad King	Status	resolved => feedback
2011-09-28 15:33	Brad King	Resolution	fixed => reopened
2016-06-10 14:28	Kitware Robot	Note Added: 0041907
2016-06-10 14:28	Kitware Robot	Status	feedback => resolved
2016-06-10 14:28	Kitware Robot	Resolution	reopened => moved
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Relationships