Re: [cmake-developers] User vs CMake include mismatch handling
On Sunday 10 October 2010 14:56:29 Alexander Neundorf wrote: On Friday 08 October 2010, David Cole wrote: On Fri, Oct 8, 2010 at 10:59 AM, Alexander Neundorf neund...@kde.orgwrote: ... Better idea: I'll add a policy which switches this behaviour (prefer CMAKE_ROOT over CMAKE_MODULE_PATH when used from within CMAKE_ROOT), and this policy will, as all other policies, default to the old behaviour, but warn. ... This latest idea does sound better, but I am still not a fan of invisible / magic behavior. I much prefer when things are explicitly spelled out. There is now a branch PreferCMakeModulesByCMakeModulesWithPolicy on staging. It includes this patch, a new policy CMP0017, and a basic test for it. I also verified that this fixes the KDE 4.5 problem. With KDE 4.5.0/4.5.1 there are now a lot of these new CMP0017 warnings, and in the end stuff has not been found which should have been found. Should I handle setting CMP0017 to NEW in kdelibs (- cmake 2.8.3 will not be able to build KDE 4.5.0/1, but complain loud) or in CMake/Modules/FindKDE4.cmake (then cmake 2.8.3 will be able to build KDE 4.5.0/1) ? So is there no chance of fixing this in a backward compatible way? One of the projects I work on has been bitten by this too, and so I guess the old, released versions are doomed to fail with CMake 2.8.3 with the current solution. This seems like quite a regression, and something the policies were supposed to avoid (old projects failing with new CMake versions). I tested your topic branch with this project, and it still fails with the following error, CMake Error at cmake/modules/FindPackageHandleStandardArgs.cmake:53 (MESSAGE): REQUIRED_VARS Call Stack (most recent call first): /usr/local/share/cmake-2.8/Modules/FindZLIB.cmake:70 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:234 (find_package) Marcus ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS Plugin in 2.8.3
On 10/11/2010 02:54 PM, Brad King wrote: I just tested it with the COnly test and VS9 x64. It now reloads even when the project has not changed at all (touch CMakeLists.txt). I wonder if the project solution folder feature affected this. It happens when the USE_FOLDERS property is on. The bug was recently hidden by the change to make this off by default. It looks like the GUID for the solution folder names is not cached across runs. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS Plugin in 2.8.3
On Mon, Oct 11, 2010 at 2:37 PM, Brad King brad.k...@kitware.com wrote: On 10/11/2010 02:54 PM, Brad King wrote: I just tested it with the COnly test and VS9 x64. It now reloads even when the project has not changed at all (touch CMakeLists.txt). I wonder if the project solution folder feature affected this. It happens when the USE_FOLDERS property is on. The bug was recently hidden by the change to make this off by default. It looks like the GUID for the solution folder names is not cached across runs. -Brad I'm glad you found the problem! ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] User vs CMake include mismatch handling
On Monday 11 October 2010, Marcus D. Hanwell wrote:
On Sunday 10 October 2010 14:56:29 Alexander Neundorf wrote:
...
So is there no chance of fixing this in a backward compatible way? One of
Prefering module in CMAKE_ROOT when include() or find_package() is called from
CMAKE_ROOT (which does have the potential to break existing builds, but those
projects must have a weird setup I think).
the projects I work on has been bitten by this too, and so I guess the old,
released versions are doomed to fail with CMake 2.8.3 with the current
solution. This seems like quite a regression, and something the policies
were supposed to avoid (old projects failing with new CMake versions).
Hmm, this would mean that the module which uses FPHSA() would have to check
how the new policy is set and depending on this call FPHSA() with the old or
the new enhanced syntax. That's also ugly I think, and worse than using
include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
This would fix the current problem, but IMO this is not a real solution, since
it can break also for other modules, and then this hardcoded path must be
used also in the future in all find-modules.
I think prefering the modules from CMAKE_ROOT when included from CMAKE_ROOT is
the right thing to do. This expresses the dependency we have (from cmake
modules to the other current cmake modules in CMAKE_ROOT).
I tested your topic branch with this project, and it still fails with the
You should get the policy warning about CMP0017.
Is that the case ?
following error,
CMake Error at cmake/modules/FindPackageHandleStandardArgs.cmake:53
(MESSAGE): REQUIRED_VARS
Call Stack (most recent call first):
/usr/local/share/cmake-2.8/Modules/FindZLIB.cmake:70
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:234 (find_package)
I see the following options:
* set policy 0017 to NEW behaviour by default (is that possible ?)
* set policy 0017 to NEW behaviour somewhere locally. What project is
failing ?
* hardcode ${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake
instead of just using include(FindPackageHandleStandardArgs), problems see
above
* revert the enhanced syntax :-( or put it into a file
FindPackageHandleStandardArgs2.cmake (but the same can happen later on
again) :-/
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).
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] User vs CMake include mismatch handling
On Mon, Oct 11, 2010 at 5:00 PM, Alexander Neundorf neund...@kde.orgwrote:
On Monday 11 October 2010, Marcus D. Hanwell wrote:
On Sunday 10 October 2010 14:56:29 Alexander Neundorf wrote:
...
So is there no chance of fixing this in a backward compatible way? One of
Prefering module in CMAKE_ROOT when include() or find_package() is called
from
CMAKE_ROOT (which does have the potential to break existing builds, but
those
projects must have a weird setup I think).
Sounds reasonable to me, although I know other options were floated.
the projects I work on has been bitten by this too, and so I guess the
old,
released versions are doomed to fail with CMake 2.8.3 with the current
solution. This seems like quite a regression, and something the policies
were supposed to avoid (old projects failing with new CMake versions).
Hmm, this would mean that the module which uses FPHSA() would have to check
how the new policy is set and depending on this call FPHSA() with the old
or
the new enhanced syntax. That's also ugly I think, and worse than using
include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
This would fix the current problem, but IMO this is not a real solution,
since
it can break also for other modules, and then this hardcoded path must be
used also in the future in all find-modules.
I think prefering the modules from CMAKE_ROOT when included from CMAKE_ROOT
is
the right thing to do. This expresses the dependency we have (from cmake
modules to the other current cmake modules in CMAKE_ROOT).
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.
I tested your topic branch with this project, and it still fails with the
You should get the policy warning about CMP0017.
Is that the case ?
I saw lots of warnings about CMP0017.
following error,
CMake Error at cmake/modules/FindPackageHandleStandardArgs.cmake:53
(MESSAGE): REQUIRED_VARS
Call Stack (most recent call first):
/usr/local/share/cmake-2.8/Modules/FindZLIB.cmake:70
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:234 (find_package)
I see the following options:
* set policy 0017 to NEW behaviour by default (is that possible ?)
I guess this is aimed at someone else, it would be the first I think if it
is possible.
* set policy 0017 to NEW behaviour somewhere locally. What project is
failing ?
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.
* hardcode ${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake
instead of just using include(FindPackageHandleStandardArgs), problems see
above
* revert the enhanced syntax :-( or put it into a file
FindPackageHandleStandardArgs2.cmake (but the same can happen later on
again) :-/
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.
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.
Until now setting a minimum CMake version has always been enough, I would
hate for that to change.
Marcus
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
