Re: [cmake-developers] User vs CMake include mismatch handling
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. Me definitely too. But I think in this case it will actually be easier to understand with the new behaviour. I had to think twice to understand what happened: it went into CMAKE_ROOT, but from there due to CMAKE_MODULE_PATH magic ;-) again out of it. I also think the comparison to RPATH and LD_LIBRARY_PATH is a good one in this case, and all OSs do have an RPATH to express such dependencies (or equivalent, for Windows it's the current dir). Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011303]: CMake fails to detect Python X64 on Win64
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=11303 == Reported By:th3flyboy Assigned To: == Project:CMake Issue ID: 11303 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2010-10-08 12:57 EDT Last Modified: 2010-10-08 12:57 EDT == Summary:CMake fails to detect Python X64 on Win64 Description: CMake is encountering an issue which blocks the detection of Python x64 with Windows 64 bit with the following message: CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE): Could NOT find PythonLibs (missing: PYTHON_LIBRARIES PYTHON_INCLUDE_DIRS) Call Stack (most recent call first): C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindPythonLibs.cmake:102 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:88 (FIND_PACKAGE) == Issue History Date ModifiedUsername FieldChange == 2010-10-08 12:57 th3flyboy New Issue == ___ 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 Friday 08 October 2010, you 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. Another idea would be the following behaviour (also with a policy): if a file, which has been found via CMAKE_MODULE_PATH or CMAKE_ROOT, includes another files, it looks first in its own directory, then in CMAKE_MODULE_PATH, then in CMAKE_ROOT. This would result in the same new behaviour for files in CMAKE_ROOT, additionally it would also change the search order for files found via CMAKE_MODULE_PATH. So this would be a bigger, but maybe more consistent change from the current behaviour. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
