hi brad, ok, the changes you are proposing sound exciting! perhaps this can be a start for a truly cross platform package management system ;0)
so is the best approach for now to create a minimal FindOpenRAVE.cmake to give to user, and put FindOpenRAVEConfig.cmake in $installprefix/lib/cmake/? rosen, 2011/4/13 Brad King <[email protected]>: > On 04/12/2011 08:02 PM, Rosen Diankov wrote: >> Perhaps I missed something, but FindX.cmake packages will look for >> that, while the configuration method you are suggesting will not. > > Correct. I've been meaning to address this for a long time. > >> It would be great if find_package also searches the registry keys for >> the install root. > > Yes. There is a TODO comment in the source code for this: > > http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFindPackageCommand.cxx;hb=v2.8.4#l2281 > > One reason it was not done originally is that I did not want to have to > search every vendor's registry namespace for packages. Since then however > I did add this: > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed0650f6 > > in order to work together with this: > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=16ce84b0 > > I think this design can be generalized to allow installation tools to > add entries. See below. > >> If cmake does not do that, then as you said, OpenRAVE users will >> still have to copy a small script in order to set the HINTS and PATHS >> variables to find_package. And most likely this script will be called >> FindOpenRAVEConfig.cmake (which will be small and call >> find_package(OpenRAVE) to search for the configuration files). > > It will still be called "FindOpenRAVE.cmake". The application writer > should not have to know how the package is found. The command > > find_package(OpenRAVE) > > will use FindOpenRAVE.cmake if it exists in the CMAKE_MODULE_PATH. > That module is then free to do > > find_package(OpenRAVE NO_MODULE) > > to look for OpenRAVEConfig.cmake. > >> Therefore, it would be great if FindOpenRAVEConfig.cmake was part of >> the cmake distributions so that users won't have to copy it.... > > Since you'd have to wait for a new CMake for this anyway, I'd rather just > solve the main problem. I think this is the prod I needed to try it. > I'll take a look at generalizing the user package registry and get back > to you. > > -Brad > _______________________________________________ cmake-developers mailing list [email protected] http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
