[cmake-developers] User vs CMake include mismatch handling

[Marcus D. Hanwell]

On Mon, Oct 11, 2010 at 5:00 PM, Alexander Neundorf <neundorf at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20101011/1ea098e7/attachment.html>