<div class="gmail_quote">On Mon, Oct 11, 2010 at 5:00 PM, Alexander Neundorf <span dir="ltr"><<a href="mailto:neundorf@kde.org">neundorf@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Monday 11 October 2010, Marcus D. Hanwell wrote:<br>
> On Sunday 10 October 2010 14:56:29 Alexander Neundorf wrote:<br>
</div>...<br>
<div class="im">> So is there no chance of fixing this in a backward compatible way? One of<br>
<br>
</div>Prefering module in CMAKE_ROOT when include() or find_package() is called from<br>
CMAKE_ROOT (which does have the potential to break existing builds, but those<br>
projects must have a weird setup I think).<br></blockquote><div><br></div><div>Sounds reasonable to me, although I know other options were floated. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
> the projects I work on has been bitten by this too, and so I guess the old,<br>
> released versions are doomed to fail with CMake 2.8.3 with the current<br>
> solution. This seems like quite a regression, and something the policies<br>
> were supposed to avoid (old projects failing with new CMake versions).<br>
<br>
</div>Hmm, this would mean that the module which uses FPHSA() would have to check<br>
how the new policy is set and depending on this call FPHSA() with the old or<br>
the new enhanced syntax. That's also ugly I think, and worse than using<br>
include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)<br>
<br>
This would fix the current problem, but IMO this is not a real solution, since<br>
it can break also for other modules, and then this hardcoded path must be<br>
used also in the future in all find-modules.<br>
I think prefering the modules from CMAKE_ROOT when included from CMAKE_ROOT is<br>
the right thing to do. This expresses the dependency we have (from cmake<br>
modules to the other current cmake modules in CMAKE_ROOT).<br></blockquote><div><br></div><div>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. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> I tested your topic branch with this project, and it still fails with the<br>
<br>
</div>You should get the policy warning about CMP0017.<br>
Is that the case ?<br>
<div class="im"><br></div></blockquote><div>I saw lots of warnings about CMP0017.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> following error,<br>
><br>
> CMake Error at cmake/modules/FindPackageHandleStandardArgs.cmake:53<br>
> (MESSAGE): REQUIRED_VARS<br>
> Call Stack (most recent call first):<br>
>   /usr/local/share/cmake-2.8/Modules/FindZLIB.cmake:70<br>
> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)<br>
>   CMakeLists.txt:234 (find_package)<br>
<br>
</div>I see the following options:<br>
* set policy 0017 to NEW behaviour by default (is that possible ?)</blockquote><div><br></div><div>I guess this is aimed at someone else, it would be the first I think if it is possible. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
 </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
* set policy 0017 to NEW behaviour somewhere locally. What project is<br>
failing ?<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
* hardcode ${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake<br>
instead of just using include(FindPackageHandleStandardArgs), problems see<br>
above<br>
* revert the enhanced syntax :-( or put it into a file<br>
FindPackageHandleStandardArgs2.cmake (but the same can happen later on<br>
again) :-/<br>
<br></blockquote><div>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.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
Personally, I would try a rc3 with CMP0017 set to NEW and see how it goes.<br>
It works for kdelibs and for our project at work (which doesn't have a lot of<br>
fancy cmake stuff).<br><br></blockquote><div>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.</div>
<div><br></div><div>Until now setting a minimum CMake version has always been enough, I would hate for that to change.</div><div><br></div><div>Marcus</div></div>