On Tuesday 28 September 2010, Brad King wrote: > On 09/28/2010 02:38 PM, Alexander Neundorf wrote: > > But it will always fail when a new version of cmake comes with a new > > version of Foo.cmake which it uses itself, and relies on the new > > features. If cmake then gets the older tweaked version from the project > > we have the problem. > > Okay, so modules must always include their dependencies from known > locations. If an outside project wants to override a Find module it should > also copy the dependencies too. > > > hammer:~/src/CMake/CMake-git/Modules$ grep FindPackageHandleSt *cmake |wc > > -l 86 > > > > IMO this would justify that new variable. > > (actually I wondered quite a few times since using cmake why such a > > CURRENT_LIST_FILE_DIR variable is missing, using GFC() always feels like > > using a clever trick instead of doing the straightforward thing). > > Okay. Your patch looks good.
:-) Currently there are CMAKE_CURRENT_LIST_FILE and CMAKE_CURRENT_LIST_LINE. Should it be CMAKE_CURRENT_LIST_FILE_DIR or CMAKE_CURRENT_LIST_DIR ? Alex _______________________________________________ cmake-developers mailing list [email protected] http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
