2010/10/12 Alexander Neundorf <neund...@kde.org> > On Tuesday 12 October 2010, Marcus D. Hanwell wrote: > > On Mon, Oct 11, 2010 at 5:00 PM, Alexander Neundorf <neund...@kde.org > >wrote: > ... > > > Personally, I would try a rc3 with CMP0017 set to NEW and see how it > > > goes. It works for kdelibs and for our project at work (which doesn't > > > have a lot of > > > fancy cmake stuff). > > > > > If it is just that one file why not go with the simple solution? I would > > love to see a policy where includes in the same directory would be > > considered first, and then the normal search behavior. I wasn't sure how > > feasible this was in an rc3. Avogadro effectively copied what KDE was > > doing, and so maybe the issue is not that widespread. > > I don't have the avogadro sources here. > What does it do, i.e. what did it copy from KDE ? > Does it a > find_package(KDE4) ? > > Or does it include its own version of FindPackageHandleStandardArgs.cmake ? > > It has its own copy of FindPackageHandleStandardArgs.cmake, which is used in some of the Find modules. Avogadro is a dependency of Kalzium (KDE Edu), but is C++/Qt based itself. I was more thinking of all the other packages out there that may have done similar, and the fact that we should avoid breaking their builds with a new CMake release.
It is on Github/Gitorious if you want to clone it, but the problem stems from its use of FindPackageHandleStandardArgs.cmake in its own modules, including a copy for them, and setting CMAKE_MODULE_PATH so that the find modules are all correctly used. Marcus
_______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
