View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008264CMakeCMakepublic2008-12-08 17:222008-12-17 09:25
Reporterjlblanco 
Assigned ToBrad King 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0008264: PATCH: FindPackage searches in ${ProgramFiles}/name*
DescriptionI think it'd be very useful for many Windows software packages to carry a FooConfig.cmake file which could be simply installed among the normal program files, e.g. "C:\Program Files\Foo-x.x.x\FooConfig.cmake".

Currently, CMake can only detect such packages if the "/bin" subdirectory is appended to $PATH, or if a custom FindFoo module exists.

Please, consider merging this patch which looks for the installation folder directly using a "glob" (non-recursive) expression.

The help of the "find_package" command has been updated accordingly (new point 0000005):

===========================================================================
...
4. Search the standard system environment variables. This can be skipped if NO_SYSTEM_ENVIRONMENT_PATH is passed. Path entries ending in "/bin" or "/sbin" are automatically converted to their parent directories.

   PATH

5. Typical instalation paths. For now this only applies to Windowsfor the paths that match the following pattern (where <name> iscase insensitive):

  ${ProgramFiles}/<name>* (W)

6. Search project build trees recently configured in a CMake GUI. This can be skipped if NO_CMAKE_BUILDS_PATH is passed. It is intended for the case when a user is building multiple dependent projects one after another.
...
===========================================================================
TagsNo tags attached.
Attached Filespatch file icon find_package_progfiles.patch [^] (3,938 bytes) 2008-12-08 17:22 [Show Content]

 Relationships

  Notes
(0014372)
Brad King (manager)
2008-12-16 11:22
edited on: 2008-12-16 11:23

I've thought about this search location a bit more. I don't think we should hard-code any search locations in front of any configurable locations. The CMAKE_SYSTEM_PREFIX_PATH variable is meant to contain common install locations (but can also be adjusted by the project or user environment).

On Windows, the CMAKE_SYSTEM_PREFIX_PATH variable already contains the program files directory. I propose that instead of explicitly searching it we just add another convention for searching below a prefix. Currently in CMake HEAD (in CVS) we have the following:

Windows convention:

  <prefix>/
  <prefix>/(cmake|CMake)/

Unix convention:

  <prefix>/(share|lib)/cmake/<name>*/
  <prefix>/(share|lib)/<name>*/
  <prefix>/(share|lib)/<name>*/(cmake|CMake)/

Mac convention:

  <prefix>/<name>.framework/Resources/
  <prefix>/<name>.framework/Resources/CMake/
  <prefix>/<name>.framework/Versions/*/Resources/
  <prefix>/<name>.framework/Versions/*/Resources/CMake/
  <prefix>/<name>.app/Contents/Resources/
  <prefix>/<name>.app/Contents/Resources/CMake/

Note that the Mac convention basically means the top-level application and framework container directories should be in the list of prefixes searched. This is the Mac equivalent of the program files folder on Windows.

I propose that we add

  <prefix>/<name>*/
  <prefix>/<name>*/(cmake|CMake)/

to the windows convention list. Then since the program files folder is already in the system prefix path the desired behavior will be achieved.

(0014380)
jlblanco (reporter)
2008-12-17 03:14

Perfect for me, Brad! Seems to cover more cases with less intrusion.

What I though after submitting this was that in cases of short package names, e.g. "gl" (for opengl), etc..., the <prefix>/<name>* expressions may expand to too large lists... It might a good idea to constrain the search to expressions such as:
  <name>-*
  <name>_*
  <name>[0-9]*
  etc...

But I'm neither fully convinced with this approach: if the search is efficient enough even with large lists of matching directories, I'd prefer the simpler "<name>*".
(0014382)
Brad King (manager)
2008-12-17 09:24

First, a fix to make sure both 64-bit and 32-bit program files folders are listed in CMAKE_SYSTEM_PREFIX_PATH:

/cvsroot/CMake/CMake/Modules/Platform/WindowsPaths.cmake,v <-- Modules/Platform/WindowsPaths.cmake
new revision: 1.6; previous revision: 1.5

Now the new search locations and a test:

/cvsroot/CMake/CMake/Source/cmFindPackageCommand.cxx,v <-- Source/cmFindPackageCommand.cxx
new revision: 1.54; previous revision: 1.53
/cvsroot/CMake/CMake/Tests/FindPackageTest/Baz 1.1/BazConfig.cmake,v <-- Tests/FindPackageTest/Baz 1.1/BazConfig.cmake
initial revision: 1.1
/cvsroot/CMake/CMake/Tests/FindPackageTest/Baz 1.1/BazConfigVersion.cmake,v <-- Tests/FindPackageTest/Baz 1.1/BazConfigVersion.cmake
initial revision: 1.1
/cvsroot/CMake/CMake/Tests/FindPackageTest/Baz 1.2/CMake/BazConfig.cmake,v <-- Tests/FindPackageTest/Baz 1.2/CMake/BazConfig.cmake
initial revision: 1.1
/cvsroot/CMake/CMake/Tests/FindPackageTest/Baz 1.2/CMake/BazConfigVersion.cmake,v <-- Tests/FindPackageTest/Baz 1.2/CMake/BazConfigVersion.cmake
initial revision: 1.1
/cvsroot/CMake/CMake/Tests/FindPackageTest/CMakeLists.txt,v <-- Tests/FindPackageTest/CMakeLists.txt
new revision: 1.16; previous revision: 1.15

 Issue History
Date Modified Username Field Change
2008-12-08 17:22 jlblanco New Issue
2008-12-08 17:22 jlblanco File Added: find_package_progfiles.patch
2008-12-15 10:36 Bill Hoffman Status new => assigned
2008-12-15 10:36 Bill Hoffman Assigned To => Brad King
2008-12-16 11:22 Brad King Note Added: 0014372
2008-12-16 11:23 Brad King Note Edited: 0014372
2008-12-16 11:23 Brad King Note Edited: 0014372
2008-12-17 03:14 jlblanco Note Added: 0014380
2008-12-17 09:24 Brad King Note Added: 0014382
2008-12-17 09:25 Brad King Status assigned => closed
2008-12-17 09:25 Brad King Resolution open => fixed


Copyright © 2000 - 2018 MantisBT Team