Re: [cmake-developers] [PATCH] New module: FindIce.cmake
On Thu, Aug 21, 2014 at 02:47:24PM +0200, Rolf Eike Beer wrote: Roger Leigh wrote: On Sun, Aug 17, 2014 at 05:22:38PM +0100, Roger Leigh wrote: On Sun, Aug 17, 2014 at 05:50:58PM +0200, Rolf Eike Beer wrote: Am Sonntag, 17. August 2014, 16:21:24 schrieb Roger Leigh: On Fri, Aug 15, 2014 at 12:31:17AM +0100, Roger Leigh wrote: OK. I'll have to read up on this and see what needs doing. In the meantime, I've attached a revised patch with all the above corrections included. Based on the comments made on my other FindXerces patch, I've updated this patch to also use current naming and usage conventions. I hope this is all OK with you. +if((MSVC_VERSION EQUAL 1400) OR (MSVC_VERSION GREATER 1400 AND MSVC_VERSION LESS 1500)) if((NOT MSVC_VERSION VERSION_LESS 1400 AND MSVC_VERSION LESS 1500) Thanks, I've fixed this now in the attached patch. One single line change to the patch attached, to add support for FreeBSD, which uses a different slice directory (unversioned share/Ice). Pushed, including some cleanups: -remove text in else(), endif() and so on (applies also to FindXerces) -if (...) else() can be if (NOT ...) -used elseif for MSVC version scanning, once you have found one version the other if's can't be true Please check if I have messed something up. I've looked through the changes for both files and I can't see any problems there. I tested FindXerces on Linux and MacOS and can't see any changes in behaviour. Likewise I tested FindIce on Linux, MacOS and Windows in a variety of different combinations of compiler and Ice versions and also didn't see any problems. I've pushed the cleanups into our local git repositories and they will be picked up by our automated jenkins CI testing; I'll have the results of that by Monday, but I wouldn't expect it to be any different from the manual testing I've already done. Many thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015101]: Imported libraries go out of scope after call to target_link_libraries().
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15101 == Reported By:Björn Piltz Assigned To: == Project:CMake Issue ID: 15101 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-08-22 08:29 EDT Last Modified: 2014-08-22 08:29 EDT == Summary:Imported libraries go out of scope after call to target_link_libraries(). Description: I have a project where module lib - a library - depends on Qt, so it calls find_package(Qt5 ...) and target_link_libraries(lib Qt5::Core). Later I call target_link_libraries(app lib). The cmake configure step runs through without problems, but the generate step halts with the message: Target app links to target Qt5::Core but the target was not found. Perhaps a find_package() call is missing for an IMPORTED target, or an ALIAS target is missing? According to the documentation the target Qt5::Core is out of scope for 'app' since app is not in a subdirectory of the directory where add_library(... IMPORTED) was made, but I would argue that this is a bug since the target was in scope when the call add_library(lib Qt5::Core) was made. This issue is not specific to Qt and I'm aware that it could be fixed on their side by calling add_library(... IMPORTED GLOBAL). I'm hoping it could be fixed on the cmake side, though. Steps to Reproduce: git clone https://github.com/bjornpiltz/cmake_bug.git cmake_bug mkdir work cd work cmake -DCMAKE_PREFIX_PATH=Qt5/lib/cmake/ ../cmake_bug/ Additional Information: This issue is platform independent. == Issue History Date ModifiedUsername FieldChange == 2014-08-22 08:29 Björn PiltzNew Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Review Request] Topic wxWidgets-cflags
On Fri, Aug 22, 2014 at 8:44 AM, Brad King brad.k...@kitware.com wrote:
On 08/21/2014 03:25 PM, Richard Shaw wrote:
So the string command should be something like:
string(REPLACE ; wxWidgets_CXX_FLAGS_str ${wxWidgets_CXX_FLAGS})
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${wxWidgets_CXX_FLAGS_str})
Yes, and followed by unset(wxWidgets_CXX_FLAGS_str) to clear the
variable to not present it to applications.
Ok, hopefully this is better. I'm reading up on git but I still fubmble
around a bit...
http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=8e702cabfb149d1c67af725a3952af7034a2981d
Thanks,
Richard
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Review Request] Topic wxWidgets-cflags
On 08/22/2014 10:02 AM, Richard Shaw wrote: Ok, hopefully this is better. I'm reading up on git but I still fubmble around a bit... http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=8e702cabfb149d1c67af725a3952af7034a2981d Good. Please rebase/rewrite the topic and force-push it back to the stage to get rid of the extra merges and make it one commit again. Also please follow up with a change to drop the MSG debugging macro that was left in there before. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Review Request] Topic wxWidgets-cflags
On Thu, Aug 21, 2014 at 2:21 PM, Brad King brad.k...@kitware.com wrote:
On 08/21/2014 02:30 PM, Richard Shaw wrote:
if (wxWidgets_CXX_FLAGS)
+# Flags are expected to be a string here, not a list.
+string(REPLACE ; wxWidgets_CXX_FLAGS ${wxWidgets_CXX_FLAGS})
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${wxWidgets_CXX_FLAGS})
Thanks. However, we shouldn't leak our local modification to the value
of wxWidgets_CXX_FLAGS, so the substitution should be done with the
result stored in a temporary local variable.
Also, please start the commit message in UsewxWidgets:
Ok, all updates have been incorporated, so I'm looking for an ACK to know
if it appears ready to push into next.
http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=e6fa6e60f6330ddf60294a0d9a6ed4cb3f27d4c4
Thanks,
Richard
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [Review request] FindwxWidgets: Improve path detection logic when cross-compiling.
Simple logic update to check if we're cross-compiling to determine if unix or win32 path find style should be used. FindwxWidgets: Improve path detection logic when cross-compiling. Thanks, Richard -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Review Request] Topic wxWidgets-cflags
On 08/22/2014 12:27 PM, Richard Shaw wrote: Ok, all updates have been incorporated, so I'm looking for an ACK Looks good, thanks. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Review request] FindwxWidgets: Improve path detection logic when cross-compiling.
On 08/22/2014 12:39 PM, Richard Shaw wrote: Simple logic update to check if we're cross-compiling to determine if unix or win32 path find style should be used. FindwxWidgets: Improve path detection logic when cross-compiling. [snip] +else(WIN32 AND NOT CYGWIN AND NOT MSYS AND NOT CMAKE_CROSSCOMPILING) + set(wxWidgets_FIND_STYLE unix) +endif(WIN32 AND NOT CYGWIN AND NOT MSYS AND NOT CMAKE_CROSSCOMPILING) Please use empty else() and endif(). Otherwise, looks good. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Review request] FindwxWidgets: Improve path detection logic when cross-compiling.
On Fri, Aug 22, 2014 at 12:08 PM, Brad King brad.k...@kitware.com wrote: On 08/22/2014 12:39 PM, Richard Shaw wrote: Simple logic update to check if we're cross-compiling to determine if unix or win32 path find style should be used. FindwxWidgets: Improve path detection logic when cross-compiling. [snip] +else(WIN32 AND NOT CYGWIN AND NOT MSYS AND NOT CMAKE_CROSSCOMPILING) + set(wxWidgets_FIND_STYLE unix) +endif(WIN32 AND NOT CYGWIN AND NOT MSYS AND NOT CMAKE_CROSSCOMPILING) Please use empty else() and endif(). Otherwise, looks good. Fixed: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=33286235048495ceafb636d549d9a4e8891967ae Thanks, Richard -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Review request] FindwxWidgets: Improve path detection logic when cross-compiling.
On 08/22/2014 01:23 PM, Richard Shaw wrote: Please use empty else() and endif(). Otherwise, looks good. Fixed: [snip] #= +# Determine whether unix or win32 paths should be used #= -if(WIN32 AND NOT CYGWIN AND NOT MSYS) +if(WIN32 AND NOT CYGWIN AND NOT MSYS AND NOT CMAKE_CROSSCOMPILING) set(wxWidgets_FIND_STYLE win32) else() - if(UNIX OR MSYS) -set(wxWidgets_FIND_STYLE unix) - endif() + set(wxWidgets_FIND_STYLE unix) endif() Good, thanks. Please merge for testing. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
