[cmake-developers] User vs CMake include mismatch handling

Marcus D. Hanwell marcus.hanwell at kitware.com
Tue Oct 12 13:07:50 EDT 2010


2010/10/12 Alexander Neundorf <neundorf at kde.org>

> On Tuesday 12 October 2010, Marcus D. Hanwell wrote:
> > On Mon, Oct 11, 2010 at 5:00 PM, Alexander Neundorf <neundorf at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20101012/d1a6ddeb/attachment.html>


More information about the cmake-developers mailing list