On Mon, Oct 11, 2010 at 5:00 PM, Alexander Neundorf <neund...@kde.org>wrote:
> On Monday 11 October 2010, Marcus D. Hanwell wrote: > > On Sunday 10 October 2010 14:56:29 Alexander Neundorf wrote: > ... > > So is there no chance of fixing this in a backward compatible way? One of > > Prefering module in CMAKE_ROOT when include() or find_package() is called > from > CMAKE_ROOT (which does have the potential to break existing builds, but > those > projects must have a weird setup I think). > Sounds reasonable to me, although I know other options were floated. > > > the projects I work on has been bitten by this too, and so I guess the > old, > > released versions are doomed to fail with CMake 2.8.3 with the current > > solution. This seems like quite a regression, and something the policies > > were supposed to avoid (old projects failing with new CMake versions). > > Hmm, this would mean that the module which uses FPHSA() would have to check > how the new policy is set and depending on this call FPHSA() with the old > or > the new enhanced syntax. That's also ugly I think, and worse than using > include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) > > This would fix the current problem, but IMO this is not a real solution, > since > it can break also for other modules, and then this hardcoded path must be > used also in the future in all find-modules. > I think prefering the modules from CMAKE_ROOT when included from CMAKE_ROOT > is > the right thing to do. This expresses the dependency we have (from cmake > modules to the other current cmake modules in CMAKE_ROOT). > It seems like a reasonable approach to generally prefer the .cmake files in the same directory, before all others. I am not a core CMake developer though, and defer to them on issues like this. I think whatever is done should ensure old projects continue to build, even if new warnings are issues. > > > I tested your topic branch with this project, and it still fails with the > > You should get the policy warning about CMP0017. > Is that the case ? > > I saw lots of warnings about CMP0017. > > following error, > > > > CMake Error at cmake/modules/FindPackageHandleStandardArgs.cmake:53 > > (MESSAGE): REQUIRED_VARS > > Call Stack (most recent call first): > > /usr/local/share/cmake-2.8/Modules/FindZLIB.cmake:70 > > (FIND_PACKAGE_HANDLE_STANDARD_ARGS) > > CMakeLists.txt:234 (find_package) > > I see the following options: > * set policy 0017 to NEW behaviour by default (is that possible ?) I guess this is aimed at someone else, it would be the first I think if it is possible. > * set policy 0017 to NEW behaviour somewhere locally. What project is > failing ? > Avogadro. We can obviously make a new release with this corrected in a number of ways, but it would sidestep the issue that a new CMake release would be incompatible with a source tree that configured/compiled fine with CMake 2.8.2 and earlier. This seems like a major regression to me. Anything done locally doesn't help out when someone downloads this project, and I wonder how many other projects we don't know about might be affected by this issue. > * hardcode ${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake > instead of just using include(FindPackageHandleStandardArgs), problems see > above > * revert the enhanced syntax :-( or put it into a file > FindPackageHandleStandardArgs2.cmake (but the same can happen later on > again) :-/ > > Putting it in a FindPackageHandleStandardArgs2.cmake while not ideal seems like one of the better solutions. I agree that it does not fix the problem very elegantly. > > 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. Until now setting a minimum CMake version has always been enough, I would hate for that to change. Marcus
_______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers