[cmake-developers] [CMake 0011301]: FindQt4.cmake: ability to use a new default dir in Qt 4.7: qml imports
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11301 == Reported By:Marco Martin Assigned To: == Project:CMake Issue ID: 11301 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2010-10-07 15:13 EDT Last Modified: 2010-10-07 15:13 EDT == Summary:FindQt4.cmake: ability to use a new default dir in Qt 4.7: qml imports Description: Since Qt 4.7.0 Qt has a new standard directory, is called "imports" and contains plugins for the QML declarative language. So should be possible to install files in it. since FindQt4.cmake is shared between KDE and upstrea cmake i'm reporting the issue also there. a proposed patch is at http://svn.reviewboard.kde.org/r/5541/ == Issue History Date ModifiedUsername FieldChange == 2010-10-07 15:13 Marco Martin 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 Wednesday 06 October 2010, David Cole wrote:
> The really robust solution here is the simple one.
>
> It is to implement CMAKE_CURRENT_LIST_DIR and for files that must
> explicitly reference a file "in the same directory as me", use that
> explicitly.
>
> Otherwise, behavior is exactly the same as it is now.
>
> Explicit reference to the file you mean is the only guaranteed way to get
> the file you mean.
This basically means that each include() and find_package() in CMAKE_ROOT has
to use ${CMAKE_CURRENT_LIST_DIR} to make sure it gets the file from
CMAKE_ROOT.
This are 398 places in CMAKE_ROOT which have to be looked at and modified
accordingly.
That's what we get automatically and future-proof with the patch.
> Anything else is a guess and will be wrong some of the time.
No.
Speaking as CMake developer: I would expect that when I do include(SomeFile)
in a file in CMAKE_ROOT in cmake version x.y.z, that I can use all features
of SomeFile.cmake of this release.
Is this a guarantee we want to provide ?
I always assumed this. Otherwise I cannot safely use any feature which has
been added to SomeModule.cmake after its initial release, because some
project may have an own copy of that file from its initial release.
If we want to ensure this, then cmake has to prefer CMAKE_ROOT over
CMAKE_MODULE_PATH when include()/find_package() is called from inside
CMAKE_ROOT.
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011296]: FindwxWidget.cmake prevents from cross compiling for Windows under Linux
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=11296 == Reported By:Florent Teichteil Assigned To: == Project:CMake Issue ID: 11296 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2010-10-07 03:47 EDT Last Modified: 2010-10-07 03:47 EDT == Summary:FindwxWidget.cmake prevents from cross compiling for Windows under Linux Description: Hi all, There is a bug in the cmake module FindwxWidgets.cmake that prevents any library using wxWidgets to cross compile for Windows from Linux. Please note that this bug is different from issue http://www.cmake.org/Bug/view.php?id=6187. Lines 192 to 198 are concerned by the present bug: IF(WIN32 AND NOT CYGWIN AND NOT MSYS) SET(wxWidgets_FIND_STYLE "win32") ELSE(WIN32 AND NOT CYGWIN AND NOT MSYS) IF(UNIX OR MSYS) SET(wxWidgets_FIND_STYLE "unix") ENDIF(UNIX OR MSYS) ENDIF(WIN32 AND NOT CYGWIN AND NOT MSYS) The problem is that, when cross compiling from Linux for Windows, the test "WIN32 AND NOT CYGWIN AND NOT MSYS" is true but find style should be "unix", because the Windows-based wxWidget library is installed in a unix environment. Therefore, the following line replacement corrects this bug: IF(WIN32 AND NOT CYGWIN AND NOT MSYS AND NOT CMAKE_CROSSCOMPILING) SET(wxWidgets_FIND_STYLE "win32") ELSE(WIN32 AND NOT CYGWIN AND NOT MSYS AND NOT CMAKE_CROSSCOMPILING) IF(UNIX OR MSYS OR CMAKE_CROSSCOMPILING) SET(wxWidgets_FIND_STYLE "unix") ENDIF(UNIX OR MSYS OR CMAKE_CROSSCOMPILING) ENDIF(WIN32 AND NOT CYGWIN AND NOT MSYS AND NOT CMAKE_CROSSCOMPILING) The modified FindwxWidget.cmake module runs fine with the following toolchain cmake file: SET(CMAKE_SYSTEM_NAME Windows) SET(CMAKE_C_COMPILER /usr/bin/i686-pc-mingw32-gcc) SET(CMAKE_CXX_COMPILER /usr/bin/i686-pc-mingw32-g++) SET(CMAKE_FIND_ROOT_PATH /usr/i686-pc-mingw32) SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH) SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) Could this "patch" be applied in cmake svn, please? All the best, Florent == Issue History Date ModifiedUsername FieldChange == 2010-10-07 03:47 Florent TeichteilNew Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
