View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0008264 | CMake | CMake | public | 2008-12-08 17:22 | 2008-12-17 09:25 | ||||
Reporter | jlblanco | ||||||||
Assigned To | Brad King | ||||||||
Priority | normal | Severity | feature | Reproducibility | N/A | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | CMake-2-6 | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0008264: PATCH: FindPackage searches in ${ProgramFiles}/name* | ||||||||
Description | I 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. ... =========================================================================== | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | find_package_progfiles.patch [^] (3,938 bytes) 2008-12-08 17:22 [Show Content] | ||||||||
Relationships | |
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 |
Notes |
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 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |