[cmake-developers] User vs CMake include mismatch handling

[Marcus D. Hanwell]

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

> 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.
>

Yes, that is correct. I think it is hard to assess which projects might be
broken after release that have not tried an rc. I would not be surprised if
quite a few out there might break.

>
> 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.
>

I would tend to agree with you there.

>
> -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.
>

Agreed.

>
> -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.
>
> I think this is the simplest, but I can see why you would rather avoid it.

>
> Did I miss anything ?
>
> I don't think so. I would go with option 1 or 3. Effectively the policy
would be the reverse of most though, and so very confusing - setting it to
OLD is more likely to cause breakage than setting it to NEW. This would mean
that the standard documentation would not really apply well to this one
policy, and it could cause a lot of confusion.

I wonder if Brad or Bill have any thoughts on this?

Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20101012/3d15d7b2/attachment.html>