[cmake-developers] User vs CMake include mismatch handling

Alexander Neundorf neundorf at kde.org
Tue Oct 12 13:38:10 EDT 2010


On Tuesday 12 October 2010, Marcus D. Hanwell wrote:
> 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.

Ok. So setting CMP0017 to NEW in FindKDE4.cmake would not help Avogadro, and 
KDE4 is not the only project which breaks together with current cmake 2.8.3.

This reduces the number of acceptable solutions I think.

Remaining are as far as I see:

-set new policy CMP0017 to NEW by default
Projects with an exotic setup may break, but that's probably better than
breaking all KDE 4.5.0/1 builds. One could also argue that these projects 
relied on internal implementation details of cmake. As a pro, I think this 
behaviour (include()s from CMAKE_ROOT first check in CMAKE_ROOT) makes sense, 
since we have that dependency but currently it's not enforced.

-hardcode the path to FPHSA.cmake in the find-modules in cmake, probably also 
to CMakeParseArguments.cmake and FindPackageMessage.cmake
IMO not a solution, just a quick fix for the moment, because we have to 
maintain this forever in the future and basically we need to check *all* 
other include()s in CMAKE_ROOT.

-rename the enhanced FPHSA to FPHSA2
Worse than above, since this doesn't give any guarantee that the same does not 
happen again in the next cmake release with the renamed function.


Did I miss anything ?

Alex



More information about the cmake-developers mailing list