Re: [cmake-developers] Major.Minor version install directories
Brad King wrote: On 10/24/2013 12:56 PM, Stephen Kelly wrote: l -1 /home/stephen/dev/prefix/qtbase/kde/doc/ cmake-2.8/ cmake-2.8.12.20131023-g07324-dirty/ cmake-2.8.12.20131023-g10e02-dirty/ cmake-2.8.12.20131023-g1bfc2/ cmake-2.8.12.20131023-g3dec3/ The granular version-specific locations ensure we don't get modules left over from a different version. This has caused problems in the past that are very hard to track down remotely. If dealing with a user perhaps. Developers shouldn't have that problem. This shouldn't be much of a problem for anyone except developers. Then how about a compromise of major.minor.patch ? IMO one shouldn't be overwriting an existing install tree with a new CMake without removing the original anyway, but this approach gives us protection from it. Managing replace-able installations is the job of a package manager. If you're doing it by hand IMO you're on you're own. FYI, I keep my test install tree below my build directory and wipe it out before the next install: rm -rf $whatever_you_call_the_prefix make install That doesn't work for me because my qtbase prefix is where I install qtbase dev branch and other Qt repos (also dev branch), cmake (master, a topic or whatever version I need to test the Qt cmake files with), some KDE stuff and some KDAB stuff. I have another prefix for qtbase stable branch testing/work, another for Qt 4.8 etc. Clearing one of those prefixes completely just to remove micro-versioned cmake installations is not practical, and I don't want to add another dimension to my prefix system just for cmake installations. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
On 10/25/2013 09:02 AM, Stephen Kelly wrote: For 'broken' things like cxx_initializer_lists and cxx_variadic_templates, I recommend that we enable the feature if the compiler vendor says it is available. Yes, I think that makes sense. The problem with trying to report broken ourselves is that only the project knows if the feature is too broken for it. Developers using these bleeding-edge language features are used to conditional workarounds in their code anyway. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Fwd: CMake System Prefix Path
On 10/25/2013 10:04 AM, Stephen Kelly wrote: Brad King wrote: Others have asked to drop CMAKE_INSTALL_PREFIX from the CMAKE_SYSTEM_PREFIX_PATH before. I think it is a good default for the common dependency-sequence-to-one-prefix use case, but we should have an option to block it. Can you choose an interface for blocking it? It needs to be something that both * Modules/Platform/UnixPaths.cmake: CMAKE_SYSTEM_PREFIX_PATH * Modules/Platform/WindowsPaths.cmake: CMAKE_SYSTEM_PREFIX_PATH CMAKE_SYSTEM_LIBRARY_PATH will see and that the user can set at the command line without modifying the project. Therefore we should just test a variable that users can add to their local cache or that projects can set before the first language gets enabled (before enable_language or project). Other find behavior is controlled by CMAKE_FIND_* settings, so how about -DCMAKE_FIND_NO_INSTALL_PREFIX=1? -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014512]: cmp0022 does not warn
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=14512
==
Reported By:Clinton Stimpson
Assigned To:
==
Project:CMake
Issue ID: 14512
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2013-10-25 11:35 EDT
Last Modified: 2013-10-25 11:35 EDT
==
Summary:cmp0022 does not warn
Description:
Using cmake 2.8.12 does not give a warning if the target property
LINK_INTERFACE_LIBRARIES is used with export().
Steps to Reproduce:
touch foo.cpp
touch bar.cpp
use the following for CMakeLists.txt:
cmake_minimum_required(VERSION 2.8)
add_library(foo SHARED foo.cpp)
add_library(bar SHARED bar.cpp)
target_link_libraries(bar foo)
set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES )
export(TARGETS bar foo FILE ${CMAKE_CURRENT_BINARY_DIR}/bar-export.cmake)
run cmake 2.8.12 on that, and there is no warning which is incorrect.
Change to
cmake_minimum_required(VERSION 2.8.12)
and there is an error, which is correct.
==
Issue History
Date ModifiedUsername FieldChange
==
2013-10-25 11:35 Clinton StimpsonNew Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
On 10/24/2013 10:23 AM, Stephen Kelly wrote: Also when you run the compiler you need to capture all stdout/stderr so that it never leaks through to the user-visible cmake configuration output. The RunCMake.* tests that failed last night were mostly due to compilers writing to stderr even when nothing is wrong and therefore messing with the expected output matching. Should be all fixed now. Your patch did: +RESULT_VARIABLE _result +OUTPUT_VARIABLE _output but RESULT_VARIABLE is for the return code or administrative error message. You also need ERROR_VARIABLE _error to get stderr. Without this the tests still failed last night. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Major.Minor version install directories
On Friday 25 October 2013, Stephen Kelly wrote: Brad King wrote: ... FYI, I keep my test install tree below my build directory and wipe it out before the next install: rm -rf $whatever_you_call_the_prefix make install That doesn't work for me because my qtbase prefix is where I install qtbase dev branch and other Qt repos (also dev branch), cmake (master, a topic or whatever version I need to test the Qt cmake files with), some KDE stuff and some KDAB stuff. I have a directory full of different versions of cmake next to each other, prefix/cmake-2.4.5/ ... prefix/cmake-2.8.12/, and next to it prefix/cmake-HEAD/, so they are always cleanly separated and can be deleted without problems. Just for cmake you don't need to set any prefixes, just calling the one I need with the full path has always worked for me. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
