<div class="gmail_quote">2010/10/12 Alexander Neundorf <span dir="ltr"><<a href="mailto:neundorf@kde.org">neundorf@kde.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tuesday 12 October 2010, Marcus D. Hanwell wrote:<br>
> 2010/10/12 Alexander Neundorf <<a href="mailto:neundorf@kde.org">neundorf@kde.org</a>><br>
><br>
> > On Tuesday 12 October 2010, Marcus D. Hanwell wrote:<br>
> > > On Mon, Oct 11, 2010 at 5:00 PM, Alexander Neundorf <<a href="mailto:neundorf@kde.org">neundorf@kde.org</a><br>
> > >wrote:<br>
> ><br>
> > ...<br>
> ><br>
> > > > Personally, I would try a rc3 with CMP0017 set to NEW and see how it<br>
> > > > goes. It works for kdelibs and for our project at work (which doesn't<br>
> > > > have a lot of<br>
> > > > fancy cmake stuff).<br>
> > ><br>
> > > If it is just that one file why not go with the simple solution? I<br>
> > > would love to see a policy where includes in the same directory would<br>
> > > be considered first, and then the normal search behavior. I wasn't sure<br>
> > > how feasible this was in an rc3. Avogadro effectively copied what KDE<br>
> > > was doing, and so maybe the issue is not that widespread.<br>
> ><br>
> > I don't have the avogadro sources here.<br>
> > What does it do, i.e. what did it copy from KDE ?<br>
> > Does it a<br>
> > find_package(KDE4) ?<br>
> ><br>
> > Or does it include its own version of FindPackageHandleStandardArgs.cmake<br>
> > ?<br>
> ><br>
<br>
> It has its own copy of FindPackageHandleStandardArgs.cmake, which is used<br>
> in some of the Find modules. Avogadro is a dependency of Kalzium (KDE Edu),<br>
> but is C++/Qt based itself. I was more thinking of all the other packages<br>
> out there that may have done similar, and the fact that we should avoid<br>
> breaking their builds with a new CMake release.<br>
<br>
</div>Ok. So setting CMP0017 to NEW in FindKDE4.cmake would not help Avogadro, and<br>
KDE4 is not the only project which breaks together with current cmake 2.8.3.<br>
<br>
This reduces the number of acceptable solutions I think.<br></blockquote><div><br></div><div>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. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Remaining are as far as I see:<br>
<br>
-set new policy CMP0017 to NEW by default<br>
Projects with an exotic setup may break, but that's probably better than<br>
breaking all KDE 4.5.0/1 builds. One could also argue that these projects<br>
relied on internal implementation details of cmake. As a pro, I think this<br>
behaviour (include()s from CMAKE_ROOT first check in CMAKE_ROOT) makes sense,<br>
since we have that dependency but currently it's not enforced.<br></blockquote><div><br></div><div>I would tend to agree with you there. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
-hardcode the path to FPHSA.cmake in the find-modules in cmake, probably also<br>
to CMakeParseArguments.cmake and FindPackageMessage.cmake<br>
IMO not a solution, just a quick fix for the moment, because we have to<br>
maintain this forever in the future and basically we need to check *all*<br>
other include()s in CMAKE_ROOT.<br></blockquote><div><br></div><div>Agreed. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
-rename the enhanced FPHSA to FPHSA2<br>
Worse than above, since this doesn't give any guarantee that the same does not<br>
happen again in the next cmake release with the renamed function.<br>
<br></blockquote><div>I think this is the simplest, but I can see why you would rather avoid it. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Did I miss anything ?<br><br></blockquote><div>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.</div>
<div><br></div><div>I wonder if Brad or Bill have any thoughts on this?</div><div><br></div><div>Marcus</div></div>