Notes
(0004745) Brad King (manager) 2006-08-25 10:03	I'm assinging this bug to myself since I plan to eventually implement the changes.

(0004746) Brad King (manager) 2006-08-25 10:03	Below is a log of email discussion and some of my notes for this topic. ------------------------------------------------ FIND_PACKAGE(QtDBUS PATH_SUFFIXES lib/QtDBUS ) # CMAKE_PACKAGE_PATH # CMAKE_PREFIX_PATH Also should support using pkgconfig to find packages. -------- Original Message -------- Subject: Re: [cmake-developers] the future of FIND_PACKAGE() Date: Tue, 27 Jun 2006 19:59:56 +0200 From: Alexander Neundorf <neundorf@kde.org> Reply-To: neundorf@kde.org To: cmake-developers@cmake.org References: <4499A362.5030909@kitware.com> <200606262319.11621.neundorf@kde.org> <44A145D7.6030606@kitware.com> On Tuesday 27 June 2006 16:51, you wrote: > > Alexander Neundorf wrote: ... > > / > > /usr > > /usr/local > > /opt/* > > > > will cover most system installations for most distributions. If a > > sysadmin or distro adds more prefixes it can put them in a > > CMAKE_PREFIX_PATH environment variable in /etc/profile for all users to > > see. Similarly if users prefixes in their home directories they are > > responsible for putting the prefix in CMAKE_PREFIX_PATH just like > > ~/myroot/bin would have to be put in PATH or ~/myroot/lib in > > LD_LIBRARY_PATH. We could also consider guessing prefixes from PATH and > > LD_LIBRARY_PATH environment varibles. > > > > On Windows, %ProgramFiles% and the system registry may provide a > > sufficient set of prefixes. > > > > Anyway the point is that CMake should be able to find Foo without Foo > > finding CMake. Although I wouldn't see a problem with this, ok (for stuff coming with the distro it's no problem, for stuff compiled itself with cmake, it's also no problem). So I think the FooConfig.cmake files should go under lib/ (since they can be quite specific) and not under share/. Leaves the following options: lib/Foo/cmake/ lib/cmake/Foo/ pkgconfig basically uses the second form. In order to minimize confusion, CMake should IMO support only one of these two locations. It should also define exactly the case to be used: "cmake" vs. "CMake". The FIND_PACKAGE() documentation also mentions a version number, maybe this could be used as suffix for the subdir name: and with version numbers: lib/Foo-x.y.z/cmake/ lib/cmake/Foo-x.y.z/ As prefixes I'd suggest to reuse the variables which are used for FIND_LIBRARY(). I think introducing more variables should be avoided, it's hard to remember them. Reusing the ones from FIND_LIBRARY() would also make sense because the FooConfig.cmake files will usually be installed under lib/ directory (where also the library itself will be located). Also the install prefix of cmake itself should be used (i.e. if cmake is installed in a strange location, it will find other stuff installed to the same strange location too). So, which one should be prefered, FindFoo.cmake or FooConfig.cmake if both can be found by cmake ? I'd say FooConfig.cmake, since this is provided by the project and should be more up-to-date/complete/bug fixed/ etc. How about adding a PATHS argument to FIND_PACKAGE() as there is for all other FIND_XXX() commands ? Bye Alex -- Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de [^] Home: neundorf AT kde.org - http://www.kde.org [^] alex AT neundorf.net - http://www.neundorf.net [^] _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers [^] -------- Original Message -------- Subject: FIND_PACKAGE changes Date: Wed, 21 Jun 2006 15:52:02 -0400 From: Brad King <brad.king@kitware.com> To: Alexander Neundorf <neundorf@kde.org> CC: Bill Hoffman <bill.hoffman@kitware.com> Alex, The CMake devs have discussed the FIND_PACKAGE situation. The Foo_DIR version of FIND_PACKAGE(Foo) is the answer for cmake-aware projects. Since Foo is cmake-aware we do not need a full FindFoo.cmake script. Instead Foo should install a FooConfig.cmake file somewhere that FIND_PACKAGE can locate it. What we need is for FIND_PACKAGE to do a better job of locating FooConfig.cmake than it does currently. I propose the following steps for FIND_PACKAGE(Foo): 1.) Search CMAKE_MODULE_PATH for FindFoo.cmake. If it is found load it, otherwise continue. This is already working. 2.) Create a Foo_DIR cache entry that is documented as the location of a FooConfig.cmake file. This is already working, but the next steps do a better job of finding it automatically. 3.) Choose a set of installation prefixes to be searched for the package. This would come from a combination of environment variables, cmake variables, and command arguments just like the other FIND_* commands. The locations may also come from registry entries like [HKEY_CURRENT_USER\Software\\Foo;InstallDir] [HKEY_CURRENT_USER\Software\\\Foo;InstallDir] [HKEY_LOCAL_MACHINE\Software\\Foo;InstallDir] [HKEY_LOCAL_MACHINE\Software\\\Foo;InstallDir] 4.) Search under each prefix for FooConfig.cmake using the following search locations: PREFIX/ (useful on windows) PREFIX/(cmake\|CMake)/ (useful on windows) PREFIX/(share\|lib)/(Foo\|foo\|FOO)./ PREFIX/(share\|lib)/(Foo\|foo\|FOO)./(cmake\|CMake)/ PREFIX/(share\|lib)/(cmake\|CMake)/(Foo\|foo\|FOO).*/ A set of PATH_SUFFIXES given in call to FIND_PACKAGE Using the share/cmake path will avoid your concern about cluttering the share folder just for one file per project. Using the share/Foo/cmake path will allow projects that already have a share directory to keep their files together. 5.) When FooConfig.cmake is found, Foo_DIR will contain its locaiton. Load the script. Since FooConfig.cmake was installed by the project and it knows where it installed it with respecto to the installation prefix, it can compute relative paths from Foo_DIR to locate everything else without a hard-coded install prefix. This search scheme will give packages quite a bit of flexibility about where they want to install their FooConfig.cmake. For QTDBUS you could install QTDBUSConfig.cmake to something like "PREFIX/share/cmake/QTDBUS-4". The file would contain lines like ----------------------------------------------------------------- # Compute the installation prefix used to install this file. SET(QTDBUS_INSTALL_PREFIX "${QTDBUS_DIR}") GET_FILENAME_COMPONENT(QTDBUS_INSTALL_PREFIX "${QTDBUS_INSTALL_PREFIX}" PATH) # strip QTDBUS-4 GET_FILENAME_COMPONENT(QTDBUS_INSTALL_PREFIX "${QTDBUS_INSTALL_PREFIX}" PATH) # strip cmake GET_FILENAME_COMPONENT(QTDBUS_INSTALL_PREFIX "${QTDBUS_INSTALL_PREFIX}" PATH) # strip share # Compute locations relative to the installation prefix. SET(QTDBUS_INCLUDE_DIRS ${QTDBUS_INSTALL_PREFIX}/include) SET(QTDBUS_LIBRARY_DIRS ${QTDBUS_INSTALL_PREFIX}/lib) ----------------------------------------------------------------- Then other projects would need just find_package(QTDBUS) to find the package and will not need any Find script at all. If the package is not found automatically, the user need set only one variable (QTDBUS_DIR) to fix the problem. Comments? -Brad

(0004747) Brad King (manager) 2006-08-25 10:04	Here are the notes again with newlines. =============================================== Subject: FIND_PACKAGE changes Date: Wed, 21 Jun 2006 15:52:02 -0400 From: Brad King <brad.king@kitware.com> To: Alexander Neundorf <neundorf@kde.org> CC: Bill Hoffman <bill.hoffman@kitware.com> Alex, The CMake devs have discussed the FIND_PACKAGE situation. The Foo_DIR version of FIND_PACKAGE(Foo) is the answer for cmake-aware projects. Since Foo is cmake-aware we do not need a full FindFoo.cmake script. Instead Foo should install a FooConfig.cmake file somewhere that FIND_PACKAGE can locate it. What we need is for FIND_PACKAGE to do a better job of locating FooConfig.cmake than it does currently. I propose the following steps for FIND_PACKAGE(Foo): 1.) Search CMAKE_MODULE_PATH for FindFoo.cmake. If it is found load it, otherwise continue. This is already working. 2.) Create a Foo_DIR cache entry that is documented as the location of a FooConfig.cmake file. This is already working, but the next steps do a better job of finding it automatically. 3.) Choose a set of installation prefixes to be searched for the package. This would come from a combination of environment variables, cmake variables, and command arguments just like the other FIND_* commands. The locations may also come from registry entries like [HKEY_CURRENT_USER\Software\\Foo;InstallDir] [HKEY_CURRENT_USER\Software\\\Foo;InstallDir] [HKEY_LOCAL_MACHINE\Software\\Foo;InstallDir] [HKEY_LOCAL_MACHINE\Software\\\Foo;InstallDir] 4.) Search under each prefix for FooConfig.cmake using the following search locations: PREFIX/ (useful on windows) PREFIX/(cmake\|CMake)/ (useful on windows) PREFIX/(share\|lib)/(Foo\|foo\|FOO)./ PREFIX/(share\|lib)/(Foo\|foo\|FOO)./(cmake\|CMake)/ PREFIX/(share\|lib)/(cmake\|CMake)/(Foo\|foo\|FOO).*/ A set of PATH_SUFFIXES given in call to FIND_PACKAGE Using the share/cmake path will avoid your concern about cluttering the share folder just for one file per project. Using the share/Foo/cmake path will allow projects that already have a share directory to keep their files together. 5.) When FooConfig.cmake is found, Foo_DIR will contain its locaiton. Load the script. Since FooConfig.cmake was installed by the project and it knows where it installed it with respecto to the installation prefix, it can compute relative paths from Foo_DIR to locate everything else without a hard-coded install prefix. This search scheme will give packages quite a bit of flexibility about where they want to install their FooConfig.cmake. For QTDBUS you could install QTDBUSConfig.cmake to something like "PREFIX/share/cmake/QTDBUS-4". The file would contain lines like ----------------------------------------------------------------- # Compute the installation prefix used to install this file. SET(QTDBUS_INSTALL_PREFIX "${QTDBUS_DIR}") GET_FILENAME_COMPONENT(QTDBUS_INSTALL_PREFIX "${QTDBUS_INSTALL_PREFIX}" PATH) # strip QTDBUS-4 GET_FILENAME_COMPONENT(QTDBUS_INSTALL_PREFIX "${QTDBUS_INSTALL_PREFIX}" PATH) # strip cmake GET_FILENAME_COMPONENT(QTDBUS_INSTALL_PREFIX "${QTDBUS_INSTALL_PREFIX}" PATH) # strip share # Compute locations relative to the installation prefix. SET(QTDBUS_INCLUDE_DIRS ${QTDBUS_INSTALL_PREFIX}/include) SET(QTDBUS_LIBRARY_DIRS ${QTDBUS_INSTALL_PREFIX}/lib) ----------------------------------------------------------------- Then other projects would need just find_package(QTDBUS) to find the package and will not need any Find script at all. If the package is not found automatically, the user need set only one variable (QTDBUS_DIR) to fix the problem. Comments? -Brad

(0004777) Alex Neundorf (developer) 2006-08-27 11:23	For us (KDE) this is currently not urgent anymore, since now QtDBUS comes with Qt 4.2 and so it is enough to find Qt. Maybe what we do with KDE is really the best way: have a small "FindFoo.cmake" in cmake itself, which loads the full cmake file, which comes with the project (FindKDE4Internal.cmake).

(0006026) Artur Kedzierski (reporter) 2006-12-20 11:45	The order of search should probably be different. The FooConfig.cmake should be preferred over FindFoo.cmake. The reason for it is that FooConfig.cmake comes with a package and has an accurate information on its usage. On the other hand, FooConfig.cmake tries to figure out such information so it is less accurate.

(0008094) Alex Neundorf (developer) 2007-07-18 10:26	I think share/ shouldn't be searched, the FooConfig.cmake files are probably not usable for other platforms. PREFIX/ (useful on windows) PREFIX/(cmake\|CMake)/ (useful on windows) PREFIX/lib/(Foo\|foo\|FOO)(-.+)?/ PREFIX/lib/(Foo\|foo\|FOO)(-.+)?/(cmake\|CMake)/ Not sure about this one, is an alternative location really required, doesn't it only make things more complicated ? PREFIX/lib/(cmake\|CMake)/(Foo\|foo\|FOO)(-.+)?/ A set of PATH_SUFFIXES given in call to FIND_PACKAGE

(0010167) Brad King (manager) 2008-01-17 09:07	I've now implemented FIND_PACKAGE command enhancements based on the discussion above: /cvsroot/CMake/CMake/Source/cmBootstrapCommands.cxx,v <-- cmBootstrapCommands.cxx new revision: 1.20; previous revision: 1.19 /cvsroot/CMake/CMake/Source/cmFindBase.cxx,v <-- cmFindBase.cxx new revision: 1.32; previous revision: 1.31 /cvsroot/CMake/CMake/Source/cmFindBase.h,v <-- cmFindBase.h new revision: 1.13; previous revision: 1.12 /cvsroot/CMake/CMake/Source/cmFindCommon.cxx,v <-- cmFindCommon.cxx initial revision: 1.1 /cvsroot/CMake/CMake/Source/cmFindCommon.h,v <-- cmFindCommon.h initial revision: 1.1 /cvsroot/CMake/CMake/Source/cmFindLibraryCommand.cxx,v <-- cmFindLibraryCommand.cxx new revision: 1.46; previous revision: 1.45 /cvsroot/CMake/CMake/Source/cmFindPackageCommand.cxx,v <-- cmFindPackageCommand.cxx new revision: 1.27; previous revision: 1.26 /cvsroot/CMake/CMake/Source/cmFindPackageCommand.h,v <-- cmFindPackageCommand.h new revision: 1.16; previous revision: 1.15 /cvsroot/CMake/CMake/Source/cmFindPathCommand.cxx,v <-- cmFindPathCommand.cxx new revision: 1.38; previous revision: 1.37 /cvsroot/CMake/CMake/Source/cmFindProgramCommand.cxx,v <-- cmFindProgramCommand.cxx new revision: 1.41; previous revision: 1.40 I also updated the FindPackageTest to test it: /cvsroot/CMake/CMake/Tests/FindPackageTest/CMakeLists.txt,v <-- CMakeLists.txt new revision: 1.6; previous revision: 1.5 /cvsroot/CMake/CMake/Tests/FindPackageTest/TApp.app/Contents/Resources/TAppConfig.cmake,v <-- TAppConfig.cmake initial revision: 1.1 /cvsroot/CMake/CMake/Tests/FindPackageTest/TApp.app/Contents/Resources/cmake/tapp-config.cmake,v <-- tapp-config.cmake initial revision: 1.1 /cvsroot/CMake/CMake/Tests/FindPackageTest/TFramework.framework/Versions/A/Resources/tframework-config.cmake,v <-- tframework-config.cmake initial revision: 1.1 /cvsroot/CMake/CMake/Tests/FindPackageTest/TFramework.framework/Versions/A/Resources/CMake/TFrameworkConfig.cmake,v <-- TFrameworkConfig.cmake initial revision: 1.1 /cvsroot/CMake/CMake/Tests/FindPackageTest/lib/Bar/BarConfig.cmake,v <-- BarConfig.cmake initial revision: 1.1 /cvsroot/CMake/CMake/Tests/FindPackageTest/lib/Bar/cmake/bar-config.cmake,v <-- bar-config.cmake initial revision: 1.1 /cvsroot/CMake/CMake/Tests/FindPackageTest/lib/TApp/TAppConfig.cmake,v <-- TAppConfig.cmake initial revision: 1.1 /cvsroot/CMake/CMake/Tests/FindPackageTest/lib/foo-1.2/foo-config.cmake,v <-- foo-config.cmake initial revision: 1.1 /cvsroot/CMake/CMake/Tests/FindPackageTest/lib/foo-1.2/CMake/FooConfig.cmake,v <-- FooConfig.cmake initial revision: 1.1 /cvsroot/CMake/CMake/Tests/FindPackageTest/lib/suffix/test/SuffixTestConfig.cmake,v <-- SuffixTestConfig.cmake initial revision: 1.1

Issue History
Date Modified	Username	Field	Change
2008-01-17 09:07	Brad King	Note Added: 0010167
2008-01-17 09:12	Brad King	Status	assigned => closed
2008-01-17 09:12	Brad King	Resolution	open => fixed

Relationships