From nilsgladitz at gmail.com Mon Feb 1 03:01:03 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 1 Feb 2016 09:01:03 +0100 Subject: [cmake-developers] Is there a way to disable soname versioning? In-Reply-To: References: Message-ID: <56AF10BF.1040407@gmail.com> On 01.02.2016 00:09, Eric Wing wrote: > This has been an ongoing nuisance for me, so I thought I would finally > ask. Is there a way I can force soname versioning without modifying > everybody's CMake build scripts? > > The main problem is Android. Using soname versioning on Android will > basically cause things to break at runtime. It would be nice if the > CMake commands that set the version would be ignored in the Android > case. (I know Android is not officially supported by CMake and > cross-compile toolchains are being used, but if I knew how to put this > in the toolchain, that would be a big help.) The "Android" platform file included with CMake contains: set(CMAKE_PLATFORM_NO_VERSIONED_SONAME 1) Which should do just that. All you should have to do for this to take effect is have: set(CMAKE_SYSTEM_NAME Android) In your toolchain file (instead of what ever you've got it set to now). Nils From nick.lewis at amag.com Mon Feb 1 05:01:39 2016 From: nick.lewis at amag.com (Nick Lewis) Date: Mon, 1 Feb 2016 10:01:39 +0000 Subject: [cmake-developers] install(EXCLUDE_FROM_ALL) new feature - request for comment Message-ID: There is currently no way to exclude a component install() from a full installation. Current workarounds using OPTIONAL do not work reliably because they depend on previous builds and on the order of the execution of the build and install commands for the components and the default target Let us take an example of a project that has some tests in a component that need to be installed into a dedicated test package. The user expectation is that the result could be achieved by typing the following: make make tests make install DESTDIR=/testpkgs make install-tests However this results in test components in the default installation as well as the testpkg Judging by questions on the mail list, users typically try to overcome this problem by adding the EXCLUDE_FROM_ALL keyword to the install() command but this is currently unsupported. The patch uploaded to the issue tracker provides support for it. Brad has further suggested that the install(EXCLUDE_FROM_ALL) should be implicitly set when installing components built with add_executable/library(EXCLUDE_FROM_ALL) I welcome your views on these ideas https://cmake.org/Bug/view.php?id=14921 Best Regards Nick -- Nick Lewis nick.lewis at amag.com +44 1684 277137 <+441684277137> www.amag.com AMAG Technology, Challenge House, International Drive, Tewkesbury Business Park, TEWKESBURY, GL20 8UQ, U.K. -- This company is part of the G4S group of companies. This communication contains information which may be confidential, personal and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sender and the Company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity. This message has been checked for viruses on behalf of the Company. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Feb 1 10:51:08 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 1 Feb 2016 10:51:08 -0500 Subject: [cmake-developers] Patch: Remove superfluous semicolon after method In-Reply-To: <56ABEB2F.2000904@grueninger.de> References: <56ABEB2F.2000904@grueninger.de> Message-ID: <56AF7EEC.4060202@kitware.com> On 01/29/2016 05:43 PM, Christoph Gr?ninger wrote: > please find attached a minimal patch to fix a GCC 6 pedantic warning > concerning a superfluous semicolon after a method. Applied, thanks: cmAlgorithms.h: remove superfluous semicolon after method https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ccb2d5c0 > Additional I got the following warning: >> CMake/Source/cmGeneratorTarget.cxx:4835:52: warning: format ?%u? expects >> argument of type ?unsigned int*?, but argument 3 has type ?int*? [-Wformat=] >> sscanf(config_reps, "%u", &iface.Multiplicity); > > Same on 4840:45, 5543:51, 5548:44 in the same file. It is not obvious to > me whether you want to change the types in cmOptionalLinkInterface, > change the type in sscanf or cast the types. There is no reason to have negative values for that, so please update both cmLinkInterface::Multiplicity and cmGeneratorTarget::Multiplicity to use `unsigned int` and follow through with any further changes needed for that (I don't think there are any but have not checked). Thanks, -Brad From michael.scott250 at gmail.com Tue Feb 2 03:08:18 2016 From: michael.scott250 at gmail.com (Michael Scott) Date: Tue, 2 Feb 2016 08:08:18 +0000 Subject: [cmake-developers] Review request: extract-cmMessenger branch In-Reply-To: References: Message-ID: <56B063F2.8080206@gmail.com> > Yes. Did you have a close look at the commits? I'm not really sure they are > correct, and I wonder if you have any thoughts on the first one which > discusses interface? I went back and had a closer look at the major changes. I think on the whole the cmMessenger class is good and a clear improvement over the previous organisation, however I imagine in its current form it would be perhaps a bit tricky extending it for other environments (e.g. displaying messages as GUI modal notifications), which I understood to be one of the overall aims of the branch (correct me if I've misunderstood of course though). I would be tempted to make the following changes to the cmMessenger class: * Make cmMessenger an abstract class, and have the IssueMessage methods pure virtual here, then create an extension containing the current implementations called cmConsoleMessenger or something. The name cmMessenger suggests a fairly generic concept, but the current implementation feels geared around a console, though that's just my thoughts. * Make the IsMessageTypeVisible and ConvertMessageType methods virtual and protected, to make it easier to override their behaviour in extensions of the base class. * Change printMessagePreamble to return void * Rename printMessagePreamble to appendMessagePreamble or something to better reflect what its doing, similar change to printMessageText as well * Move the different parts to displayMessage into individual methods, e.g. adding the notes about warning suppression * Append notes for DEPRECATED_WARNING and DEPRECATED_ERROR message types, or remove the current notes, to be consistent I don't really have any other comments for the other commits. I was wondering if it would be possible to move away from accessing the cmMessenger class through the cmake / cmMakefile class, but then if we do want to slot it new implementations easily I imagine the current organisation would facilitate that quite well so it wouldn't be worth changing. Cheers, Michael From apbarrero at gmail.com Tue Feb 2 03:29:10 2016 From: apbarrero at gmail.com (Antonio Perez Barrero) Date: Tue, 2 Feb 2016 09:29:10 +0100 Subject: [cmake-developers] [PATCH] FindProtobuf: check version Message-ID: <1454401750-31859-1-git-send-email-antonioperez@by.com.es> From: Antonio Perez Barrero Check found libraries version to match user required version, including EXACT match. Protobuf compiler executable version is check to be aligned with found libraries, raising a warning message otherwise. Module interface and private variables are renamed to honour recommendation to be aligned in case with module name. --- Modules/FindProtobuf.cmake | 205 ++++++++++++++++++++++++++++++++------------- 1 file changed, 149 insertions(+), 56 deletions(-) diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake index 2f13b09..34cd660 100644 --- a/Modules/FindProtobuf.cmake +++ b/Modules/FindProtobuf.cmake @@ -6,47 +6,49 @@ # # The following variables can be set and are optional: # -# ``PROTOBUF_SRC_ROOT_FOLDER`` +# ``Protobuf_SRC_ROOT_FOLDER`` # When compiling with MSVC, if this cache variable is set # the protobuf-default VS project build locations # (vsprojects/Debug and vsprojects/Release # or vsprojects/x64/Debug and vsprojects/x64/Release) # will be searched for libraries and binaries. -# ``PROTOBUF_IMPORT_DIRS`` +# ``Protobuf_IMPORT_DIRS`` # List of additional directories to be searched for # imported .proto files. +# ``Protobuf_DEBUG`` +# Show debug messages. # # Defines the following variables: # -# ``PROTOBUF_FOUND`` +# ``Protobuf_FOUND`` # Found the Google Protocol Buffers library # (libprotobuf & header files) -# ``PROTOBUF_INCLUDE_DIRS`` +# ``Protobuf_INCLUDE_DIRS`` # Include directories for Google Protocol Buffers -# ``PROTOBUF_LIBRARIES`` +# ``Protobuf_LIBRARIES`` # The protobuf libraries -# ``PROTOBUF_PROTOC_LIBRARIES`` +# ``Protobuf_PROTOC_LIBRARIES`` # The protoc libraries -# ``PROTOBUF_LITE_LIBRARIES`` +# ``Protobuf_LITE_LIBRARIES`` # The protobuf-lite libraries # # The following cache variables are also available to set or use: # -# ``PROTOBUF_LIBRARY`` +# ``Protobuf_LIBRARY`` # The protobuf library -# ``PROTOBUF_PROTOC_LIBRARY`` +# ``Protobuf_PROTOC_LIBRARY`` # The protoc library -# ``PROTOBUF_INCLUDE_DIR`` +# ``Protobuf_INCLUDE_DIR`` # The include directory for protocol buffers -# ``PROTOBUF_PROTOC_EXECUTABLE`` +# ``Protobuf_PROTOC_EXECUTABLE`` # The protoc compiler -# ``PROTOBUF_LIBRARY_DEBUG`` +# ``Protobuf_LIBRARY_DEBUG`` # The protobuf library (debug) -# ``PROTOBUF_PROTOC_LIBRARY_DEBUG`` +# ``Protobuf_PROTOC_LIBRARY_DEBUG`` # The protoc library (debug) -# ``PROTOBUF_LITE_LIBRARY`` +# ``Protobuf_LITE_LIBRARY`` # The protobuf lite library -# ``PROTOBUF_LITE_LIBRARY_DEBUG`` +# ``Protobuf_LITE_LIBRARY_DEBUG`` # The protobuf lite library (debug) # # Example: @@ -54,12 +56,12 @@ # .. code-block:: cmake # # find_package(Protobuf REQUIRED) -# include_directories(${PROTOBUF_INCLUDE_DIRS}) +# include_directories(${Protobuf_INCLUDE_DIRS}) # include_directories(${CMAKE_CURRENT_BINARY_DIR}) # protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS foo.proto) # protobuf_generate_python(PROTO_PY foo.proto) # add_executable(bar bar.cc ${PROTO_SRCS} ${PROTO_HDRS}) -# target_link_libraries(bar ${PROTOBUF_LIBRARIES}) +# target_link_libraries(bar ${Protobuf_LIBRARIES}) # # .. note:: # The ``protobuf_generate_cpp`` and ``protobuf_generate_python`` @@ -105,13 +107,13 @@ # (To distribute this file outside of CMake, substitute the full # License text for the above reference.) -function(PROTOBUF_GENERATE_CPP SRCS HDRS) +function(Protobuf_GENERATE_CPP SRCS HDRS) if(NOT ARGN) - message(SEND_ERROR "Error: PROTOBUF_GENERATE_CPP() called without any proto files") + message(SEND_ERROR "Error: Protobuf_GENERATE_CPP() called without any proto files") return() endif() - if(PROTOBUF_GENERATE_CPP_APPEND_PATH) + if(Protobuf_GENERATE_CPP_APPEND_PATH) # Create an include path for each file specified foreach(FIL ${ARGN}) get_filename_component(ABS_FIL ${FIL} ABSOLUTE) @@ -125,8 +127,8 @@ function(PROTOBUF_GENERATE_CPP SRCS HDRS) set(_protobuf_include_path -I ${CMAKE_CURRENT_SOURCE_DIR}) endif() - if(DEFINED PROTOBUF_IMPORT_DIRS) - foreach(DIR ${PROTOBUF_IMPORT_DIRS}) + if(DEFINED Protobuf_IMPORT_DIRS) + foreach(DIR ${Protobuf_IMPORT_DIRS}) get_filename_component(ABS_PATH ${DIR} ABSOLUTE) list(FIND _protobuf_include_path ${ABS_PATH} _contains_already) if(${_contains_already} EQUAL -1) @@ -147,9 +149,9 @@ function(PROTOBUF_GENERATE_CPP SRCS HDRS) add_custom_command( OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.cc" "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.h" - COMMAND ${PROTOBUF_PROTOC_EXECUTABLE} + COMMAND ${Protobuf_PROTOC_EXECUTABLE} ARGS --cpp_out ${CMAKE_CURRENT_BINARY_DIR} ${_protobuf_include_path} ${ABS_FIL} - DEPENDS ${ABS_FIL} ${PROTOBUF_PROTOC_EXECUTABLE} + DEPENDS ${ABS_FIL} ${Protobuf_PROTOC_EXECUTABLE} COMMENT "Running C++ protocol buffer compiler on ${FIL}" VERBATIM ) endforeach() @@ -159,13 +161,13 @@ function(PROTOBUF_GENERATE_CPP SRCS HDRS) set(${HDRS} ${${HDRS}} PARENT_SCOPE) endfunction() -function(PROTOBUF_GENERATE_PYTHON SRCS) +function(Protobuf_GENERATE_PYTHON SRCS) if(NOT ARGN) - message(SEND_ERROR "Error: PROTOBUF_GENERATE_PYTHON() called without any proto files") + message(SEND_ERROR "Error: Protobuf_GENERATE_PYTHON() called without any proto files") return() endif() - if(PROTOBUF_GENERATE_CPP_APPEND_PATH) + if(Protobuf_GENERATE_CPP_APPEND_PATH) # Create an include path for each file specified foreach(FIL ${ARGN}) get_filename_component(ABS_FIL ${FIL} ABSOLUTE) @@ -179,8 +181,8 @@ function(PROTOBUF_GENERATE_PYTHON SRCS) set(_protobuf_include_path -I ${CMAKE_CURRENT_SOURCE_DIR}) endif() - if(DEFINED PROTOBUF_IMPORT_DIRS) - foreach(DIR ${PROTOBUF_IMPORT_DIRS}) + if(DEFINED Protobuf_IMPORT_DIRS) + foreach(DIR ${Protobuf_IMPORT_DIRS}) get_filename_component(ABS_PATH ${DIR} ABSOLUTE) list(FIND _protobuf_include_path ${ABS_PATH} _contains_already) if(${_contains_already} EQUAL -1) @@ -197,8 +199,8 @@ function(PROTOBUF_GENERATE_PYTHON SRCS) list(APPEND ${SRCS} "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}_pb2.py") add_custom_command( OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}_pb2.py" - COMMAND ${PROTOBUF_PROTOC_EXECUTABLE} --python_out ${CMAKE_CURRENT_BINARY_DIR} ${_protobuf_include_path} ${ABS_FIL} - DEPENDS ${ABS_FIL} ${PROTOBUF_PROTOC_EXECUTABLE} + COMMAND ${Protobuf_PROTOC_EXECUTABLE} --python_out ${CMAKE_CURRENT_BINARY_DIR} ${_protobuf_include_path} ${ABS_FIL} + DEPENDS ${ABS_FIL} ${Protobuf_PROTOC_EXECUTABLE} COMMENT "Running Python protocol buffer compiler on ${FIL}" VERBATIM ) endforeach() @@ -207,7 +209,7 @@ function(PROTOBUF_GENERATE_PYTHON SRCS) endfunction() if(CMAKE_SIZEOF_VOID_P EQUAL 8) - set(_PROTOBUF_ARCH_DIR x64/) + set(_Protobuf_ARCH_DIR x64/) endif() # Internal function: search for normal library as well as a debug one @@ -216,12 +218,12 @@ endif() function(_protobuf_find_libraries name filename) find_library(${name}_LIBRARY NAMES ${filename} - PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Release) + PATHS ${Protobuf_SRC_ROOT_FOLDER}/vsprojects/${_Protobuf_ARCH_DIR}Release) mark_as_advanced(${name}_LIBRARY) find_library(${name}_LIBRARY_DEBUG NAMES ${filename} - PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug) + PATHS ${Protobuf_SRC_ROOT_FOLDER}/vsprojects/${_Protobuf_ARCH_DIR}Debug) mark_as_advanced(${name}_LIBRARY_DEBUG) if(NOT ${name}_LIBRARY_DEBUG) @@ -243,8 +245,8 @@ function(_protobuf_find_threads) set(CMAKE_THREAD_PREFER_PTHREAD TRUE) find_package(Threads) if(Threads_FOUND) - list(APPEND PROTOBUF_LIBRARIES ${CMAKE_THREAD_LIBS_INIT}) - set(PROTOBUF_LIBRARIES "${PROTOBUF_LIBRARIES}" PARENT_SCOPE) + list(APPEND Protobuf_LIBRARIES ${CMAKE_THREAD_LIBS_INIT}) + set(Protobuf_LIBRARIES "${Protobuf_LIBRARIES}" PARENT_SCOPE) endif() endfunction() @@ -252,34 +254,34 @@ endfunction() # Main. # -# By default have PROTOBUF_GENERATE_CPP macro pass -I to protoc +# By default have Protobuf_GENERATE_CPP macro pass -I to protoc # for each directory where a proto file is referenced. -if(NOT DEFINED PROTOBUF_GENERATE_CPP_APPEND_PATH) - set(PROTOBUF_GENERATE_CPP_APPEND_PATH TRUE) +if(NOT DEFINED Protobuf_GENERATE_CPP_APPEND_PATH) + set(Protobuf_GENERATE_CPP_APPEND_PATH TRUE) endif() # Google's provided vcproj files generate libraries with a "lib" # prefix on Windows if(MSVC) - set(PROTOBUF_ORIG_FIND_LIBRARY_PREFIXES "${CMAKE_FIND_LIBRARY_PREFIXES}") + set(Protobuf_ORIG_FIND_LIBRARY_PREFIXES "${CMAKE_FIND_LIBRARY_PREFIXES}") set(CMAKE_FIND_LIBRARY_PREFIXES "lib" "") - find_path(PROTOBUF_SRC_ROOT_FOLDER protobuf.pc.in) + find_path(Protobuf_SRC_ROOT_FOLDER protobuf.pc.in) endif() # The Protobuf library -_protobuf_find_libraries(PROTOBUF protobuf) +_protobuf_find_libraries(Protobuf protobuf) #DOC "The Google Protocol Buffers RELEASE Library" -_protobuf_find_libraries(PROTOBUF_LITE protobuf-lite) +_protobuf_find_libraries(Protobuf_LITE protobuf-lite) # The Protobuf Protoc Library -_protobuf_find_libraries(PROTOBUF_PROTOC protoc) +_protobuf_find_libraries(Protobuf_PROTOC protoc) # Restore original find library prefixes if(MSVC) - set(CMAKE_FIND_LIBRARY_PREFIXES "${PROTOBUF_ORIG_FIND_LIBRARY_PREFIXES}") + set(CMAKE_FIND_LIBRARY_PREFIXES "${Protobuf_ORIG_FIND_LIBRARY_PREFIXES}") endif() if(UNIX) @@ -287,27 +289,118 @@ if(UNIX) endif() # Find the include directory -find_path(PROTOBUF_INCLUDE_DIR +find_path(Protobuf_INCLUDE_DIR google/protobuf/service.h - PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/src + PATHS ${Protobuf_SRC_ROOT_FOLDER}/src ) -mark_as_advanced(PROTOBUF_INCLUDE_DIR) +mark_as_advanced(Protobuf_INCLUDE_DIR) # Find the protoc Executable -find_program(PROTOBUF_PROTOC_EXECUTABLE +find_program(Protobuf_PROTOC_EXECUTABLE NAMES protoc DOC "The Google Protocol Buffers Compiler" PATHS - ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Release - ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug + ${Protobuf_SRC_ROOT_FOLDER}/vsprojects/${_Protobuf_ARCH_DIR}Release + ${Protobuf_SRC_ROOT_FOLDER}/vsprojects/${_Protobuf_ARCH_DIR}Debug ) -mark_as_advanced(PROTOBUF_PROTOC_EXECUTABLE) +mark_as_advanced(Protobuf_PROTOC_EXECUTABLE) +if(Protobuf_DEBUG) + message(STATUS "[ ${CMAKE_CURRENT_LIST_FILE}:${CMAKE_CURRENT_LIST_LINE} ] " + "requested version of Google Protobuf is ${Protobuf_FIND_VERSION}") +endif() + +if(Protobuf_INCLUDE_DIR) + set(_Protobuf_COMMON_HEADER ${Protobuf_INCLUDE_DIR}/google/protobuf/stubs/common.h) + + if(Protobuf_DEBUG) + message(STATUS "[ ${CMAKE_CURRENT_LIST_FILE}:${CMAKE_CURRENT_LIST_LINE} ] " + "location of common.h: ${Protobuf_INCLUDE_DIR}/google/protobuf/stubs/common.h") + endif() + + set(Protobuf_VERSION 0) + set(Protobuf_LIB_VERSION "") + file(STRINGS ${_Protobuf_COMMON_HEADER} _Protobuf_COMMON_H_CONTENTS REGEX "#define GOOGLE_PROTOBUF_VERSION ") + set(_Protobuf_VERSION_REGEX "([0-9]+)") + if("${_Protobuf_COMMON_H_CONTENTS}" MATCHES "#define GOOGLE_PROTOBUF_VERSION ${_Protobuf_VERSION_REGEX}") + set(Protobuf_VERSION "${CMAKE_MATCH_1}") + endif() + unset(_Protobuf_COMMON_H_CONTENTS) + + math(EXPR Protobuf_MAJOR_VERSION "${Protobuf_VERSION} / 1000000") + math(EXPR Protobuf_MINOR_VERSION "${Protobuf_VERSION} / 1000 % 1000") + math(EXPR Protobuf_SUBMINOR_VERSION "${Protobuf_VERSION} % 1000") + + set(Protobuf_ERROR_REASON + "${Protobuf_ERROR_REASON}Google Protobuf version: ${Protobuf_MAJOR_VERSION}.${Protobuf_MINOR_VERSION}.${Protobuf_SUBMINOR_VERSION}\nGoogle Protobuf include path: ${Protobuf_INCLUDE_DIR}") + if(Protobuf_DEBUG) + message(STATUS "[ ${CMAKE_CURRENT_LIST_FILE}:${CMAKE_CURRENT_LIST_LINE} ] " + "${_Protobuf_COMMON_HEADER} reveals protobuf " + "${Protobuf_MAJOR_VERSION}.${Protobuf_MINOR_VERSION}.${Protobuf_SUBMINOR_VERSION}") + endif() + + if(Protobuf_FIND_VERSION) + # Set Protobuf_FOUND based on requested version. + set(_Protobuf_VERSION "${Protobuf_MAJOR_VERSION}.${Protobuf_MINOR_VERSION}.${Protobuf_SUBMINOR_VERSION}") + if("${_Protobuf_VERSION}" VERSION_LESS "${Protobuf_FIND_VERSION}") + set(Protobuf_FOUND 0) + set(_Protobuf_VERSION_AGE "old") + elseif(Protobuf_FIND_VERSION_EXACT AND + NOT "${_Protobuf_VERSION}" VERSION_EQUAL "${Protobuf_FIND_VERSION}") + set(Protobuf_FOUND 0) + set(_Protobuf_VERSION_AGE "new") + else() + set(Protobuf_FOUND 1) + endif() + if(NOT Protobuf_FOUND) + # State that we found a version of Protobuf that is too new or too old. + set(Protobuf_ERROR_REASON + "${Protobuf_ERROR_REASON}\nDetected version of Google Protobuf is too ${_Protobuf_VERSION_AGE}. Requested version was ${Protobuf_FIND_VERSION_MAJOR}.${Protobuf_FIND_VERSION_MINOR}") + if (Protobuf_FIND_VERSION_PATCH) + set(Protobuf_ERROR_REASON + "${Protobuf_ERROR_REASON}.${Protobuf_FIND_VERSION_PATCH}") + endif () + if (NOT Protobuf_FIND_VERSION_EXACT) + set(Protobuf_ERROR_REASON "${Protobuf_ERROR_REASON} (or newer)") + endif () + set(Protobuf_ERROR_REASON "${Protobuf_ERROR_REASON}.") + endif () + else() + # Caller will accept any Protobuf version. + set(Protobuf_FOUND 1) + endif() + + if(NOT Protobuf_FOUND AND Protobuf_FIND_REQUIRED) + message(FATAL_ERROR "${Protobuf_ERROR_REASON}") + endif() + + # Check Protobuf compiler version to be aligned with libraries version + execute_process(COMMAND ${Protobuf_PROTOC_EXECUTABLE} --version + OUTPUT_VARIABLE _Protobuf_PROTOC_EXECUTABLE_VERSION) + + if("${_Protobuf_PROTOC_EXECUTABLE_VERSION}" MATCHES "libprotoc ([0-9\.]+)") + set(_Protobuf_PROTOC_EXECUTABLE_VERSION "${CMAKE_MATCH_1}") + endif() + + if(Protobuf_DEBUG) + message(STATUS "[ ${CMAKE_CURRENT_LIST_FILE}:${CMAKE_CURRENT_LIST_LINE} ] " + "${Protobuf_PROTOC_EXECUTABLE} reveals version ${_Protobuf_PROTOC_EXECUTABLE_VERSION}") + endif() + + if(NOT "${_Protobuf_PROTOC_EXECUTABLE_VERSION}" VERSION_EQUAL "${_Protobuf_VERSION}") + message(WARNING "Protobuf compiler version ${_Protobuf_PROTOC_EXECUTABLE_VERSION}" + " doesn't match library version ${_Protobuf_VERSION}") + endif() +else() + set(Protobuf_FOUND 0) + set(Protobuf_ERROR_REASON + "${Protobuf_ERROR_REASON}Unable to find the Google Protobuf header files.") +endif() -include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) +include(FindPackageHandleStandardArgs) FIND_PACKAGE_HANDLE_STANDARD_ARGS(Protobuf DEFAULT_MSG - PROTOBUF_LIBRARY PROTOBUF_INCLUDE_DIR) + Protobuf_LIBRARY Protobuf_INCLUDE_DIR) -if(PROTOBUF_FOUND) - set(PROTOBUF_INCLUDE_DIRS ${PROTOBUF_INCLUDE_DIR}) +if(Protobuf_FOUND) + set(Protobuf_INCLUDE_DIRS ${Protobuf_INCLUDE_DIR}) endif() -- 1.9.1 From mantis at public.kitware.com Tue Feb 2 07:53:48 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 2 Feb 2016 07:53:48 -0500 Subject: [cmake-developers] [CMake 0015950]: CMAKE_SIZEOF_VOID_P is undefined on Windows 7 x64 VM (Vmware 10) Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15950 ====================================================================== Reported By: Lars Wiese Assigned To: ====================================================================== Project: CMake Issue ID: 15950 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-02 07:53 EST Last Modified: 2016-02-02 07:53 EST ====================================================================== Summary: CMAKE_SIZEOF_VOID_P is undefined on Windows 7 x64 VM (Vmware 10) Description: CMAKE_SIZEOF_VOID_P is undefined on Windows 7 x64 VM (Vmware 10) I am using CMAKE_SIZEOF_VOID_P for switching parameters for x86 or x64. For my understanding the value is related to generator the ARCH. I tried the generator for VS 2010 and VS2013 together with/without " Win64" Steps to Reproduce: if( CMAKE_SIZEOF_VOID_P EQUAL 8 ) set (ARCH "x64") add_definitions("-DX86_64") message ("Build type: Windows x64") else () set (ARCH "x86") message ("Build type: Windows x86") endif() ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-02 07:53 Lars Wiese New Issue ====================================================================== From brad.king at kitware.com Tue Feb 2 09:09:47 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 2 Feb 2016 09:09:47 -0500 Subject: [cmake-developers] CMake 3.5 feature freeze on 2016-02-01 In-Reply-To: <56A63BD8.7000501@kitware.com> References: <55F04ADB.1000003@kitware.com> <56A63BD8.7000501@kitware.com> Message-ID: <56B0B8AB.2050103@kitware.com> On 01/25/2016 10:14 AM, Brad King wrote: > I'll announce when post-3.5 development in 'next' is open. I've branched 'release' for 3.5. The repository is now open for post-3.5 development. Please rebase any open topics on 'master' before merging to 'next'. > * Documentation updates > * Regression fixes > * Fixes for bugs in features new to 3.5 These types of changes may still be accepted to 'release' during the 3.5 release candidate cycle. The 3.5 release is now closed to new features and general bug fixes. -Brad From ben.boeckel at kitware.com Tue Feb 2 09:58:08 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 2 Feb 2016 09:58:08 -0500 Subject: [cmake-developers] [PATCH] FindProtobuf: check version In-Reply-To: <1454401750-31859-1-git-send-email-antonioperez@by.com.es> References: <1454401750-31859-1-git-send-email-antonioperez@by.com.es> Message-ID: <20160202145808.GB3429@megas.kitware.com> On Tue, Feb 02, 2016 at 09:29:10 +0100, Antonio Perez Barrero wrote: > From: Antonio Perez Barrero > > Check found libraries version to match user required version, including > EXACT match. > > Protobuf compiler executable version is check to be aligned with found > libraries, raising a warning message otherwise. > > Module interface and private variables are renamed to honour > recommendation to be aligned in case with module name. Thanks, comments inline. > diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake > index 2f13b09..34cd660 100644 > --- a/Modules/FindProtobuf.cmake > +++ b/Modules/FindProtobuf.cmake > @@ -6,47 +6,49 @@ > # > # The following variables can be set and are optional: > # > -# ``PROTOBUF_SRC_ROOT_FOLDER`` > +# ``Protobuf_SRC_ROOT_FOLDER`` Could this rename be split out into a separate patch? Backwards compatibility still needs to be provided though, so the uppercase versions will still need to exist. > -function(PROTOBUF_GENERATE_CPP SRCS HDRS) > +function(Protobuf_GENERATE_CPP SRCS HDRS) Function case doesn't matter, so no need to duplicate it. > + if("${_Protobuf_COMMON_H_CONTENTS}" MATCHES "#define GOOGLE_PROTOBUF_VERSION ${_Protobuf_VERSION_REGEX}") No need to dereference the content variable. Should be: + if(_Protobuf_COMMON_H_CONTENTS MATCHES "#define GOOGLE_PROTOBUF_VERSION ${_Protobuf_VERSION_REGEX}") > + math(EXPR Protobuf_MAJOR_VERSION "${Protobuf_VERSION} / 1000000") > + math(EXPR Protobuf_MINOR_VERSION "${Protobuf_VERSION} / 1000 % 1000") > + math(EXPR Protobuf_SUBMINOR_VERSION "${Protobuf_VERSION} % 1000") Would string manipulation be better here? > + if(Protobuf_FIND_VERSION) > + # Set Protobuf_FOUND based on requested version. > + set(_Protobuf_VERSION "${Protobuf_MAJOR_VERSION}.${Protobuf_MINOR_VERSION}.${Protobuf_SUBMINOR_VERSION}") The find_package_handle_standard_args function has a VERSION_VAR argument which can do this logic. Thanks, --Ben From eike at sf-mail.de Tue Feb 2 10:18:31 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 02 Feb 2016 16:18:31 +0100 Subject: [cmake-developers] [PATCH] FindProtobuf: check version In-Reply-To: <1454401750-31859-1-git-send-email-antonioperez@by.com.es> References: <1454401750-31859-1-git-send-email-antonioperez@by.com.es> Message-ID: > + > + set(Protobuf_VERSION 0) Just set it to an empty string. > + set(Protobuf_LIB_VERSION "") > + file(STRINGS ${_Protobuf_COMMON_HEADER} _Protobuf_COMMON_H_CONTENTS > REGEX "#define GOOGLE_PROTOBUF_VERSION ") I would replace the spaces with "[ \t]+" so a formatting change will not break the extraction, also below. > + set(_Protobuf_VERSION_REGEX "([0-9]+)") No need for that variable, just put it into the matches argument below. > + if("${_Protobuf_COMMON_H_CONTENTS}" MATCHES "#define > GOOGLE_PROTOBUF_VERSION ${_Protobuf_VERSION_REGEX}") > + set(Protobuf_VERSION "${CMAKE_MATCH_1}") > + endif() > + unset(_Protobuf_COMMON_H_CONTENTS) > + > + math(EXPR Protobuf_MAJOR_VERSION "${Protobuf_VERSION} / 1000000") > + math(EXPR Protobuf_MINOR_VERSION "${Protobuf_VERSION} / 1000 % > 1000") > + math(EXPR Protobuf_SUBMINOR_VERSION "${Protobuf_VERSION} % 1000") You are not required to export these variables, only if you expect it to be useful for something beyond version checking. If anyone needs specific version fiddling Protobuf_VERSION can be used. Eike From robert.maynard at kitware.com Tue Feb 2 16:56:24 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 2 Feb 2016 16:56:24 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake 3.5.0-rc1 now ready for testing! Message-ID: I am proud to announce the first CMake 3.5 release candidate. Sources and binaries are available at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.5 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.5/release/3.5.html Some of the more significant features of CMake 3.5 are: * The precompiled Windows binary provided on "cmake.org" is now a ".msi" package instead of an installer executable. One may need to manually uninstall CMake versions lower than 3.5 before installing the new package. * The "cmake-gui(1)" learned an option to set the toolset to be used with VS IDE and Xcode generators, much like the existing "-T" option to "cmake(1)". * Find modules for Boost, FLEX, GTest, GTK2, PNG, TIFF, and XercesC now provide imported targets. * The "FindOpenMP" module learned to support Clang. * A new platform file for cross-compiling in the Cray Linux Environment to target compute nodes was added. See Cross Compiling for the Cray Linux Environment for usage details. * The "Compile Features" functionality is now aware of features supported by Clang compilers on Windows (MinGW). * Support was added for the ARM Compiler (arm.com) with compiler id "ARMCC". * When building for embedded Apple platforms like iOS CMake learned to build and install combined targets which contain both a device and a simulator build. This behavior can be enabled by setting the "IOS_INSTALL_COMBINED" target property. * The "CPackDMG" module learned new variable to specify AppleScript file run to customize appearance of "DragNDrop" installer folder, including background image setting using supplied PNG or multi- resolution TIFF file. See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and "CPACK_DMG_BACKGROUND_IMAGE" variables. Deprecated and Removed Features: * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "cmake(1)" "-E time" command now properly passes arguments with spaces or special characters through to the child process. This may break scripts that worked around the bug with their own extra quoting or escaping. CMake 3.5 Release Notes *********************** Changes made since CMake 3.4 include the following. New Features ============ GUI --- * The "cmake-gui(1)" gained options to control warnings about deprecated functionality. * The "cmake-gui(1)" learned an option to set the toolset to be used with VS IDE and Xcode generators, much like the existing "-T" option to "cmake(1)". * The "cmake-gui(1)" gained a Regular Expression Explorer which may be used to create and evaluate regular expressions in real-time. The explorer window is available via the "Tools" menu. Command-Line ------------ * The "-Wdev" and "-Wno-dev" "cmake(1)" options now also enable and suppress the deprecated warnings output by default. * The suppression of developer warnings as errors can now be controlled with the new "-Werror=dev" and "-Wno-error=dev" "cmake(1)" options. * The "cmake(1)" "-E" command-line tools "copy", "copy_if_different", "copy_directory", and "make_directory" learned to support multiple input files or directories. Commands -------- * The "cmake_parse_arguments()" command is now implemented natively. The "CMakeParseArguments" module remains as an empty placeholder for compatibility. * The "install(DIRECTORY)" command learned to support "generator expressions" in the list of directories. Variables --------- * The "CMAKE_ERROR_DEPRECATED" variable can now be set using the "-Werror=deprecated" and "-Wno-error=deprecated" "cmake(1)" options. * The "CMAKE_WARN_DEPRECATED" variable can now be set using the "-Wdeprecated" and "-Wno-deprecated" "cmake(1)" options. Properties ---------- * The "VS_GLOBAL_" target property is now implemented for VS 2010 and above. Previously it worked only in VS 2008 and below. Modules ------- * The "ExternalProject" module learned a new "GIT_REMOTE_NAME" option to control the "git clone --origin" value. * The "FindBoost" module now provides imported targets such as "Boost::boost" and "Boost::filesystem". * The "FindFLEX" module "FLEX_TARGET" macro learned a new "DEFINES_FILE" option to specify a custom output header to be generated. * The "FindGTest" module now provides imported targets. * The "FindGTK2" module, when "GTK2_USE_IMPORTED_TARGETS" is enabled, now sets "GTK2_LIBRARIES" to contain the list of imported targets instead of the paths to the libraries. Moreover it now sets a new "GTK2_TARGETS" variable containing all the targets imported. * The "FindOpenMP" module learned to support Clang. * The "FindOpenSSL" module gained a new "OPENSSL_MSVC_STATIC_RT" option to search for libraries using the MSVC static runtime. * The "FindPNG" module now provides imported targets. * The "FindTIFF" module now provides imported targets. * A "FindXalanC" module was introduced to find the Apache Xalan-C++ XSL transform processing library. * The "FindXercesC" module now provides imported targets. Platforms --------- * Support was added for the ARM Compiler (arm.com) with compiler id "ARMCC". * A new platform file for cross-compiling in the Cray Linux Environment to target compute nodes was added. See Cross Compiling for the Cray Linux Environment for usage details. * The "Compile Features" functionality is now aware of features supported by Clang compilers on Windows (MinGW). * When building for embedded Apple platforms like iOS CMake learned to build and install combined targets which contain both a device and a simulator build. This behavior can be enabled by setting the "IOS_INSTALL_COMBINED" target property. CPack ----- * The "CPackDMG" module learned new variable to specify AppleScript file run to customize appearance of "DragNDrop" installer folder, including background image setting using supplied PNG or multi- resolution TIFF file. See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and "CPACK_DMG_BACKGROUND_IMAGE" variables. * The "CPackDeb" module learned to set the optional config file "Source" field using a monolithic or per-component variable. See "CPACK_DEBIAN_PACKAGE_SOURCE". * The "CPackDeb" module learned to set Package, Section and Priority control fields per-component. See variables "CPACK_DEBIAN__PACKAGE_SECTION" and "CPACK_DEBIAN__PACKAGE_PRIORITY". * The "CPack DragNDrop generator" learned to add multi-lingual SLAs to a DMG which is presented to the user when they try to mount the DMG. See the "CPACK_DMG_SLA_LANGUAGES" and "CPACK_DMG_SLA_DIR" variables for details. * The "CPackNSIS" module learned new variables to add bitmaps to the installer. See the "CPACK_NSIS_MUI_WELCOMEFINISHPAGE_BITMAP" and "CPACK_NSIS_MUI_UNWELCOMEFINISHPAGE_BITMAP" variables. * The "CPackRPM" module learned to set Name and Group control fields per-component. See "CPACK_RPM__PACKAGE_NAME" and "CPACK_RPM__PACKAGE_GROUP". Other ----- * Warnings about deprecated functionality are now enabled by default. They may be suppressed with "-Wno-deprecated" or by setting the "CMAKE_WARN_DEPRECATED" variable to false. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "cmake(1)" "-E time" command now properly passes arguments with spaces or special characters through to the child process. This may break scripts that worked around the bug with their own extra quoting or escaping. Other Changes ============= * The "Visual Studio 14 2015" generator learned to map the "/debug:fastlink" linker flag to the ".vcxproj" file property. * The "FindGTK2" module now configures the "GTK2::sigc++" imported target to enable c++11 on its dependents when using sigc++ 2.5.1 or higher. * The precompiled Windows binary provided on "cmake.org" is now a ".msi" package instead of an installer executable. One may need to manually uninstall CMake versions lower than 3.5 before installing the new package. From mantis at public.kitware.com Tue Feb 2 17:51:02 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 2 Feb 2016 17:51:02 -0500 Subject: [cmake-developers] [CMake 0015951]: cannot configure cmake Message-ID: <05d93fa7e10173da61759f917762b4b2@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15951 ====================================================================== Reported By: Kemin Zhou Assigned To: ====================================================================== Project: CMake Issue ID: 15951 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2016-02-02 17:51 EST Last Modified: 2016-02-02 17:51 EST ====================================================================== Summary: cannot configure cmake Description: Cannot pass the configuration step of cmake while trying to build cmake. The problem is the the g++ compiler is in /usr/local which g++ /usr/local/bin/g++ g++ --version g++ (GCC) 5.3.0 Copyright (C) 2015 Free Software Foundation, Inc. echo $CXX /usr/local/bin/g++ ./configure --------------------------------------------- CMake 3.5.0-rc1, Copyright 2000-2016 Kitware, Inc. C compiler on this system is: cc --------------------------------------------- Error when bootstrapping CMake: Cannot find appropriate C++ compiler on this system. Please specify one using environment variable CXX. See cmake_bootstrap.log for compilers attempted. --------------------------------------------- Log of errors: /da/coding/download/cmake-3.5.0-rc1/Bootstrap.cmk/cmake_bootstrap.log --------------------------------------------- When I look into the log file: I found the location and the reason for the failure: cmake_bootstrap_12256_test.cxx:5:23: fatal error: iostream.h: No such file or directory compilation terminated. Test failed to compile Try: /usr/local/bin/g++ Line: /usr/local/bin/g++ -DTEST3 cmake_bootstrap_12256_test.cxx -o cmake_bootstrap_12256_test ==== it is not using the include directory: /usr/local/include/c++/5.3.0 CPLUS_INCLUDE_PATH=/usr/local/include/c++/5.3.0 the configuration script should add this variable to the make file. Steps to Reproduce: You need to install the gcc to /usr/local Additional Information: It is the -I$CPLUS_INCLUDE_PATH that is not being used by cmake ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-02 17:51 Kemin Zhou New Issue ====================================================================== From brad.king at kitware.com Wed Feb 3 11:16:57 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 3 Feb 2016 11:16:57 -0500 Subject: [cmake-developers] [PATCH] Added FILTER subcommand to list command In-Reply-To: <1454016550-4646-1-git-send-email-ashley@awhetter.co.uk> References: <1452964207-31271-1-git-send-email-ashley@awhetter.co.uk> <1454016550-4646-1-git-send-email-ashley@awhetter.co.uk> Message-ID: <56B227F9.1050007@kitware.com> On 01/28/2016 04:29 PM, Ashley Whetter wrote: > Taking the previous comments into consideration Nice work. Applied: list: Add FILTER subcommand (#3986) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0205f882 > I opted for > list(FILTER REGEX ) > rather than > list(FILTER REGEX ) > because I think that it reads more nicely this way around. Yes, I agree. Thanks! -Brad From arankin at robarts.ca Wed Feb 3 12:47:07 2016 From: arankin at robarts.ca (Adam Rankin) Date: Wed, 3 Feb 2016 17:47:07 +0000 Subject: [cmake-developers] [partial duplicate of users mailing list] SelectLibraryConfigurations Message-ID: <31b4aefab97e429d966f41b1532b1a81@dag2.robarts.ca> Hello all, I am exploring FindZLIB.cmake and FindPNG.cmake and they both use SelectLibraryConfigurations.cmake. The macro in this file populates xyz_LIBRARIES with library file locations. I am wondering if it should not be populating _LIBRARIES variable with target names? Can it even possibly resolve target names from library files? If not, should _LIBRARIES not be set by this macro? Thanks, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Feb 3 12:54:40 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 3 Feb 2016 12:54:40 -0500 Subject: [cmake-developers] [partial duplicate of users mailing list] SelectLibraryConfigurations In-Reply-To: <31b4aefab97e429d966f41b1532b1a81@dag2.robarts.ca> References: <31b4aefab97e429d966f41b1532b1a81@dag2.robarts.ca> Message-ID: <56B23EE0.6050502@kitware.com> On 02/03/2016 12:47 PM, Adam Rankin wrote: > I am wondering if it should not be populating _LIBRARIES variable > with target names? The _LIBRARIES variables are essentially the legacy interface to modules that provide imported targets. Clients should choose to use the imported targets explicitly. -Brad From arankin at robarts.ca Wed Feb 3 13:03:41 2016 From: arankin at robarts.ca (Adam Rankin) Date: Wed, 3 Feb 2016 18:03:41 +0000 Subject: [cmake-developers] [partial duplicate of users mailing list] SelectLibraryConfigurations In-Reply-To: <56B23EE0.6050502@kitware.com> References: <31b4aefab97e429d966f41b1532b1a81@dag2.robarts.ca>, <56B23EE0.6050502@kitware.com> Message-ID: Ok, I admit I'm just diving into cmake internals so I'm still catching up. Is there documentation on best practices for writing findxyz modules? How does a client determine the target names that are imported after calling find_package? Thanks for the help, I'm happy to do my learning by reading if you have any recommended resources. Cheers, Adam > On Feb 3, 2016, at 12:54 PM, Brad King wrote: > >> On 02/03/2016 12:47 PM, Adam Rankin wrote: >> I am wondering if it should not be populating _LIBRARIES variable >> with target names? > > The _LIBRARIES variables are essentially the legacy interface to > modules that provide imported targets. Clients should choose to > use the imported targets explicitly. > > -Brad > From brad.king at kitware.com Wed Feb 3 13:35:49 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 3 Feb 2016 13:35:49 -0500 Subject: [cmake-developers] [partial duplicate of users mailing list] SelectLibraryConfigurations In-Reply-To: References: <31b4aefab97e429d966f41b1532b1a81@dag2.robarts.ca> <56B23EE0.6050502@kitware.com> Message-ID: <56B24885.9060400@kitware.com> On 02/03/2016 01:03 PM, Adam Rankin wrote: > Is there documentation on best practices for writing findxyz modules? There is a section in the cmake-developer manual: https://cmake.org/cmake/help/v3.5/manual/cmake-developer.7.html#find-modules > How does a client determine the target names that are imported after > calling find_package? Client authors should read the module documentation, just as they might to see the list of provided variables. -Brad From brad.king at kitware.com Wed Feb 3 14:31:43 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 3 Feb 2016 14:31:43 -0500 Subject: [cmake-developers] install(EXCLUDE_FROM_ALL) new feature - request for comment In-Reply-To: References: Message-ID: <56B2559F.8030205@kitware.com> On 02/01/2016 05:01 AM, Nick Lewis wrote: > https://cmake.org/Bug/view.php?id=14921 Thanks. Actually my request in the issue tracker to post here was meant to have the actual patch file attached so people can see it without digging through the messages and attachments there. Patch revisions or new patches can be attached in responses within the thread. Anyway, I've applied the "correction2" patch from the issue tracker, applied it, and followed up with some test cases. I merged the topic to 'next' for testing: install: Add EXCLUDE_FROM_ALL option (#14921) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0b6c4729 Tests: Add cases for install() command EXCLUDE_FROM_ALL option https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=670fa897 Help: Add notes for topic 'install-EXCLUDE_FROM_ALL' https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cee30e16 but it is not ready for 'master' yet. Please look at extending the Tests/RunCMake/install test with cases for more install command signatures. Please also update the Help/command/install.rst file documentation to mention the option in all signatures where it is supported and add a list entry for it among the main options at the top. Since I've already applied the original patch, please provide these updates as new patches that I can apply on top. Commit locally in Git and use `git format-patch ...` to produce patch files to attach here. Thanks, -Brad From arankin at robarts.ca Wed Feb 3 14:39:21 2016 From: arankin at robarts.ca (Adam Rankin) Date: Wed, 3 Feb 2016 19:39:21 +0000 Subject: [cmake-developers] [partial duplicate of users mailing list] SelectLibraryConfigurations In-Reply-To: <56B24885.9060400@kitware.com> References: <31b4aefab97e429d966f41b1532b1a81@dag2.robarts.ca> <56B23EE0.6050502@kitware.com> <56B24885.9060400@kitware.com> Message-ID: Ah, gotcha. So, is it expected that each project in a client's package will call find_package(xyz)? I am used to the top level CMakeLists finding all the dependencies, and then passing the information down into projects. I am happy to update our system behavior to match what is more correct. Adam -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Wednesday, February 03, 2016 1:36 PM To: Adam Rankin Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [partial duplicate of users mailing list] SelectLibraryConfigurations On 02/03/2016 01:03 PM, Adam Rankin wrote: > Is there documentation on best practices for writing findxyz modules? There is a section in the cmake-developer manual: https://cmake.org/cmake/help/v3.5/manual/cmake-developer.7.html#find-modules > How does a client determine the target names that are imported after > calling find_package? Client authors should read the module documentation, just as they might to see the list of provided variables. -Brad From ewmailing at gmail.com Wed Feb 3 15:48:35 2016 From: ewmailing at gmail.com (Eric Wing) Date: Wed, 3 Feb 2016 12:48:35 -0800 Subject: [cmake-developers] [ANNOUNCE] CMake 3.5.0-rc1 now ready for testing! In-Reply-To: References: Message-ID: Hi, I'm curious about this. Would you explain the difference between the .msi and the installer? (I don't have a very good understanding of Windows installers.) What are the trade-offs, if any? Was the old installer using NSIS? What is the .msi using? Does this mean CPack can build .msi now? Thanks! From brad.king at kitware.com Wed Feb 3 16:16:40 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 3 Feb 2016 16:16:40 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake 3.5.0-rc1 now ready for testing! In-Reply-To: References: Message-ID: <56B26E38.7090704@kitware.com> On 02/03/2016 03:48 PM, Eric Wing wrote: > Hi, I'm curious about this. Would you explain the difference between > the .msi and the installer? The .exe was a NSIS-generated installer tool. There were several bugs in it caused by problems with NSIS, but worst is that it could wipe out long PATH environment variables. The .msi is more like a .deb or .rpm but that is managed by the Windows Installer Service. > Was the old installer using NSIS? Yes. > What is the .msi using? Does this mean CPack can build .msi now? CPack now has a WiX generator, and WiX produces a .msi. -Brad From brad.king at kitware.com Wed Feb 3 16:17:50 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 3 Feb 2016 16:17:50 -0500 Subject: [cmake-developers] install(EXCLUDE_FROM_ALL) new feature - request for comment In-Reply-To: <56B2559F.8030205@kitware.com> References: <56B2559F.8030205@kitware.com> Message-ID: <56B26E7E.2060602@kitware.com> On 02/03/2016 02:31 PM, Brad King wrote: > install: Add EXCLUDE_FROM_ALL option (#14921) > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0b6c4729 > > Tests: Add cases for install() command EXCLUDE_FROM_ALL option > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=670fa897 I've had to revert it from 'next' pending some corrections to how the test infrastructure checks the installation results to work more portably. I'll respond again once that is fixed and the topic draft is restored. Meanwhile please work on the documentation updates. Thanks, -Brad From konstantin at podsvirov.pro Wed Feb 3 16:28:10 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 04 Feb 2016 00:28:10 +0300 Subject: [cmake-developers] [CMake] CMake 3.5.0-rc1 install is missing dependencies In-Reply-To: <56B248AD.5060900@kitware.com> References: <6ee60740ae1149f7b0e8be4e09d3a146@EXG13-P-MBX09.win.lanl.gov> <56B248AD.5060900@kitware.com> Message-ID: <2143941454534890@web21j.yandex.ru> Meet the fresh update online installers (CMake3.5.3.5.20160203): http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe and http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe If you have used them previously, then just update via "CMake Maintenance Tool". These installers were collected and razvernut using AppVeyor: https://ci.appveyor.com/project/podsvirov/cmake/build/3.5-26 03.02.2016, 21:36, "Brad King" : > On 02/03/2016 11:19 AM, Thompson, KT wrote: >> The Windows installation doesn't appear to provide all the >> required dependencies. ?cmake-gui? will not launch and provides >> the error ?Qt5Widgets.dll is missing form your computer.? > > Ugh, after months of working correctly on the nightly binary builds > something happened to go wrong on the packaging machine specifically > for this release build due to an environment change. I've fixed it > and replaced the binary on the download site for the Windows build. > Please download and try again. > > -Brad I tried the installer: https://cmake.org/files/v3.5/cmake-3.5.0-rc1-win32-x86.msi He asked me to install CMake on your way: C:\Program Files (x86)\Canon\Easy-WebPrint EX\ :-) (something and somewhere went wrong...) I changed to: C:\Program Files (x86)\CMake\ And installed as usual. In the Start menu I have a folder of CMake (although the old NSIS installer would create a folder CMake 3.5.0-rc1) I then used just installed cmake to create installers based on IFW generator. I built these offline installers: http://ifw.podsvirov.pro/cmake/files/v3.5/cmake-3.5.0-rc1-win32-x86.exe and http://ifw.podsvirov.pro/cmake/files/v3.5/cmake-3.5.0-rc1-win64-x64.exe In all cases I was using MSVC2013 and Qt5.5.1 for cmake-gui. For me everything works fine. I ask all those interested. To test the results and to share lessons learned. Together we will make CMake better!!! Regards, Konstantin Podsvirov From foss at grueninger.de Wed Feb 3 17:25:52 2016 From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=) Date: Wed, 3 Feb 2016 23:25:52 +0100 Subject: [cmake-developers] Use unsigned int for cmLinkInterface:: and cmGeneratorTarget::Multiplicity In-Reply-To: <56AF7EEC.4060202@kitware.com> References: <56ABEB2F.2000904@grueninger.de> <56AF7EEC.4060202@kitware.com> Message-ID: <56B27E70.5060101@grueninger.de> Dear Brad, thanks for your advice. An accoring patch is attached. > There is no reason to have negative values for that, so please update > both cmLinkInterface::Multiplicity and cmGeneratorTarget::Multiplicity > to use `unsigned int` and follow through with any further changes > needed for that (I don't think there are any but have not checked). There is a comparison to "count", which triggered another warning. I have fixed that one, too. Bye Christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-cmLinkInterface-and-cmGeneratorTarget-Multiplic.patch Type: text/x-patch Size: 1947 bytes Desc: not available URL: From mantis at public.kitware.com Wed Feb 3 20:13:49 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 3 Feb 2016 20:13:49 -0500 Subject: [cmake-developers] [CMake 0015952]: '$' becomes '$$' in compile_commands.json Message-ID: <2af835fa6d9912d69072822785228f83@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15952 ====================================================================== Reported By: Chaoren Lin Assigned To: ====================================================================== Project: CMake Issue ID: 15952 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-03 20:13 EST Last Modified: 2016-02-03 20:13 EST ====================================================================== Summary: '$' becomes '$$' in compile_commands.json Description: If your compile command contains a '$' character, it'll be incorrectly emitted as '$$' in compile_commands.json if CMAKE_EXPORT_COMPILE_COMMANDS is enabled. Steps to Reproduce: 1) extract example.zip 2) cd example && cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=True . 3) make VERBOSE=1 4) see that the compile command is /usr/bin/cc -DFOO="\"\$\"" -o CMakeFiles/foo.dir/foo.c.o -c /tmp/cmake/foo.c 5) open up compile_commands.json 6) see "command": "/usr/bin/cc -DFOO=\"\\\"\\$$\\\"\" -o CMakeFiles/foo.dir/foo.c.o -c /tmp/cmake/foo.c" which is wrong, since it should be $ instead of $$. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-03 20:13 Chaoren Lin New Issue 2016-02-03 20:13 Chaoren Lin File Added: example.zip ====================================================================== From mantis at public.kitware.com Thu Feb 4 03:14:14 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 4 Feb 2016 03:14:14 -0500 Subject: [cmake-developers] [CMake 0015953]: CMake Does Not Use -isystem with GCC on OS X Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15953 ====================================================================== Reported By: jbauer Assigned To: ====================================================================== Project: CMake Issue ID: 15953 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-04 03:14 EST Last Modified: 2016-02-04 03:14 EST ====================================================================== Summary: CMake Does Not Use -isystem with GCC on OS X Description: On OS X with the GCC compiler, CMake does not pass the -isystem flag to build commands for libraries configured with SYSTEM. For example, if target 'cmake_test' has an include added as 'target_include_directories( cmake_test SYSTEM PRIVATE ${PNG_INCLUDE_DIRS} )', -isystem will not be added on OS X with GCC. Steps to Reproduce: Use the 'target_include_directories' command with the SYSTEM option on OS X with GCC. A minimal project that reproduces this issue has been provided via: https://github.com/digitalriptide/cmake_test ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-04 03:14 jbauer New Issue ====================================================================== From nick.lewis at amag.com Thu Feb 4 04:55:57 2016 From: nick.lewis at amag.com (Nick Lewis) Date: Thu, 4 Feb 2016 09:55:57 +0000 Subject: [cmake-developers] install(EXCLUDE_FROM_ALL) new feature - request for comment In-Reply-To: <56B26E7E.2060602@kitware.com> References: <56B2559F.8030205@kitware.com> <56B26E7E.2060602@kitware.com> Message-ID: Brad Thank you for looking at adding this feature to 'next'. I am not familiar with git format-patch but i hope you can make use of the attached patch for ??Help/command/install.rst Best regards Nick?? On Wed, Feb 3, 2016 at 9:17 PM, Brad King wrote: > On 02/03/2016 02:31 PM, Brad King wrote: > > install: Add EXCLUDE_FROM_ALL option (#14921) > > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0b6c4729 > > > > Tests: Add cases for install() command EXCLUDE_FROM_ALL option > > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=670fa897 > > I've had to revert it from 'next' pending some corrections to how > the test infrastructure checks the installation results to work > more portably. I'll respond again once that is fixed and the > topic draft is restored. Meanwhile please work on the documentation > updates. > > Thanks, > -Brad > > -- Nick Lewis nick.lewis at amag.com +44 1684 277137 <+441684277137> www.amag.com AMAG Technology, Challenge House, International Drive, Tewkesbury Business Park, TEWKESBURY, GL20 8UQ, U.K. -- This company is part of the G4S group of companies. This communication contains information which may be confidential, personal and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sender and the Company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity. This message has been checked for viruses on behalf of the Company. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_install_exclude_doc.patch Type: text/x-diff Size: 2473 bytes Desc: not available URL: From gang65 at poczta.onet.pl Thu Feb 4 05:17:16 2016 From: gang65 at poczta.onet.pl (Bartosz Kosiorek) Date: Thu, 4 Feb 2016 11:17:16 +0100 Subject: [cmake-developers] [ANNOUNCE] CMake 3.5.0-rc1 now ready for testing! In-Reply-To: References: Message-ID: Hi I just started testing 3.5.0-rc1 on Linux and I noticed regression in Makefile generation time. I checked 3.5.0rc1, 3.4.3 and 3.2.2 versions, and the results are as follows: 64bit cmake 3.5.0-rc1 Makefile Generation 1. Run real 2m36.457s user 2m32.008s sys 0m3.184s 2. Run real 2m36.764s user 2m31.672s sys 0m3.296s 64bit cmake 3.4.3 Makefile Generation 1. Run real 1m29.679s user 1m24.696s sys 0m2.920s 2. Run real 1m28.266s user 1m24.220s sys 0m2.976s 64bit cmake 3.2.2 Makefile Generation 1. Run real 1m57.894s user 1m54.160s sys 0m2.320s 2. Run real 1m57.083s user 1m53.076s sys 0m2.304s Is it known issue? Do you have suspects what could cause this regression? Best Regards Bartosz 2016-02-02 22:56 GMT+01:00 Robert Maynard : > I am proud to announce the first CMake 3.5 release candidate. > > Sources and binaries are available at: > https://cmake.org/download/ > > Documentation is available at: > https://cmake.org/cmake/help/v3.5 > > Release notes appear below and are also published at > https://cmake.org/cmake/help/v3.5/release/3.5.html > > Some of the more significant features of CMake 3.5 are: > > * The precompiled Windows binary provided on "cmake.org" is now a > ".msi" package instead of an installer executable. One may need to > manually uninstall CMake versions lower than 3.5 before installing > the new package. > > * The "cmake-gui(1)" learned an option to set the toolset to be used > with VS IDE and Xcode generators, much like the existing "-T" option > to "cmake(1)". > > * Find modules for Boost, FLEX, GTest, GTK2, PNG, TIFF, and XercesC > now provide imported targets. > > * The "FindOpenMP" module learned to support Clang. > > * A new platform file for cross-compiling in the Cray Linux > Environment to target compute nodes was added. See Cross Compiling > for the Cray Linux Environment for usage details. > > * The "Compile Features" functionality is now aware of features > supported by Clang compilers on Windows (MinGW). > > * Support was added for the ARM Compiler (arm.com) with compiler id > "ARMCC". > > * When building for embedded Apple platforms like iOS CMake learned > to build and install combined targets which contain both a device > and a simulator build. This behavior can be enabled by setting the > "IOS_INSTALL_COMBINED" target property. > > * The "CPackDMG" module learned new variable to specify AppleScript > file run to customize appearance of "DragNDrop" installer folder, > including background image setting using supplied PNG or multi- > resolution TIFF file. See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and > "CPACK_DMG_BACKGROUND_IMAGE" variables. > > Deprecated and Removed Features: > > * The "CMakeForceCompiler" module and its macros are now deprecated. > See module documentation for an explanation. > > * The "cmake(1)" "-E time" command now properly passes arguments > with spaces or special characters through to the child process. > This may break scripts that worked around the bug with their own > extra quoting or escaping. > > > > CMake 3.5 Release Notes > *********************** > > Changes made since CMake 3.4 include the following. > > > New Features > ============ > > > GUI > --- > > * The "cmake-gui(1)" gained options to control warnings about > deprecated functionality. > > * The "cmake-gui(1)" learned an option to set the toolset to be used > with VS IDE and Xcode generators, much like the existing "-T" option > to "cmake(1)". > > * The "cmake-gui(1)" gained a Regular Expression Explorer which may > be used to create and evaluate regular expressions in real-time. The > explorer window is available via the "Tools" menu. > > > Command-Line > ------------ > > * The "-Wdev" and "-Wno-dev" "cmake(1)" options now also enable and > suppress the deprecated warnings output by default. > > * The suppression of developer warnings as errors can now be > controlled with the new "-Werror=dev" and "-Wno-error=dev" > "cmake(1)" options. > > * The "cmake(1)" "-E" command-line tools "copy", > "copy_if_different", "copy_directory", and "make_directory" learned > to support multiple input files or directories. > > > Commands > -------- > > * The "cmake_parse_arguments()" command is now implemented natively. > The "CMakeParseArguments" module remains as an empty placeholder for > compatibility. > > * The "install(DIRECTORY)" command learned to support "generator > expressions" in the list of directories. > > > Variables > --------- > > * The "CMAKE_ERROR_DEPRECATED" variable can now be set using the > "-Werror=deprecated" and "-Wno-error=deprecated" "cmake(1)" options. > > * The "CMAKE_WARN_DEPRECATED" variable can now be set using the > "-Wdeprecated" and "-Wno-deprecated" "cmake(1)" options. > > > Properties > ---------- > > * The "VS_GLOBAL_" target property is now implemented for > VS 2010 and above. Previously it worked only in VS 2008 and below. > > > Modules > ------- > > * The "ExternalProject" module learned a new "GIT_REMOTE_NAME" > option to control the "git clone --origin" value. > > * The "FindBoost" module now provides imported targets such as > "Boost::boost" and "Boost::filesystem". > > * The "FindFLEX" module "FLEX_TARGET" macro learned a new > "DEFINES_FILE" option to specify a custom output header to be > generated. > > * The "FindGTest" module now provides imported targets. > > * The "FindGTK2" module, when "GTK2_USE_IMPORTED_TARGETS" is > enabled, now sets "GTK2_LIBRARIES" to contain the list of imported > targets instead of the paths to the libraries. Moreover it now sets > a new "GTK2_TARGETS" variable containing all the targets imported. > > * The "FindOpenMP" module learned to support Clang. > > * The "FindOpenSSL" module gained a new "OPENSSL_MSVC_STATIC_RT" > option to search for libraries using the MSVC static runtime. > > * The "FindPNG" module now provides imported targets. > > * The "FindTIFF" module now provides imported targets. > > * A "FindXalanC" module was introduced to find the Apache Xalan-C++ > XSL transform processing library. > > * The "FindXercesC" module now provides imported targets. > > > Platforms > --------- > > * Support was added for the ARM Compiler (arm.com) with compiler id > "ARMCC". > > * A new platform file for cross-compiling in the Cray Linux > Environment to target compute nodes was added. See Cross Compiling > for the Cray Linux Environment for usage details. > > * The "Compile Features" functionality is now aware of features > supported by Clang compilers on Windows (MinGW). > > * When building for embedded Apple platforms like iOS CMake learned > to build and install combined targets which contain both a device > and a simulator build. This behavior can be enabled by setting the > "IOS_INSTALL_COMBINED" target property. > > > CPack > ----- > > * The "CPackDMG" module learned new variable to specify AppleScript > file run to customize appearance of "DragNDrop" installer folder, > including background image setting using supplied PNG or multi- > resolution TIFF file. See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and > "CPACK_DMG_BACKGROUND_IMAGE" variables. > > * The "CPackDeb" module learned to set the optional config file > "Source" field using a monolithic or per-component variable. See > "CPACK_DEBIAN_PACKAGE_SOURCE". > > * The "CPackDeb" module learned to set Package, Section and Priority > control fields per-component. See variables > "CPACK_DEBIAN__PACKAGE_SECTION" and > "CPACK_DEBIAN__PACKAGE_PRIORITY". > > * The "CPack DragNDrop generator" learned to add multi-lingual SLAs > to a DMG which is presented to the user when they try to mount the > DMG. See the "CPACK_DMG_SLA_LANGUAGES" and "CPACK_DMG_SLA_DIR" > variables for details. > > * The "CPackNSIS" module learned new variables to add bitmaps to the > installer. See the "CPACK_NSIS_MUI_WELCOMEFINISHPAGE_BITMAP" and > "CPACK_NSIS_MUI_UNWELCOMEFINISHPAGE_BITMAP" variables. > > * The "CPackRPM" module learned to set Name and Group control fields > per-component. See "CPACK_RPM__PACKAGE_NAME" and > "CPACK_RPM__PACKAGE_GROUP". > > > Other > ----- > > * Warnings about deprecated functionality are now enabled by > default. They may be suppressed with "-Wno-deprecated" or by setting > the "CMAKE_WARN_DEPRECATED" variable to false. > > > Deprecated and Removed Features > =============================== > > * The "CMakeForceCompiler" module and its macros are now deprecated. > See module documentation for an explanation. > > * The "cmake(1)" "-E time" command now properly passes arguments > with spaces or special characters through to the child process. > This may break scripts that worked around the bug with their own > extra quoting or escaping. > > > Other Changes > ============= > > * The "Visual Studio 14 2015" generator learned to map the > "/debug:fastlink" linker flag to the ".vcxproj" file property. > > * The "FindGTK2" module now configures the "GTK2::sigc++" imported > target to enable c++11 on its dependents when using sigc++ 2.5.1 or > higher. > > * The precompiled Windows binary provided on "cmake.org" is now a > ".msi" package instead of an installer executable. One may need to > manually uninstall CMake versions lower than 3.5 before installing > the new package. > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gang65 at poczta.onet.pl Thu Feb 4 07:09:43 2016 From: gang65 at poczta.onet.pl (Bartosz Kosiorek) Date: Thu, 4 Feb 2016 13:09:43 +0100 Subject: [cmake-developers] [ANNOUNCE] CMake 3.5.0-rc1 now ready for testing! In-Reply-To: References: Message-ID: Hi One more thing. There is huge difference in Unix Makefile generation time between 32 vs 64 bit cmake version: 32 bit CMake 3.5.0 generation time: real 5m33.310s user 5m27.268s sys 0m3.540s 64 bit CMake 3.5.0 generation time: real 2m36.457s user 2m32.008s sys 0m3.184s Unfortunately there no 64bit CMake version for Windows: https://cmake.org/download/ Is it possible to create 64 bit build for Windows? Best Regards Bartosz 2016-02-04 11:17 GMT+01:00 Bartosz Kosiorek : > Hi > I just started testing 3.5.0-rc1 on Linux and I noticed regression in > Makefile generation time. > I checked 3.5.0rc1, 3.4.3 and 3.2.2 versions, and the results are as > follows: > > 64bit cmake 3.5.0-rc1 Makefile Generation > 1. Run > real 2m36.457s > user 2m32.008s > sys 0m3.184s > 2. Run > real 2m36.764s > user 2m31.672s > sys 0m3.296s > > > 64bit cmake 3.4.3 Makefile Generation > 1. Run > real 1m29.679s > user 1m24.696s > sys 0m2.920s > 2. Run > real 1m28.266s > user 1m24.220s > sys 0m2.976s > > 64bit cmake 3.2.2 Makefile Generation > 1. Run > real 1m57.894s > user 1m54.160s > sys 0m2.320s > 2. Run > real 1m57.083s > user 1m53.076s > sys 0m2.304s > > Is it known issue? > Do you have suspects what could cause this regression? > > Best Regards > Bartosz > > > 2016-02-02 22:56 GMT+01:00 Robert Maynard : > >> I am proud to announce the first CMake 3.5 release candidate. >> >> Sources and binaries are available at: >> https://cmake.org/download/ >> >> Documentation is available at: >> https://cmake.org/cmake/help/v3.5 >> >> Release notes appear below and are also published at >> https://cmake.org/cmake/help/v3.5/release/3.5.html >> >> Some of the more significant features of CMake 3.5 are: >> >> * The precompiled Windows binary provided on "cmake.org" is now a >> ".msi" package instead of an installer executable. One may need to >> manually uninstall CMake versions lower than 3.5 before installing >> the new package. >> >> * The "cmake-gui(1)" learned an option to set the toolset to be used >> with VS IDE and Xcode generators, much like the existing "-T" option >> to "cmake(1)". >> >> * Find modules for Boost, FLEX, GTest, GTK2, PNG, TIFF, and XercesC >> now provide imported targets. >> >> * The "FindOpenMP" module learned to support Clang. >> >> * A new platform file for cross-compiling in the Cray Linux >> Environment to target compute nodes was added. See Cross Compiling >> for the Cray Linux Environment for usage details. >> >> * The "Compile Features" functionality is now aware of features >> supported by Clang compilers on Windows (MinGW). >> >> * Support was added for the ARM Compiler (arm.com) with compiler id >> "ARMCC". >> >> * When building for embedded Apple platforms like iOS CMake learned >> to build and install combined targets which contain both a device >> and a simulator build. This behavior can be enabled by setting the >> "IOS_INSTALL_COMBINED" target property. >> >> * The "CPackDMG" module learned new variable to specify AppleScript >> file run to customize appearance of "DragNDrop" installer folder, >> including background image setting using supplied PNG or multi- >> resolution TIFF file. See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and >> "CPACK_DMG_BACKGROUND_IMAGE" variables. >> >> Deprecated and Removed Features: >> >> * The "CMakeForceCompiler" module and its macros are now deprecated. >> See module documentation for an explanation. >> >> * The "cmake(1)" "-E time" command now properly passes arguments >> with spaces or special characters through to the child process. >> This may break scripts that worked around the bug with their own >> extra quoting or escaping. >> >> >> >> CMake 3.5 Release Notes >> *********************** >> >> Changes made since CMake 3.4 include the following. >> >> >> New Features >> ============ >> >> >> GUI >> --- >> >> * The "cmake-gui(1)" gained options to control warnings about >> deprecated functionality. >> >> * The "cmake-gui(1)" learned an option to set the toolset to be used >> with VS IDE and Xcode generators, much like the existing "-T" option >> to "cmake(1)". >> >> * The "cmake-gui(1)" gained a Regular Expression Explorer which may >> be used to create and evaluate regular expressions in real-time. The >> explorer window is available via the "Tools" menu. >> >> >> Command-Line >> ------------ >> >> * The "-Wdev" and "-Wno-dev" "cmake(1)" options now also enable and >> suppress the deprecated warnings output by default. >> >> * The suppression of developer warnings as errors can now be >> controlled with the new "-Werror=dev" and "-Wno-error=dev" >> "cmake(1)" options. >> >> * The "cmake(1)" "-E" command-line tools "copy", >> "copy_if_different", "copy_directory", and "make_directory" learned >> to support multiple input files or directories. >> >> >> Commands >> -------- >> >> * The "cmake_parse_arguments()" command is now implemented natively. >> The "CMakeParseArguments" module remains as an empty placeholder for >> compatibility. >> >> * The "install(DIRECTORY)" command learned to support "generator >> expressions" in the list of directories. >> >> >> Variables >> --------- >> >> * The "CMAKE_ERROR_DEPRECATED" variable can now be set using the >> "-Werror=deprecated" and "-Wno-error=deprecated" "cmake(1)" options. >> >> * The "CMAKE_WARN_DEPRECATED" variable can now be set using the >> "-Wdeprecated" and "-Wno-deprecated" "cmake(1)" options. >> >> >> Properties >> ---------- >> >> * The "VS_GLOBAL_" target property is now implemented for >> VS 2010 and above. Previously it worked only in VS 2008 and below. >> >> >> Modules >> ------- >> >> * The "ExternalProject" module learned a new "GIT_REMOTE_NAME" >> option to control the "git clone --origin" value. >> >> * The "FindBoost" module now provides imported targets such as >> "Boost::boost" and "Boost::filesystem". >> >> * The "FindFLEX" module "FLEX_TARGET" macro learned a new >> "DEFINES_FILE" option to specify a custom output header to be >> generated. >> >> * The "FindGTest" module now provides imported targets. >> >> * The "FindGTK2" module, when "GTK2_USE_IMPORTED_TARGETS" is >> enabled, now sets "GTK2_LIBRARIES" to contain the list of imported >> targets instead of the paths to the libraries. Moreover it now sets >> a new "GTK2_TARGETS" variable containing all the targets imported. >> >> * The "FindOpenMP" module learned to support Clang. >> >> * The "FindOpenSSL" module gained a new "OPENSSL_MSVC_STATIC_RT" >> option to search for libraries using the MSVC static runtime. >> >> * The "FindPNG" module now provides imported targets. >> >> * The "FindTIFF" module now provides imported targets. >> >> * A "FindXalanC" module was introduced to find the Apache Xalan-C++ >> XSL transform processing library. >> >> * The "FindXercesC" module now provides imported targets. >> >> >> Platforms >> --------- >> >> * Support was added for the ARM Compiler (arm.com) with compiler id >> "ARMCC". >> >> * A new platform file for cross-compiling in the Cray Linux >> Environment to target compute nodes was added. See Cross Compiling >> for the Cray Linux Environment for usage details. >> >> * The "Compile Features" functionality is now aware of features >> supported by Clang compilers on Windows (MinGW). >> >> * When building for embedded Apple platforms like iOS CMake learned >> to build and install combined targets which contain both a device >> and a simulator build. This behavior can be enabled by setting the >> "IOS_INSTALL_COMBINED" target property. >> >> >> CPack >> ----- >> >> * The "CPackDMG" module learned new variable to specify AppleScript >> file run to customize appearance of "DragNDrop" installer folder, >> including background image setting using supplied PNG or multi- >> resolution TIFF file. See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and >> "CPACK_DMG_BACKGROUND_IMAGE" variables. >> >> * The "CPackDeb" module learned to set the optional config file >> "Source" field using a monolithic or per-component variable. See >> "CPACK_DEBIAN_PACKAGE_SOURCE". >> >> * The "CPackDeb" module learned to set Package, Section and Priority >> control fields per-component. See variables >> "CPACK_DEBIAN__PACKAGE_SECTION" and >> "CPACK_DEBIAN__PACKAGE_PRIORITY". >> >> * The "CPack DragNDrop generator" learned to add multi-lingual SLAs >> to a DMG which is presented to the user when they try to mount the >> DMG. See the "CPACK_DMG_SLA_LANGUAGES" and "CPACK_DMG_SLA_DIR" >> variables for details. >> >> * The "CPackNSIS" module learned new variables to add bitmaps to the >> installer. See the "CPACK_NSIS_MUI_WELCOMEFINISHPAGE_BITMAP" and >> "CPACK_NSIS_MUI_UNWELCOMEFINISHPAGE_BITMAP" variables. >> >> * The "CPackRPM" module learned to set Name and Group control fields >> per-component. See "CPACK_RPM__PACKAGE_NAME" and >> "CPACK_RPM__PACKAGE_GROUP". >> >> >> Other >> ----- >> >> * Warnings about deprecated functionality are now enabled by >> default. They may be suppressed with "-Wno-deprecated" or by setting >> the "CMAKE_WARN_DEPRECATED" variable to false. >> >> >> Deprecated and Removed Features >> =============================== >> >> * The "CMakeForceCompiler" module and its macros are now deprecated. >> See module documentation for an explanation. >> >> * The "cmake(1)" "-E time" command now properly passes arguments >> with spaces or special characters through to the child process. >> This may break scripts that worked around the bug with their own >> extra quoting or escaping. >> >> >> Other Changes >> ============= >> >> * The "Visual Studio 14 2015" generator learned to map the >> "/debug:fastlink" linker flag to the ".vcxproj" file property. >> >> * The "FindGTK2" module now configures the "GTK2::sigc++" imported >> target to enable c++11 on its dependents when using sigc++ 2.5.1 or >> higher. >> >> * The precompiled Windows binary provided on "cmake.org" is now a >> ".msi" package instead of an installer executable. One may need to >> manually uninstall CMake versions lower than 3.5 before installing >> the new package. >> -- >> >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Feb 4 08:30:47 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 4 Feb 2016 08:30:47 -0500 Subject: [cmake-developers] CMake 3.5 generation time (was: CMake 3.5.0-rc1 now ready for testing!) In-Reply-To: References: Message-ID: <56B35287.9010309@kitware.com> On 02/04/2016 07:09 AM, Bartosz Kosiorek wrote: > There is huge difference in Unix Makefile generation time between > 32 vs 64 bit cmake version: > > 32 bit CMake 3.5.0 generation time: > real 5m33.310s > user 5m27.268s > sys 0m3.540s > > 64 bit CMake 3.5.0 generation time: > real 2m36.457s > user 2m32.008s > sys 0m3.184s > > Unfortunately there no 64bit CMake version for Windows: > https://cmake.org/download/ > > Is it possible to create 64 bit build for Windows? Perhaps eventually, but please try running those timings with local builds of CMake on Windows to see if the difference carries across platforms. > 64bit cmake 3.5.0-rc1 Makefile Generation > 1. Run > real 2m36.457s > user 2m32.008s > sys 0m3.184s > 2. Run > real 2m36.764s > user 2m31.672s > sys 0m3.296s > > 64bit cmake 3.4.3 Makefile Generation > 1. Run > real 1m29.679s > user 1m24.696s > sys 0m2.920s > 2. Run > real 1m28.266s > user 1m24.220s > sys 0m2.976s There has been some refactoring but it has not had that effect on projects I've seen. What project are you configuring? Were both of these versions built the same way? Is this consistent when configuring, say, CMake itself? Thanks, -Brad From gang65 at poczta.onet.pl Thu Feb 4 10:29:45 2016 From: gang65 at poczta.onet.pl (Bartosz Kosiorek) Date: Thu, 4 Feb 2016 16:29:45 +0100 Subject: [cmake-developers] CMake 3.5 generation time (was: CMake 3.5.0-rc1 now ready for testing!) In-Reply-To: <56B35287.9010309@kitware.com> References: <56B35287.9010309@kitware.com> Message-ID: Hi Brad. I'm configuring/generating NavKit project, by using -G "Unix Makefiles" parameter. I downloaded cmakes from website: https://cmake.org/download/ All generation were done on clean output (deleted all files generated by cmake) on the same repository version, in the same directory. The only difference was cmake version used for configuring. How I could check what was caused such long times? Best Regards Bartosz 2016-02-04 14:30 GMT+01:00 Brad King : > On 02/04/2016 07:09 AM, Bartosz Kosiorek wrote: > > There is huge difference in Unix Makefile generation time between > > 32 vs 64 bit cmake version: > > > > 32 bit CMake 3.5.0 generation time: > > real 5m33.310s > > user 5m27.268s > > sys 0m3.540s > > > > 64 bit CMake 3.5.0 generation time: > > real 2m36.457s > > user 2m32.008s > > sys 0m3.184s > > > > Unfortunately there no 64bit CMake version for Windows: > > https://cmake.org/download/ > > > > Is it possible to create 64 bit build for Windows? > > Perhaps eventually, but please try running those timings with local > builds of CMake on Windows to see if the difference carries across > platforms. > > > 64bit cmake 3.5.0-rc1 Makefile Generation > > 1. Run > > real 2m36.457s > > user 2m32.008s > > sys 0m3.184s > > 2. Run > > real 2m36.764s > > user 2m31.672s > > sys 0m3.296s > > > > 64bit cmake 3.4.3 Makefile Generation > > 1. Run > > real 1m29.679s > > user 1m24.696s > > sys 0m2.920s > > 2. Run > > real 1m28.266s > > user 1m24.220s > > sys 0m2.976s > > There has been some refactoring but it has not had that effect on > projects I've seen. What project are you configuring? Were both > of these versions built the same way? Is this consistent when > configuring, say, CMake itself? > > Thanks, > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From JamesJ at motionview3d.com Thu Feb 4 11:12:39 2016 From: JamesJ at motionview3d.com (James Johnston) Date: Thu, 4 Feb 2016 16:12:39 -0000 Subject: [cmake-developers] [ANNOUNCE] CMake 3.5.0-rc1 now ready for testing! In-Reply-To: <56B26E38.7090704@kitware.com> References: <56B26E38.7090704@kitware.com> Message-ID: <0d6d01d15f66$df3747e0$9da5d7a0$@motionview3d.com> > -----Original Message----- > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] > On Behalf Of Brad King > Sent: Wednesday, February 03, 2016 21:17 > To: Eric Wing; Robert Maynard > Cc: CMake Developers > Subject: Re: [cmake-developers] [ANNOUNCE] CMake 3.5.0-rc1 now ready > for testing! > > On 02/03/2016 03:48 PM, Eric Wing wrote: > > Hi, I'm curious about this. Would you explain the difference between > > the .msi and the installer? > > The .exe was a NSIS-generated installer tool. There were several bugs in it > caused by problems with NSIS, but worst is that it could wipe out long PATH > environment variables. The .msi is more like a .deb or .rpm but that is > managed by the Windows Installer Service. There's several other reasons as well. Not that I had anything to do with CMake moving to WiX, but I'm happy to see they did: * Windows Installer is transactional. If there's an error or other problem during installation, MSI will roll back the installation - it "just works" for the most part. Whereas with NSIS, offering something as simple as a "Cancel" button is apparently quite difficult: http://nsis.sourceforge.net/InstFiles_Cancel_-_Allowing_a_user_to_cancel_ins tallation_during_InstFiles * Self-healing functionality: if the application installation is damaged, MSI can automatically repair it when launching the application. If you like, you can have it go as far as verify checksums of each file. * MSI is declarative: standardized database schema defines what to install and where - not how to install it. So installs, uninstalls, repairs, recovery from a failed transaction, etc. "just work". The standardized behavior could also help system administrators to customize the installation with existing tools. * MSI packages can be deployed with Active Directory, and non-administrator users can elect to install them while the installation still runs at an elevated level (or the installation can be forced when the system starts or when the user logs in). Nice discussion here: http://serverfault.com/a/274609 Maybe now that CPack supports WiX, more open source projects will start to use it instead of NSIS. :) I only hope they set up the MSIs to support side-by-side installations of multiple CMake versions. I have yet to find time to see if this is the case. Best regards, James Johnston From brad.king at kitware.com Thu Feb 4 12:57:42 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 4 Feb 2016 12:57:42 -0500 Subject: [cmake-developers] CMake 3.5 generation time In-Reply-To: References: <56B35287.9010309@kitware.com> Message-ID: <56B39116.3090101@kitware.com> On 02/04/2016 10:29 AM, Bartosz Kosiorek wrote: > I downloaded cmakes from website: > https://cmake.org/download/ > > All generation were done on clean output (deleted all files generated by cmake) > on the same repository version, in the same directory. > The only difference was cmake version used for configuring. > > How I could check what was caused such long times? Try also timing the second and third runs on a single build tree to get timings without all the platform introspection tests. You could clone the CMake Git repository, build from source with -DCMAKE_BUILD_TYPE=RelWithDebInfo and then run it through a profiler (e.g. valgrind --tool=callgrind). Alternatively you could `git bisect` between v3.4.3 and v3.5.0-rc1 to see if there is a small range of commits that causes the regression. That could really help narrow it down. Thanks, -Brad From brad.king at kitware.com Thu Feb 4 12:57:58 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 4 Feb 2016 12:57:58 -0500 Subject: [cmake-developers] Use unsigned int for cmLinkInterface:: and cmGeneratorTarget::Multiplicity In-Reply-To: <56B27E70.5060101@grueninger.de> References: <56ABEB2F.2000904@grueninger.de> <56AF7EEC.4060202@kitware.com> <56B27E70.5060101@grueninger.de> Message-ID: <56B39126.5030805@kitware.com> On 02/03/2016 05:25 PM, Christoph Gr?ninger wrote: > thanks for your advice. An accoring patch is attached. Thanks, applied: Make cmLinkInterface:: and cmGeneratorTarget::Multiplicity unsigned ints https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=58a4a771 -Brad From brad.king at kitware.com Thu Feb 4 12:59:16 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 4 Feb 2016 12:59:16 -0500 Subject: [cmake-developers] install(EXCLUDE_FROM_ALL) new feature - request for comment In-Reply-To: References: <56B2559F.8030205@kitware.com> <56B26E7E.2060602@kitware.com> Message-ID: <56B39174.7070906@kitware.com> On 02/04/2016 04:55 AM, Nick Lewis wrote: > I am not familiar with git format-patch After committing locally just run git format-patch HEAD~1.. to construct the patch file. The "~1" specifies the number of commits to go back (via first-parent) and include in the series. > make use of the attached patch for ??Help/command/install.rst Thanks. I integrated that in to my revised form of the topic. I've merged it to 'next' for testing again: install: Add EXCLUDE_FROM_ALL option (#14921) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=18ce97c4 Tests: Add cases for install() command EXCLUDE_FROM_ALL option https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d321c196 Help: Add notes for topic 'install-EXCLUDE_FROM_ALL' https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=586e56d0 Please look at extending the tests added by the second commit to cover more install() command signatures. Thanks, -Brad From brad.king at kitware.com Thu Feb 4 13:00:16 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 4 Feb 2016 13:00:16 -0500 Subject: [cmake-developers] [partial duplicate of users mailing list] SelectLibraryConfigurations In-Reply-To: References: <31b4aefab97e429d966f41b1532b1a81@dag2.robarts.ca> <56B23EE0.6050502@kitware.com> <56B24885.9060400@kitware.com> Message-ID: <56B391B0.6050701@kitware.com> On 02/03/2016 02:39 PM, Adam Rankin wrote: > So, is it expected that each project in a client's package > will call find_package(xyz)? > I am used to the top level CMakeLists finding all the dependencies, > and then passing the information down into projects. After calling find_package(xyz) the imported targets will be visible in the directory where the call is made and below for use with target_link_libraries. The top level is sufficient but not always necessary. Transitive dependencies will still be followed across directories even if the final dependent cannot see the imported target directly. -Brad From brad.king at kitware.com Thu Feb 4 13:08:06 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 4 Feb 2016 13:08:06 -0500 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: References: <568FE434.1020501@kitware.com> <569556D8.80308@kitware.com> <5696683B.2050703@kitware.com> <5697EF44.60001@kitware.com> <5699597B.80108@kitware.com> <569E644B.2020404@kitware.com> <569FA49B.2070005@kitware.com> Message-ID: <56B39386.1000709@kitware.com> On 01/29/2016 03:16 PM, Eric Wing wrote: > I need more guidance here. I'm not connecting the dots. > My problem seems to be that the execute_process() in > CMakeDetermineCompilerId.cmake is trying to invoke the command: > 'swift CompilerId/main.swift' [snip] > Looking at the execute_process() that gets invoked (final one in the > big if/elseif block of CMAKE_DETERMINE_COMPILER_ID_BUILD), the only > way to get the flags I need are via CMAKE_${lang}_COMPILER_ID_FLAGS. Some refactoring may be needed to allow language-specific behavior to add flags that must be there for the check. Add an explicit internal variable or other code path to support it (that is just not set for other languages). The semantics of selecting flags from the environment in CMAKE_${lang}_COMPILER_ID_FLAGS must not change. Thanks, -Brad From christian.askeland at gmail.com Thu Feb 4 13:34:46 2016 From: christian.askeland at gmail.com (Christian Askeland) Date: Thu, 4 Feb 2016 19:34:46 +0100 Subject: [cmake-developers] [PATCH] Bug fix: Dylibs inside .framework folders fails in BundleUtilities.cmake. Message-ID: The specific cause is when e.g. /Library/Frameworks/GStreamer.framework/Versions/1.0/lib/libgio-2.0.0.dylib is detected by fixup_bundle. BundleUtilities.cmake/set_bundle_key_values() interprets this as a framework, thus doing a string replace that creates an embedded_item that is equal to the original path, i.e. it is not embedded. The fix is to rely on the correct framework detection in GetPrerequisite.cmake/gp_item_default_embedded_path() instead. --- Modules/BundleUtilities.cmake | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 45dda40..0a92251 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -479,7 +479,8 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) get_item_rpaths("${resolved_item}" item_rpaths) - if(item MATCHES "[^/]+\\.framework/") + # Use default_embedded_path from gp_item_default_embedded_path() to query whether the item is a framework + if(default_embedded_path MATCHES "/Frameworks") # For frameworks, construct the name under the embedded path from the # opening "${item_name}.framework/" to the closing "/${item_name}": # -- 2.5.4 (Apple Git-61) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gang65 at poczta.onet.pl Thu Feb 4 14:56:42 2016 From: gang65 at poczta.onet.pl (Bartosz Kosiorek) Date: Thu, 4 Feb 2016 20:56:42 +0100 Subject: [cmake-developers] CMake 3.5 generation time In-Reply-To: <56B39116.3090101@kitware.com> References: <56B35287.9010309@kitware.com> <56B39116.3090101@kitware.com> Message-ID: Hi. I would like to mention that all my previous times, was measured for clean Generation (I deleted all generation files) I will try to make bisect build, to check where regression occur. Now I would like to present results with enabled cleaning only on first run: CMake 3.4.3 Unix Makefile generation 1. Clean run (rm -rf Output) real 1m31.233s user 1m26.136s sys 0m3.004s 2. Dirty run (no deletion) real 1m27.101s user 1m24.620s sys 0m2.988s 3. Dirty run (no deletion) real 1m26.237s user 1m23.240s sys 0m3.020s 4. Dirty run (no deletion) real 1m27.670s user 1m24.764s sys 0m2.816s CMake 3.5.0-rc1 Unix Makefile generation 1. Clean run (rm -rf Output) real 2m34.244s user 2m30.176s sys 0m3.220s 2. Dirty run (no deletion) real 2m35.259s user 2m32.400s sys 0m3.116s 3. Dirty run (no deletion) real 2m27.881s user 2m25.184s sys 0m3.032s 4. Dirty run (no deletion) real 2m25.139s user 2m22.552s sys 0m2.984s 2016-02-04 18:57 GMT+01:00 Brad King : > On 02/04/2016 10:29 AM, Bartosz Kosiorek wrote: > > I downloaded cmakes from website: > > https://cmake.org/download/ > > > > All generation were done on clean output (deleted all files generated by > cmake) > > on the same repository version, in the same directory. > > The only difference was cmake version used for configuring. > > > > How I could check what was caused such long times? > > Try also timing the second and third runs on a single build tree > to get timings without all the platform introspection tests. > > You could clone the CMake Git repository, build from source with > -DCMAKE_BUILD_TYPE=RelWithDebInfo and then run it through a > profiler (e.g. valgrind --tool=callgrind). Alternatively you > could `git bisect` between v3.4.3 and v3.5.0-rc1 to see if there > is a small range of commits that causes the regression. That > could really help narrow it down. > > Thanks, > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gang65 at poczta.onet.pl Thu Feb 4 17:57:36 2016 From: gang65 at poczta.onet.pl (Bartosz Kosiorek) Date: Thu, 4 Feb 2016 23:57:36 +0100 Subject: [cmake-developers] CMake 3.5 generation time In-Reply-To: References: <56B35287.9010309@kitware.com> <56B39116.3090101@kitware.com> Message-ID: Hi Brad Unfortunately after building locally, the times are totally different (worse). I don't know why it is happen. Builds for some specific commits, are not able to run properly. In that case I have just skip bisect commit. Do you have some further recommendation? On master the times are: real 8m1.255s user 7m56.684s sys 0m3.900s Bisection logs: git bisect log git bisect start # bad: [8a8d22cf1e5d20b7c3b32c1ec9b5f06b339c2a50] CMake 3.5.0-rc1 version update git bisect bad 8a8d22cf1e5d20b7c3b32c1ec9b5f06b339c2a50 # good: [0aef6f2412177a236deb292654402518777f3cb0] CMake 3.4.3 git bisect good 0aef6f2412177a236deb292654402518777f3cb0 # skip: [49ac682d39af7fe47e79455827e2e83130193236] Merge topic 'vs-show-def-files' git bisect skip 49ac682d39af7fe47e79455827e2e83130193236 # bad: [e069aa05c6a0d8e89a677fa4f00d33432191eeaa] Merge topic 'regex-explorer' git bisect bad e069aa05c6a0d8e89a677fa4f00d33432191eeaa # good: [a03c13a710fc4c65035e92749720b559cbeeff2e] CMake Nightly Date Stamp git bisect good a03c13a710fc4c65035e92749720b559cbeeff2e # skip: [59315f5b0028e4f9c4fde765196c4df38ab83b3e] Merge topic 'cpack-deb-compression-scheme-test' git bisect skip 59315f5b0028e4f9c4fde765196c4df38ab83b3e # bad: [48182afd3d04cc659fc5d86ab65b403d8a2b8eff] CMake Nightly Date Stamp git bisect bad 48182afd3d04cc659fc5d86ab65b403d8a2b8eff # skip: [1e8c920d0409770214a4ff517f6a4c31b9830f45] Merge topic 'use-generator-target' git bisect skip 1e8c920d0409770214a4ff517f6a4c31b9830f45 # good: [cf69630e510a5c639a93a99b315fcefea9688935] cmGeneratorTarget: Move GetFrameworkVersion from cmTarget git bisect good cf69630e510a5c639a93a99b315fcefea9688935 # skip: [1bfb527f561c705169f0716108e34a2b5ba5c8bb] FindPkgConfig: return actual error when a package is not found (#15810) git bisect skip 1bfb527f561c705169f0716108e34a2b5ba5c8bb Bisection results: # good: [cf69630e510a5c639a93a99b315fcefea9688935] cmGeneratorTarget: Move GetFrameworkVersion from cmTarget real 3m52.078s user 3m47.508s sys 0m4.240s # bad: [48182afd3d04cc659fc5d86ab65b403d8a2b8eff] CMake Nightly Date Stamp real 12m6.370s user 12m2.872s sys 0m4.392s # good: [a03c13a710fc4c65035e92749720b559cbeeff2e] CMake Nightly Date Stamp real 3m54.556s user 3m44.596s sys 0m4.284s # bad: [e069aa05c6a0d8e89a677fa4f00d33432191eeaa] Merge topic 'regex-explorer' real 12m36.866s user 12m31.864s sys 0m4.348s # good: [d233030f5bcfe2509b82433f7df6383cd301e34e] cmGeneratorTarget: Port implementation to cmGeneratorTarget. git bisect bad d233030f5bcfe2509b82433f7df6383cd301e34e 1. First clean generation real 3m40.716s user 3m34.908s sys 0m3.944s 2. Second clean generation real 3m41.351s user 3m36.880s sys 0m3.872s 2016-02-04 20:56 GMT+01:00 Bartosz Kosiorek : > Hi. > I would like to mention that all my previous times, was measured for clean > Generation (I deleted all generation files) > I will try to make bisect build, to check where regression occur. > > Now I would like to present results with enabled cleaning only on first > run: > > CMake 3.4.3 Unix Makefile generation > 1. Clean run (rm -rf Output) > real 1m31.233s > user 1m26.136s > sys 0m3.004s > 2. Dirty run (no deletion) > real 1m27.101s > user 1m24.620s > sys 0m2.988s > 3. Dirty run (no deletion) > real 1m26.237s > user 1m23.240s > sys 0m3.020s > 4. Dirty run (no deletion) > real 1m27.670s > user 1m24.764s > sys 0m2.816s > > CMake 3.5.0-rc1 Unix Makefile generation > 1. Clean run (rm -rf Output) > real 2m34.244s > user 2m30.176s > sys 0m3.220s > 2. Dirty run (no deletion) > real 2m35.259s > user 2m32.400s > sys 0m3.116s > 3. Dirty run (no deletion) > real 2m27.881s > user 2m25.184s > sys 0m3.032s > 4. Dirty run (no deletion) > real 2m25.139s > user 2m22.552s > sys 0m2.984s > > 2016-02-04 18:57 GMT+01:00 Brad King : > >> On 02/04/2016 10:29 AM, Bartosz Kosiorek wrote: >> > I downloaded cmakes from website: >> > https://cmake.org/download/ >> > >> > All generation were done on clean output (deleted all files generated >> by cmake) >> > on the same repository version, in the same directory. >> > The only difference was cmake version used for configuring. >> > >> > How I could check what was caused such long times? >> >> Try also timing the second and third runs on a single build tree >> to get timings without all the platform introspection tests. >> >> You could clone the CMake Git repository, build from source with >> -DCMAKE_BUILD_TYPE=RelWithDebInfo and then run it through a >> profiler (e.g. valgrind --tool=callgrind). Alternatively you >> could `git bisect` between v3.4.3 and v3.5.0-rc1 to see if there >> is a small range of commits that causes the regression. That >> could really help narrow it down. >> >> Thanks, >> -Brad >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Thu Feb 4 21:00:49 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 4 Feb 2016 21:00:49 -0500 Subject: [cmake-developers] [CMake 0015954]: Ninja generated superbuilds do not reinstall dependent projects Message-ID: <14be5e586f1d9de394b3f7da1b324495@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15954 ====================================================================== Reported By: logan.buchy Assigned To: ====================================================================== Project: CMake Issue ID: 15954 Category: (No Category) Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-04 21:00 EST Last Modified: 2016-02-04 21:00 EST ====================================================================== Summary: Ninja generated superbuilds do not reinstall dependent projects Description: The Make and Ninja generators behave quite differently when dealing with ExternalProjects. I wanted to document the Ninja behaviour here since I would consider it buggy/un-intuitive. Suppose we have a 'superbuild' project that has a hierarchy like this: . ??? bar ??? ??? CMakeLists.txt ??? ??? main.cpp ??? CMakeLists.txt ??? foo ??? CMakeLists.txt ??? include/ ??? src/ The top-level cmake file sets up two external projects, foo and bar. bar depends on foo. The foo project installs libraries into a staging path and bar pulls the configuration from that path to import the foo library (and headers). If I use the make generator and build from the top cmake file. I see that foo is built and installed, then bar is built and linked to foo. ########################################################## Scanning dependencies of target foo [ 6%] Creating directories for 'foo' [ 12%] No download step for 'foo' [ 18%] No patch step for 'foo' [ 25%] No update step for 'foo' [ 31%] Performing configure step for 'foo' -- The C compiler identification is GNU 4.8.4 -- The CXX compiler identification is GNU 4.8.4 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done -- Generating done -- Build files have been written to: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/build/foo-build [ 37%] Performing build step for 'foo' Scanning dependencies of target foo [ 50%] Building CXX object CMakeFiles/foo.dir/src/foo.cpp.o [100%] Linking CXX static library libfoo.a [100%] Built target foo [ 43%] Performing install step for 'foo' [100%] Built target foo Install the project... -- Install configuration: "" -- Installing: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/build/staging/lib/foo/libfoo.a -- Installing: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/build/staging/lib/foo/foo-config.cmake -- Installing: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/build/staging/lib/foo/foo-config-noconfig.cmake -- Installing: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/build/staging/include/foo.h [ 50%] Completed 'foo' [ 50%] Built target foo Scanning dependencies of target bar [ 56%] Creating directories for 'bar' [ 62%] No download step for 'bar' [ 68%] No patch step for 'bar' [ 75%] No update step for 'bar' [ 81%] Performing configure step for 'bar' -- The C compiler identification is GNU 4.8.4 -- The CXX compiler identification is GNU 4.8.4 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done -- Generating done -- Build files have been written to: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/build/bar-build [ 87%] Performing build step for 'bar' Scanning dependencies of target bar [ 50%] Building CXX object CMakeFiles/bar.dir/main.cpp.o [100%] Linking CXX executable bar [100%] Built target bar [ 93%] No install step for 'bar' [100%] Completed 'bar' [100%] Built target bar ########################################################## If I don't change anything and run it again, then I see the foo install step run, no changes are needed and then the bar build step run (bar doesn't get relinked). ########################################################## [ 6%] Performing build step for 'foo' [100%] Built target foo [ 12%] Performing install step for 'foo' [100%] Built target foo Install the project... -- Install configuration: "" -- Up-to-date: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/build/staging/lib/foo/libfoo.a -- Up-to-date: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/build/staging/lib/foo/foo-config.cmake -- Up-to-date: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/build/staging/lib/foo/foo-config-noconfig.cmake -- Up-to-date: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/build/staging/include/foo.h [ 18%] Completed 'foo' [ 50%] Built target foo [ 56%] Performing configure step for 'bar' -- Configuring done -- Generating done -- Build files have been written to: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/build/bar-build [ 62%] Performing build step for 'bar' [100%] Built target bar [ 68%] No install step for 'bar' [ 75%] Completed 'bar' [100%] Built target bar ########################################################## Now if I touch something in foo, we can see that foo is rebuilt. The library is reinstalled and bar is relinked. This results in the correct executable. ########################################################## [ 6%] Performing build step for 'foo' Scanning dependencies of target foo [ 50%] Building CXX object CMakeFiles/foo.dir/src/foo.cpp.o [100%] Linking CXX static library libfoo.a [100%] Built target foo [ 12%] Performing install step for 'foo' [100%] Built target foo Install the project... -- Install configuration: "" -- Installing: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/build/staging/lib/foo/libfoo.a -- Up-to-date: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/build/staging/lib/foo/foo-config.cmake -- Up-to-date: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/build/staging/lib/foo/foo-config-noconfig.cmake -- Up-to-date: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/build/staging/include/foo.h [ 18%] Completed 'foo' [ 50%] Built target foo [ 56%] Performing configure step for 'bar' -- Configuring done -- Generating done -- Build files have been written to: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/build/bar-build [ 62%] Performing build step for 'bar' [ 50%] Linking CXX executable bar [100%] Built target bar [ 68%] No install step for 'bar' [ 75%] Completed 'bar' [100%] Built target bar ########################################################## If I use the ninja generator then the behaviour is different. On the first invocation of 'ninja, foo is built and installed, then bar is built and linked to foo. ########################################################## [5/16] Performing configure step for 'foo' -- The C compiler identification is GNU 4.8.4 -- The CXX compiler identification is GNU 4.8.4 -- Check for working C compiler using: Ninja -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler using: Ninja -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done -- Generating done -- Build files have been written to: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/ninja/foo-build [6/16] Performing build step for 'foo' [1/2] Building CXX object CMakeFiles/foo.dir/src/foo.cpp.o [2/2] Linking CXX static library libfoo.a [7/16] Performing install step for 'foo' [1/1] Install the project... -- Install configuration: "" -- Installing: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/ninja/staging/lib/foo/libfoo.a -- Installing: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/ninja/staging/lib/foo/foo-config.cmake -- Installing: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/ninja/staging/lib/foo/foo-config-noconfig.cmake -- Installing: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/ninja/staging/include/foo.h [13/16] Performing configure step for 'bar' -- The C compiler identification is GNU 4.8.4 -- The CXX compiler identification is GNU 4.8.4 -- Check for working C compiler using: Ninja -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler using: Ninja -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done -- Generating done -- Build files have been written to: /media/data/home/lbuchy/work/cmake/cmake-ninja-install-out/ninja/bar-build [14/16] Performing build step for 'bar' [1/2] Building CXX object CMakeFiles/bar.dir/main.cpp.o [2/2] Linking CXX executable bar [16/16] Completed 'bar' ########################################################## On subsequent invocations (with no changes to bar), there is no work to do. Checking that the installed files are there is not done. But it sure is quick to run a no-op build! ########################################################## [1/7] Performing build step for 'foo' ninja: no work to do. [2/4] Performing build step for 'bar' ninja: no work to do. ########################################################## But if I touch a file in foo, then foo is rebuilt but not reinstalled. bar is not relinked and thus the bar executable is stale. ########################################################## [1/7] Performing build step for 'foo' [1/2] Building CXX object CMakeFiles/foo.dir/src/foo.cpp.o [2/2] Linking CXX static library libfoo.a [2/4] Performing build step for 'bar' ninja: no work to do. ########################################################## Steps to Reproduce: Please see this for an example project to reproduce this bug. https://github.com/lbuchy/cmake-superbuild-ninja-bug The README is a bit incorrect. The description in this bug is better. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-04 21:00 logan.buchy New Issue ====================================================================== From mantis at public.kitware.com Fri Feb 5 01:58:29 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 5 Feb 2016 01:58:29 -0500 Subject: [cmake-developers] [CMake 0015955]: CMAKE-GUI creates varies with trailing blanks Message-ID: <1cfaf283890b39298f744294ff44aed1@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15955 ====================================================================== Reported By: Haju Schulz Assigned To: ====================================================================== Project: CMake Issue ID: 15955 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-05 01:58 EST Last Modified: 2016-02-05 01:58 EST ====================================================================== Summary: CMAKE-GUI creates varies with trailing blanks Description: The cmake-gui dialog to add a variable includes trailing blanks into a variable name. This can lead to a variety of issues later during configure an build step because nothing visualizes such trailing blanks. In my case I copied cmake project setup instructions from a website. This copy&paste operation resulted in the following name inside the cmake-gui: "BOOST_ROOT ". Mind the blank after "..ROOT" ! It took a long time to figure out why configuring this project failed to find BOOS as nothing in the gui shows this trailing blank. To make things worse, the cmake-gui remembers that a user has added "BOOST_ROOT " variable, and keeps offering this as auto-complete name in new project setup attempts. Steps to Reproduce: 1) create a new crake-project with make-gui 2) click "+ add entry" 3) Enter (without the "-Quotes) this as name: "NAME_WITH_SPACE " 4) press OK The cmake-gui shows a variable with "NAME_WITH_SPACE", but internally it is "NAME_WITH_SPACE " ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-05 01:58 Haju Schulz New Issue ====================================================================== From brad.king at kitware.com Fri Feb 5 08:35:35 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 5 Feb 2016 08:35:35 -0500 Subject: [cmake-developers] CMake 3.5 generation time In-Reply-To: References: <56B35287.9010309@kitware.com> <56B39116.3090101@kitware.com> Message-ID: <56B4A527.2050302@kitware.com> On 02/04/2016 05:57 PM, Bartosz Kosiorek wrote: > Unfortunately after building locally, the times are totally different (worse). Check CMAKE_BUILD_TYPE in the CMakeCache.txt file of your CMake build and make sure it is "Release". If not, just change it and run "make" again to rebuild. Thanks, -Brad From roman.wueger at gmx.at Fri Feb 5 08:54:33 2016 From: roman.wueger at gmx.at (=?iso-8859-1?Q?Roman_W=FCger?=) Date: Fri, 5 Feb 2016 14:54:33 +0100 Subject: [cmake-developers] CMake can't generate Windows 10 store app with VS2015 Update 1 Message-ID: Hello, I?ve Installed Windows 10 Professional with VS2015 Update 1 and CMake 3.4.3. When I run configure: cmake -G "Visual Studio 14 Win64" -DCMAKE_SYSTEM_NAME:STRING=WindowsStore -DCMAKE_SYSTEM_VERSION:STRING=10.0 ..\source Then I became the following error message: CMake Error at CMakeLists.txt:3 (PROJECT): A Windows Store component with CMake requires both the Windows Desktop SDK as well as the Windows Store '10.0' SDK. Please make sure that you have both installed -- Configuring incomplete, errors occurred! Did I need something additional to get it working? Thanks in advance Best Regards Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5483 bytes Desc: not available URL: From gang65 at poczta.onet.pl Fri Feb 5 09:10:33 2016 From: gang65 at poczta.onet.pl (Bartosz Kosiorek) Date: Fri, 5 Feb 2016 15:10:33 +0100 Subject: [cmake-developers] CMake 3.5 generation time In-Reply-To: References: <56B35287.9010309@kitware.com> <56B39116.3090101@kitware.com> Message-ID: Hi. Finally I was able to finalize git bisect. Generally without regression time was: real 3m44.070s first bad commit: [0c97d32f7a592a768d614c19b3fd48eab245a2c4] cmGlobalGenerator: Remove direct storage of target time increased to real 6m36.929s (second clean run real 6m12.635s) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0c97d32f In our project we have exactly 3287 targets, because we have flavored builds (in many cases one source code is build in three variants, depending on map type) Below there is an logs from git bisect and times for specific commits. 0c97d32f7a592a768d614c19b3fd48eab245a2c4 is the first bad commit commit 0c97d32f7a592a768d614c19b3fd48eab245a2c4 Author: Stephen Kelly Date: Sun Oct 25 12:22:51 2015 +0100 cmGlobalGenerator: Remove direct storage of targets Find the target by looping when needed. :040000 040000 81eb745e29adced1b44b4e58e6f7658691ff0613 fe0617270fc29a9dabf64035f5a1b3827413bb36 M Source Bisection logs: git bisect log git bisect start # bad: [8a8d22cf1e5d20b7c3b32c1ec9b5f06b339c2a50] CMake 3.5.0-rc1 version update git bisect bad 8a8d22cf1e5d20b7c3b32c1ec9b5f06b339c2a50 # good: [0aef6f2412177a236deb292654402518777f3cb0] CMake 3.4.3 git bisect good 0aef6f2412177a236deb292654402518777f3cb0 # skip: [49ac682d39af7fe47e79455827e2e83130193236] Merge topic 'vs-show-def-files' git bisect skip 49ac682d39af7fe47e79455827e2e83130193236 # bad: [e069aa05c6a0d8e89a677fa4f00d33432191eeaa] Merge topic 'regex-explorer' git bisect bad e069aa05c6a0d8e89a677fa4f00d33432191eeaa # good: [a03c13a710fc4c65035e92749720b559cbeeff2e] CMake Nightly Date Stamp git bisect good a03c13a710fc4c65035e92749720b559cbeeff2e # skip: [59315f5b0028e4f9c4fde765196c4df38ab83b3e] Merge topic 'cpack-deb-compression-scheme-test' git bisect skip 59315f5b0028e4f9c4fde765196c4df38ab83b3e # bad: [48182afd3d04cc659fc5d86ab65b403d8a2b8eff] CMake Nightly Date Stamp git bisect bad 48182afd3d04cc659fc5d86ab65b403d8a2b8eff # skip: [1e8c920d0409770214a4ff517f6a4c31b9830f45] Merge topic 'use-generator-target' git bisect skip 1e8c920d0409770214a4ff517f6a4c31b9830f45 # good: [cf69630e510a5c639a93a99b315fcefea9688935] cmGeneratorTarget: Move GetFrameworkVersion from cmTarget git bisect good cf69630e510a5c639a93a99b315fcefea9688935 # skip: [1bfb527f561c705169f0716108e34a2b5ba5c8bb] FindPkgConfig: return actual error when a package is not found (#15810) git bisect skip 1bfb527f561c705169f0716108e34a2b5ba5c8bb # skip: [c389f8bb07e900d805ca3163f47b06e3dbe4303b] cmLocalGenerator: Port Find method away from GetGeneratorTarget git bisect skip c389f8bb07e900d805ca3163f47b06e3dbe4303b # skip: [1a8c7bc2c649781d1163c1966245a45e0fb829ba] libarchive 3.1.2-601-g3bfe5f1 (reduced) git bisect skip 1a8c7bc2c649781d1163c1966245a45e0fb829ba # skip: [60cbd9b9da2059481e2f29fbb5859a5b0643d3d7] CMake Nightly Date Stamp git bisect skip 60cbd9b9da2059481e2f29fbb5859a5b0643d3d7 # bad: [3cb726371f27948149f668d43aa58cd2a5e9be4c] Merge topic 'wix-toplevel-feature-required' git bisect bad 3cb726371f27948149f668d43aa58cd2a5e9be4c # good: [6a56c8247fa874bd418c3e175c941070dafb0e76] Tests: Disable parallel test execution while running ctest_test git bisect good 6a56c8247fa874bd418c3e175c941070dafb0e76 # skip: [e14709e5a5379f0a6fa2434551211b66561ad540] Merge topic 'revert-autorcc-qt-5.1' git bisect skip e14709e5a5379f0a6fa2434551211b66561ad540 # good: [832fe4b133f47781f4e08df1f83fdc4e3e7aa06b] libarchive: Fix VS 7.1 Debug build git bisect good 832fe4b133f47781f4e08df1f83fdc4e3e7aa06b # skip: [b5d94065c07a3ba6db29297e55b0e01ba0ef1f9d] Merge topic 'autorcc-qt-5.1-compat' git bisect skip b5d94065c07a3ba6db29297e55b0e01ba0ef1f9d # good: [91a829c165209b96c20d17f8eb7d46d3375cc57c] Makefiles: Remove unused variable git bisect good 91a829c165209b96c20d17f8eb7d46d3375cc57c # skip: [5cdba31fc631453d530abbac04bf4a455d1f10bb] Merge topic 'cpack-osx-sysroot' git bisect skip 5cdba31fc631453d530abbac04bf4a455d1f10bb # skip: [6c0d8a5d027bfe681f45337c79d1bbba6331bbd8] README: Fix typo in wording git bisect skip 6c0d8a5d027bfe681f45337c79d1bbba6331bbd8 # bad: [4ce9742ae33678d8fce189d172c2fffb1a43061c] Alias: Fix access at generate-time (#15832) git bisect bad 4ce9742ae33678d8fce189d172c2fffb1a43061c # good: [85e0bb84f5eca2f77f070bce9f83024854096307] libarchive: Avoid using 'uint8_t' as bitfield type git bisect good 85e0bb84f5eca2f77f070bce9f83024854096307 # skip: [13dc7bdb5e3a0eaaf3607b154bba77a01404a788] CMake Nightly Date Stamp git bisect skip 13dc7bdb5e3a0eaaf3607b154bba77a01404a788 # skip: [a375702eaa961a496b9420a836c336d884e9cbf3] CMake Nightly Date Stamp git bisect skip a375702eaa961a496b9420a836c336d884e9cbf3 # good: [593f347b5385a510e641eca0448f7ddf64c1c12b] VS7: Port some implementation details to cmGeneratorTarget git bisect good 593f347b5385a510e641eca0448f7ddf64c1c12b # skip: [7f6c613fd041e8b2dcbfdfc43992a6db28a4b36a] Merge topic 'bootstrap-cleanup' git bisect skip 7f6c613fd041e8b2dcbfdfc43992a6db28a4b36a # skip: [3179d9a2415702b8ca73e8759c0dba97f26423e2] Merge topic 'FindPkgConfig-better-error' git bisect skip 3179d9a2415702b8ca73e8759c0dba97f26423e2 # skip: [e7e713cc0533cd8f1ef47de4cdfd895d33545502] VS: Add module definition `.def` files to .vcxproj files (#15313) git bisect skip e7e713cc0533cd8f1ef47de4cdfd895d33545502 # skip: [41e5605d029ac92c9593d69e06c3a56e1d5c40da] Merge topic 'vs-resw-files' git bisect skip 41e5605d029ac92c9593d69e06c3a56e1d5c40da # skip: [a3c5ca960bdf7c136fc64e3bb6d6619ca30623d2] cmGlobalNinjaGenerator: Save 'ninja' version very early git bisect skip a3c5ca960bdf7c136fc64e3bb6d6619ca30623d2 # good: [f8eb72fe5fedbf45e66f433e6bc54e1cf0359760] Help: Clarify documentation for MACOSX_RPATH variable. git bisect good f8eb72fe5fedbf45e66f433e6bc54e1cf0359760 # skip: [ed67f4052264003133b19edde2c85791d501e001] cmGlobalNinjaGenerator: Save path to 'ninja' tool very early git bisect skip ed67f4052264003133b19edde2c85791d501e001 # good: [63e2af0f8dbae222ebaae62b532340f3d83cbc93] CPack: Fix CPACK_OSX_SYSROOT with symbolic CMAKE_OSX_SYSROOT (#15816) git bisect good 63e2af0f8dbae222ebaae62b532340f3d83cbc93 # skip: [247c168b987a8c9c479112c13078aa2e5db37773] Refactor `.def` file lookup git bisect skip 247c168b987a8c9c479112c13078aa2e5db37773 # skip: [39e830a98e81929ce95694f2f81d92ffd3f14d5b] Merge topic 'cpack-deb-config-file-source-field' git bisect skip 39e830a98e81929ce95694f2f81d92ffd3f14d5b # skip: [adfc8a677e51772d87a3e050477c60ce0b70288f] cmGeneratorTarget: Fix IMPLEMENT_VISIT_IMPL for template data types git bisect skip adfc8a677e51772d87a3e050477c60ce0b70288f # good: [520ca0ff6c123250c633a3618459d0161cbc4683] cmGeneratorTarget: Add API for property keys git bisect good 520ca0ff6c123250c633a3618459d0161cbc4683 # good: [e78fcc6329483c99e61cebffbe5d82b67a3361ae] QtAutogen: Fix rcc invocation for Qt 5.0 and 5.1 (#15644) git bisect good e78fcc6329483c99e61cebffbe5d82b67a3361ae # skip: [06ed3eb9e97e0b5e7f8f968518f0822f3bdda06d] Merge topic 'xcode-lastupgradecheck' git bisect skip 06ed3eb9e97e0b5e7f8f968518f0822f3bdda06d # good: [45cd9e63371ae09b6ad9dbc27ac4d36c19b357af] Update libarchive configuration within CMake git bisect good 45cd9e63371ae09b6ad9dbc27ac4d36c19b357af # skip: [96ac964d765108ea0bf2c37567efdf777a6047e4] CMake Nightly Date Stamp git bisect skip 96ac964d765108ea0bf2c37567efdf777a6047e4 # bad: [79c11d23405d3894a254a8c03df5ead32464b109] Xcode: Port away from GetGeneratorTarget git bisect bad 79c11d23405d3894a254a8c03df5ead32464b109 # bad: [d566f39a640297114bd3ad933bb3279440b2f38f] cmGlobalGenerator: Remove unneeded GetGeneratorTarget git bisect bad d566f39a640297114bd3ad933bb3279440b2f38f # good: [383bfd95432990365ac5c7fc3ab190bfb05cbec1] cmTargetCollectLinkLanguages: Remove cmMakefile dependency git bisect good 383bfd95432990365ac5c7fc3ab190bfb05cbec1 kosiorek at pl1lxl-104710:~/dev/perforce/cmake-dev-doc-update$ git bisect log git bisect start # bad: [8a8d22cf1e5d20b7c3b32c1ec9b5f06b339c2a50] CMake 3.5.0-rc1 version update git bisect bad 8a8d22cf1e5d20b7c3b32c1ec9b5f06b339c2a50 # good: [0aef6f2412177a236deb292654402518777f3cb0] CMake 3.4.3 git bisect good 0aef6f2412177a236deb292654402518777f3cb0 # skip: [49ac682d39af7fe47e79455827e2e83130193236] Merge topic 'vs-show-def-files' git bisect skip 49ac682d39af7fe47e79455827e2e83130193236 # bad: [e069aa05c6a0d8e89a677fa4f00d33432191eeaa] Merge topic 'regex-explorer' git bisect bad e069aa05c6a0d8e89a677fa4f00d33432191eeaa # good: [a03c13a710fc4c65035e92749720b559cbeeff2e] CMake Nightly Date Stamp git bisect good a03c13a710fc4c65035e92749720b559cbeeff2e # skip: [59315f5b0028e4f9c4fde765196c4df38ab83b3e] Merge topic 'cpack-deb-compression-scheme-test' git bisect skip 59315f5b0028e4f9c4fde765196c4df38ab83b3e # bad: [48182afd3d04cc659fc5d86ab65b403d8a2b8eff] CMake Nightly Date Stamp git bisect bad 48182afd3d04cc659fc5d86ab65b403d8a2b8eff # skip: [1e8c920d0409770214a4ff517f6a4c31b9830f45] Merge topic 'use-generator-target' git bisect skip 1e8c920d0409770214a4ff517f6a4c31b9830f45 # good: [cf69630e510a5c639a93a99b315fcefea9688935] cmGeneratorTarget: Move GetFrameworkVersion from cmTarget git bisect good cf69630e510a5c639a93a99b315fcefea9688935 # skip: [1bfb527f561c705169f0716108e34a2b5ba5c8bb] FindPkgConfig: return actual error when a package is not found (#15810) git bisect skip 1bfb527f561c705169f0716108e34a2b5ba5c8bb # skip: [c389f8bb07e900d805ca3163f47b06e3dbe4303b] cmLocalGenerator: Port Find method away from GetGeneratorTarget git bisect skip c389f8bb07e900d805ca3163f47b06e3dbe4303b # skip: [1a8c7bc2c649781d1163c1966245a45e0fb829ba] libarchive 3.1.2-601-g3bfe5f1 (reduced) git bisect skip 1a8c7bc2c649781d1163c1966245a45e0fb829ba # skip: [60cbd9b9da2059481e2f29fbb5859a5b0643d3d7] CMake Nightly Date Stamp git bisect skip 60cbd9b9da2059481e2f29fbb5859a5b0643d3d7 # bad: [3cb726371f27948149f668d43aa58cd2a5e9be4c] Merge topic 'wix-toplevel-feature-required' git bisect bad 3cb726371f27948149f668d43aa58cd2a5e9be4c # good: [6a56c8247fa874bd418c3e175c941070dafb0e76] Tests: Disable parallel test execution while running ctest_test git bisect good 6a56c8247fa874bd418c3e175c941070dafb0e76 # skip: [e14709e5a5379f0a6fa2434551211b66561ad540] Merge topic 'revert-autorcc-qt-5.1' git bisect skip e14709e5a5379f0a6fa2434551211b66561ad540 # good: [832fe4b133f47781f4e08df1f83fdc4e3e7aa06b] libarchive: Fix VS 7.1 Debug build git bisect good 832fe4b133f47781f4e08df1f83fdc4e3e7aa06b # skip: [b5d94065c07a3ba6db29297e55b0e01ba0ef1f9d] Merge topic 'autorcc-qt-5.1-compat' git bisect skip b5d94065c07a3ba6db29297e55b0e01ba0ef1f9d # good: [91a829c165209b96c20d17f8eb7d46d3375cc57c] Makefiles: Remove unused variable git bisect good 91a829c165209b96c20d17f8eb7d46d3375cc57c # skip: [5cdba31fc631453d530abbac04bf4a455d1f10bb] Merge topic 'cpack-osx-sysroot' git bisect skip 5cdba31fc631453d530abbac04bf4a455d1f10bb # skip: [6c0d8a5d027bfe681f45337c79d1bbba6331bbd8] README: Fix typo in wording git bisect skip 6c0d8a5d027bfe681f45337c79d1bbba6331bbd8 # bad: [4ce9742ae33678d8fce189d172c2fffb1a43061c] Alias: Fix access at generate-time (#15832) git bisect bad 4ce9742ae33678d8fce189d172c2fffb1a43061c # good: [85e0bb84f5eca2f77f070bce9f83024854096307] libarchive: Avoid using 'uint8_t' as bitfield type git bisect good 85e0bb84f5eca2f77f070bce9f83024854096307 # skip: [13dc7bdb5e3a0eaaf3607b154bba77a01404a788] CMake Nightly Date Stamp git bisect skip 13dc7bdb5e3a0eaaf3607b154bba77a01404a788 # skip: [a375702eaa961a496b9420a836c336d884e9cbf3] CMake Nightly Date Stamp git bisect skip a375702eaa961a496b9420a836c336d884e9cbf3 # good: [593f347b5385a510e641eca0448f7ddf64c1c12b] VS7: Port some implementation details to cmGeneratorTarget git bisect good 593f347b5385a510e641eca0448f7ddf64c1c12b # skip: [7f6c613fd041e8b2dcbfdfc43992a6db28a4b36a] Merge topic 'bootstrap-cleanup' git bisect skip 7f6c613fd041e8b2dcbfdfc43992a6db28a4b36a # skip: [3179d9a2415702b8ca73e8759c0dba97f26423e2] Merge topic 'FindPkgConfig-better-error' git bisect skip 3179d9a2415702b8ca73e8759c0dba97f26423e2 # skip: [e7e713cc0533cd8f1ef47de4cdfd895d33545502] VS: Add module definition `.def` files to .vcxproj files (#15313) git bisect skip e7e713cc0533cd8f1ef47de4cdfd895d33545502 # skip: [41e5605d029ac92c9593d69e06c3a56e1d5c40da] Merge topic 'vs-resw-files' git bisect skip 41e5605d029ac92c9593d69e06c3a56e1d5c40da # skip: [a3c5ca960bdf7c136fc64e3bb6d6619ca30623d2] cmGlobalNinjaGenerator: Save 'ninja' version very early git bisect skip a3c5ca960bdf7c136fc64e3bb6d6619ca30623d2 # good: [f8eb72fe5fedbf45e66f433e6bc54e1cf0359760] Help: Clarify documentation for MACOSX_RPATH variable. git bisect good f8eb72fe5fedbf45e66f433e6bc54e1cf0359760 # skip: [ed67f4052264003133b19edde2c85791d501e001] cmGlobalNinjaGenerator: Save path to 'ninja' tool very early git bisect skip ed67f4052264003133b19edde2c85791d501e001 # good: [63e2af0f8dbae222ebaae62b532340f3d83cbc93] CPack: Fix CPACK_OSX_SYSROOT with symbolic CMAKE_OSX_SYSROOT (#15816) git bisect good 63e2af0f8dbae222ebaae62b532340f3d83cbc93 # skip: [247c168b987a8c9c479112c13078aa2e5db37773] Refactor `.def` file lookup git bisect skip 247c168b987a8c9c479112c13078aa2e5db37773 # skip: [39e830a98e81929ce95694f2f81d92ffd3f14d5b] Merge topic 'cpack-deb-config-file-source-field' git bisect skip 39e830a98e81929ce95694f2f81d92ffd3f14d5b # skip: [adfc8a677e51772d87a3e050477c60ce0b70288f] cmGeneratorTarget: Fix IMPLEMENT_VISIT_IMPL for template data types git bisect skip adfc8a677e51772d87a3e050477c60ce0b70288f # good: [520ca0ff6c123250c633a3618459d0161cbc4683] cmGeneratorTarget: Add API for property keys git bisect good 520ca0ff6c123250c633a3618459d0161cbc4683 # good: [e78fcc6329483c99e61cebffbe5d82b67a3361ae] QtAutogen: Fix rcc invocation for Qt 5.0 and 5.1 (#15644) git bisect good e78fcc6329483c99e61cebffbe5d82b67a3361ae # skip: [06ed3eb9e97e0b5e7f8f968518f0822f3bdda06d] Merge topic 'xcode-lastupgradecheck' git bisect skip 06ed3eb9e97e0b5e7f8f968518f0822f3bdda06d # good: [45cd9e63371ae09b6ad9dbc27ac4d36c19b357af] Update libarchive configuration within CMake git bisect good 45cd9e63371ae09b6ad9dbc27ac4d36c19b357af # skip: [96ac964d765108ea0bf2c37567efdf777a6047e4] CMake Nightly Date Stamp git bisect skip 96ac964d765108ea0bf2c37567efdf777a6047e4 # bad: [79c11d23405d3894a254a8c03df5ead32464b109] Xcode: Port away from GetGeneratorTarget git bisect bad 79c11d23405d3894a254a8c03df5ead32464b109 # bad: [d566f39a640297114bd3ad933bb3279440b2f38f] cmGlobalGenerator: Remove unneeded GetGeneratorTarget git bisect bad d566f39a640297114bd3ad933bb3279440b2f38f # good: [383bfd95432990365ac5c7fc3ab190bfb05cbec1] cmTargetCollectLinkLanguages: Remove cmMakefile dependency git bisect good 383bfd95432990365ac5c7fc3ab190bfb05cbec1 Bisection results: first bad commit: [0c97d32f7a592a768d614c19b3fd48eab245a2c4] cmGlobalGenerator: Remove direct storage of target 1. real 6m36.929s user 6m26.232s sys 0m3.928s 2. real 6m12.635s user 6m9.340s sys 0m3.604s # good: [383bfd95432990365ac5c7fc3ab190bfb05cbec1] cmTargetCollectLinkLanguages: Remove cmMakefile dependency real 3m44.070s user 3m39.872s sys 0m3.608s # bad: [d566f39a640297114bd3ad933bb3279440b2f38f] cmGlobalGenerator: Remove unneeded GetGeneratorTarget real 7m5.141s user 6m59.824s sys 0m3.796s # bad: [79c11d23405d3894a254a8c03df5ead32464b109] Xcode: Port away from GetGeneratorTarget real 6m33.845s user 6m30.440s sys 0m3.616s # good: [45cd9e63371ae09b6ad9dbc27ac4d36c19b357af] Update libarchive configuration within CMake real 3m46.190s user 3m41.800s sys 0m3.260s # good: [e78fcc6329483c99e61cebffbe5d82b67a3361ae] QtAutogen: Fix rcc invocation for Qt 5.0 and 5.1 (#15644) real 3m44.454s user 3m39.640s sys 0m3.524s # good: [520ca0ff6c123250c633a3618459d0161cbc4683] cmGeneratorTarget: Add API for property keys real 3m43.945s user 3m39.712s sys 0m3.568s # good: [63e2af0f8dbae222ebaae62b532340f3d83cbc93] CPack: Fix CPACK_OSX_SYSROOT with symbolic CMAKE_OSX_SYSROOT (#15816) real 3m44.176s user 3m39.216s sys 0m3.764s # good: [f8eb72fe5fedbf45e66f433e6bc54e1cf0359760] Help: Clarify documentation for MACOSX_RPATH variable. real 3m35.856s user 3m29.228s sys 0m3.536s # good: [593f347b5385a510e641eca0448f7ddf64c1c12b] VS7: Port some implementation details to cmGeneratorTarget real 3m46.947s user 3m42.540s sys 0m3.636s # good: [85e0bb84f5eca2f77f070bce9f83024854096307] libarchive: Avoid using 'uint8_t' as bitfield type real 3m40.737s user 3m36.084s sys 0m3.548s bad: [4ce9742ae33678d8fce189d172c2fffb1a43061c] Alias: Fix access at generate-time (#15832) real 9m17.389s user 9m14.324s sys 0m3.596s # good: [91a829c165209b96c20d17f8eb7d46d3375cc57c] Makefiles: Remove unused variable real 3m51.085s user 3m46.896s sys 0m3.592s [b5d94065c07a3ba6db29297e55b0e01ba0ef1f9d] Merge topic 'autorcc-qt-5.1-compat' 1. real 4m30.586s user 4m19.812s sys 0m4.080s 2. real 4m23.646s user 4m18.552s sys 0m4.084s # good: [6a56c8247fa874bd418c3e175c941070dafb0e76] Tests: Disable parallel test execution while running ctest_test real 3m49.764s user 3m45.076s sys 0m3.736s # bad: [3cb726371f27948149f668d43aa58cd2a5e9be4c] Merge topic 'wix-toplevel-feature-required' real 11m44.201s user 11m41.232s sys 0m3.960s # good: [cf69630e510a5c639a93a99b315fcefea9688935] cmGeneratorTarget: Move GetFrameworkVersion from cmTarget real 3m52.078s user 3m47.508s sys 0m4.240s # bad: [48182afd3d04cc659fc5d86ab65b403d8a2b8eff] CMake Nightly Date Stamp real 12m6.370s user 12m2.872s sys 0m4.392s # good: [a03c13a710fc4c65035e92749720b559cbeeff2e] CMake Nightly Date Stamp real 3m54.556s user 3m44.596s sys 0m4.284s # bad: [e069aa05c6a0d8e89a677fa4f00d33432191eeaa] Merge topic 'regex-explorer' real 12m36.866s user 12m31.864s sys 0m4.348s # good: [d233030f5bcfe2509b82433f7df6383cd301e34e] cmGeneratorTarget: Port implementation to cmGeneratorTarget. git bisect bad d233030f5bcfe2509b82433f7df6383cd301e34e 1. First clean generation real 3m40.716s user 3m34.908s sys 0m3.944s 2. Second clean generation real 3m41.351s user 3m36.880s sys 0m3.872s 2016-02-04 23:57 GMT+01:00 Bartosz Kosiorek : > Hi Brad > Unfortunately after building locally, the times are totally different > (worse). > I don't know why it is happen. > > Builds for some specific commits, are not able to run properly. In that > case I have just skip bisect commit. > Do you have some further recommendation? > > > On master the times are: > real 8m1.255s > user 7m56.684s > sys 0m3.900s > > Bisection logs: > git bisect log > git bisect start > # bad: [8a8d22cf1e5d20b7c3b32c1ec9b5f06b339c2a50] CMake 3.5.0-rc1 version > update > git bisect bad 8a8d22cf1e5d20b7c3b32c1ec9b5f06b339c2a50 > # good: [0aef6f2412177a236deb292654402518777f3cb0] CMake 3.4.3 > git bisect good 0aef6f2412177a236deb292654402518777f3cb0 > # skip: [49ac682d39af7fe47e79455827e2e83130193236] Merge topic > 'vs-show-def-files' > git bisect skip 49ac682d39af7fe47e79455827e2e83130193236 > # bad: [e069aa05c6a0d8e89a677fa4f00d33432191eeaa] Merge topic > 'regex-explorer' > git bisect bad e069aa05c6a0d8e89a677fa4f00d33432191eeaa > # good: [a03c13a710fc4c65035e92749720b559cbeeff2e] CMake Nightly Date Stamp > git bisect good a03c13a710fc4c65035e92749720b559cbeeff2e > # skip: [59315f5b0028e4f9c4fde765196c4df38ab83b3e] Merge topic > 'cpack-deb-compression-scheme-test' > git bisect skip 59315f5b0028e4f9c4fde765196c4df38ab83b3e > # bad: [48182afd3d04cc659fc5d86ab65b403d8a2b8eff] CMake Nightly Date Stamp > git bisect bad 48182afd3d04cc659fc5d86ab65b403d8a2b8eff > # skip: [1e8c920d0409770214a4ff517f6a4c31b9830f45] Merge topic > 'use-generator-target' > git bisect skip 1e8c920d0409770214a4ff517f6a4c31b9830f45 > # good: [cf69630e510a5c639a93a99b315fcefea9688935] cmGeneratorTarget: Move > GetFrameworkVersion from cmTarget > git bisect good cf69630e510a5c639a93a99b315fcefea9688935 > # skip: [1bfb527f561c705169f0716108e34a2b5ba5c8bb] FindPkgConfig: return > actual error when a package is not found (#15810) > git bisect skip 1bfb527f561c705169f0716108e34a2b5ba5c8bb > > > Bisection results: > # good: [cf69630e510a5c639a93a99b315fcefea9688935] cmGeneratorTarget: Move > GetFrameworkVersion from cmTarget > real 3m52.078s > user 3m47.508s > sys 0m4.240s > > # bad: [48182afd3d04cc659fc5d86ab65b403d8a2b8eff] CMake Nightly Date Stamp > real 12m6.370s > user 12m2.872s > sys 0m4.392s > > # good: [a03c13a710fc4c65035e92749720b559cbeeff2e] CMake Nightly Date Stamp > real 3m54.556s > user 3m44.596s > sys 0m4.284s > > # bad: [e069aa05c6a0d8e89a677fa4f00d33432191eeaa] Merge topic > 'regex-explorer' > real 12m36.866s > user 12m31.864s > sys 0m4.348s > > # good: [d233030f5bcfe2509b82433f7df6383cd301e34e] cmGeneratorTarget: Port > implementation to cmGeneratorTarget. > git bisect bad d233030f5bcfe2509b82433f7df6383cd301e34e > 1. First clean generation > real 3m40.716s > user 3m34.908s > sys 0m3.944s > 2. Second clean generation > real 3m41.351s > user 3m36.880s > sys 0m3.872s > > > 2016-02-04 20:56 GMT+01:00 Bartosz Kosiorek : > >> Hi. >> I would like to mention that all my previous times, was measured for >> clean Generation (I deleted all generation files) >> I will try to make bisect build, to check where regression occur. >> >> Now I would like to present results with enabled cleaning only on first >> run: >> >> CMake 3.4.3 Unix Makefile generation >> 1. Clean run (rm -rf Output) >> real 1m31.233s >> user 1m26.136s >> sys 0m3.004s >> 2. Dirty run (no deletion) >> real 1m27.101s >> user 1m24.620s >> sys 0m2.988s >> 3. Dirty run (no deletion) >> real 1m26.237s >> user 1m23.240s >> sys 0m3.020s >> 4. Dirty run (no deletion) >> real 1m27.670s >> user 1m24.764s >> sys 0m2.816s >> >> CMake 3.5.0-rc1 Unix Makefile generation >> 1. Clean run (rm -rf Output) >> real 2m34.244s >> user 2m30.176s >> sys 0m3.220s >> 2. Dirty run (no deletion) >> real 2m35.259s >> user 2m32.400s >> sys 0m3.116s >> 3. Dirty run (no deletion) >> real 2m27.881s >> user 2m25.184s >> sys 0m3.032s >> 4. Dirty run (no deletion) >> real 2m25.139s >> user 2m22.552s >> sys 0m2.984s >> >> 2016-02-04 18:57 GMT+01:00 Brad King : >> >>> On 02/04/2016 10:29 AM, Bartosz Kosiorek wrote: >>> > I downloaded cmakes from website: >>> > https://cmake.org/download/ >>> > >>> > All generation were done on clean output (deleted all files generated >>> by cmake) >>> > on the same repository version, in the same directory. >>> > The only difference was cmake version used for configuring. >>> > >>> > How I could check what was caused such long times? >>> >>> Try also timing the second and third runs on a single build tree >>> to get timings without all the platform introspection tests. >>> >>> You could clone the CMake Git repository, build from source with >>> -DCMAKE_BUILD_TYPE=RelWithDebInfo and then run it through a >>> profiler (e.g. valgrind --tool=callgrind). Alternatively you >>> could `git bisect` between v3.4.3 and v3.5.0-rc1 to see if there >>> is a small range of commits that causes the regression. That >>> could really help narrow it down. >>> >>> Thanks, >>> -Brad >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Arnau.Quintana at king.com Fri Feb 5 09:23:13 2016 From: Arnau.Quintana at king.com (Arnau Quintana) Date: Fri, 5 Feb 2016 14:23:13 +0000 Subject: [cmake-developers] Xcode generator is adding old attributes on .pbxproj Message-ID: Hi, tl;dr: I have problems generating .pbxproj files with cmake, related to deprecated attributes on .pbxproj. We are using cmake to generate and build Xcode projects. We need to generate the schemes programatically, and to do so we are using https://github.com/CocoaPods/Xcodeproj to generate them. The problem is that the .pbxproj contains some attributes that seem to be deprecated. Specifically: * ?refType" for the ?PBXFileReference" isa * ?buildSettings? and ?buildStyles? for ?PBXProject" isa Xcode is nice enough to open the project and regenerate the .pbxproj. But we are building from a CI environment, so it is not feasible to open Xcode. If I open the project with Xcode * ?refType? is jus removed from the .pbxproj file. Also, a new project does not contain this attribute. * ?buildSettings? and ?buildStyles? are left there. But a new project is not creating them. Are there any ongoing efforts to fix this? I have seen that refType is only used for Xcode version 1.5, except on "cmGlobalXCodeGenerator::CreateXCodeTarget?. I suppose it would be safe to also put the condition in that case. In addition, maybe we could remove this, as Xcode 1.5 seems to be old enough.. Maybe we could just remove all references to ?refType?. About ?buildSetting?, it is empty for ?PBXProject?, so I think it would be save to remove it. About ?buildStyles?, it is only used to set ?COPY_PHASE_STRIP? to ?NO?. On Xcode 6.4 this key is set in ?XCBuildConfiguration? section. So we could move this to the new section. If someone else is working on this, I?d gladly join efforts :) Meanwhile I will start on a patch. Should I open a bug? Thanks a lot! Arnau Quintana -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Feb 5 10:11:24 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 5 Feb 2016 10:11:24 -0500 Subject: [cmake-developers] Xcode generator is adding old attributes on .pbxproj In-Reply-To: References: Message-ID: <56B4BB9C.1090009@kitware.com> On 02/05/2016 09:23 AM, Arnau Quintana wrote: > The problem is that the .pbxproj contains some attributes that seem to be deprecated. Specifically: > > * ?refType" for the ?PBXFileReference" isa > * ?buildSettings? and ?buildStyles? for ?PBXProject" isa > > Xcode is nice enough to open the project and regenerate the .pbxproj. > > If I open the project with Xcode > > * ?refType? is jus removed from the .pbxproj file. Also, a new project does not contain this attribute. > * ?buildSettings? and ?buildStyles? are left there. But a new project is not creating them. > > Are there any ongoing efforts to fix this? I'm not aware of such effort, and this is the first I've seen a report of problems like this. Over the years I've run the entire test suite of CMake with every version of Xcode through 7.2 and have not seen any failure due to such content. I don't normally develop in Xcode though. > maybe we could remove this, as Xcode 1.5 seems to be old enough Yes. > If someone else is working on this, I?d gladly join efforts :) If you can provide a patch to fix this, then great! I've added Gregor Jasny to Cc because he may be interested in this too. Thanks, -Brad From brad.king at kitware.com Fri Feb 5 10:16:58 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 5 Feb 2016 10:16:58 -0500 Subject: [cmake-developers] CMake 3.5 generation time In-Reply-To: References: <56B35287.9010309@kitware.com> <56B39116.3090101@kitware.com> Message-ID: <56B4BCEA.6020201@kitware.com> On 02/05/2016 09:10 AM, Bartosz Kosiorek wrote: > Finally I was able to finalize git bisect. > Generally without regression time was: real3m44.070s > first bad commit: [0c97d32f7a592a768d614c19b3fd48eab245a2c4] cmGlobalGenerator: Remove direct storage of target > time increased to real 6m36.929s (second clean run real 6m12.635s) > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0c97d32f > > In our project we have exactly 3287 targets, because we have > flavored builds (in many cases one source code is build in > three variants, depending on map type) Thanks. That commit was part of a larger refactoring topic: Merge topic 'use-generator-target' https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1e8c920d and so cannot be simply reverted without a lot of other changes. It looks like these methods: cmGlobalGenerator::FindTargetImpl cmGlobalGenerator::FindGeneratorTargetImpl cmGlobalGenerator::FindImportedTargetImpl are all now using linear searches instead of algorithmically efficient data structures like before. These lookups are done a lot. Steve, IIUC you made this change as part of refactoring to separate configure-time and generate-time structures. We need to fix this to make the lookups efficient again. Where should we store the needed data structures now? Thanks, -Brad From brad.king at kitware.com Fri Feb 5 10:22:03 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 5 Feb 2016 10:22:03 -0500 Subject: [cmake-developers] [PATCH] Bug fix: Dylibs inside .framework folders fails in BundleUtilities.cmake. In-Reply-To: References: Message-ID: <56B4BE1B.5050200@kitware.com> On 02/04/2016 01:34 PM, Christian Askeland wrote: > The specific cause is when e.g. > > /Library/Frameworks/GStreamer.framework/Versions/1.0/lib/libgio-2.0.0.dylib > > is detected by fixup_bundle. BundleUtilities.cmake/set_bundle_key_values() > interprets this as a framework, thus doing a string replace that creates an > embedded_item that is equal to the original path, i.e. it is not embedded. > > The fix is to rely on the correct framework detection in > GetPrerequisite.cmake/gp_item_default_embedded_path() instead. [snip] > - if(item MATCHES "[^/]+\\.framework/") > + # Use default_embedded_path from gp_item_default_embedded_path() to query whether the item is a framework > + if(default_embedded_path MATCHES "/Frameworks") If the project uses gp_item_default_embedded_path_override then we cannot rely on the value from gp_item_default_embedded_path. Is there another way to detect whether the item is actually the main framework library itself or just something else inside one? Thanks, -Brad From roman.wueger at gmx.at Fri Feb 5 10:41:20 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Fri, 5 Feb 2016 16:41:20 +0100 Subject: [cmake-developers] CMake can't generate Windows 10 store app with VS2015 Update 1 In-Reply-To: References: Message-ID: <483EC079-93D1-4330-8F1B-11DC682E3866@gmx.at> Ok, I've installed all options from the SDK (https://dev.windows.com/en-us/downloads/windows-10-sdk) but it doesn't solve the issue. Is there something other to install? What things does CMake require? Best Regards Roman > Am 05.02.2016 um 14:54 schrieb Roman W?ger : > > Hello, > > I?ve Installed Windows 10 Professional with VS2015 Update 1 and CMake 3.4.3. > When I run configure: > > cmake -G "Visual Studio 14 Win64" -DCMAKE_SYSTEM_NAME:STRING=WindowsStore -DCMAKE_SYSTEM_VERSION:STRING=10.0 ..\source > > Then I became the following error message: > > CMake Error at CMakeLists.txt:3 (PROJECT): > A Windows Store component with CMake requires both the Windows Desktop SDK > as well as the Windows Store '10.0' SDK. Please make sure that you have > both installed > > > -- Configuring incomplete, errors occurred! > > Did I need something additional to get it working? > > Thanks in advance > > Best Regards > Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Feb 5 11:45:41 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 5 Feb 2016 11:45:41 -0500 Subject: [cmake-developers] Xcode generator is adding old attributes on .pbxproj In-Reply-To: <61F736FE-7D52-4F57-A76A-C12D8CC2FF87@king.com> References: <56B4BB9C.1090009@kitware.com> <61F736FE-7D52-4F57-A76A-C12D8CC2FF87@king.com> Message-ID: <56B4D1B5.6070104@kitware.com> On 02/05/2016 11:35 AM, Arnau Quintana wrote: > I do not know if these are related. Any thoughts? Unfortunately I'm not familiar enough with Xcode to answer. Hopefully someone else can answer. > I am curious about what tests are you running. Could you > please point me to the relevant tests? Build CMake from source using another CMake and the Xcode generator: mkdir cmake-xcode cd cmake-xcode cmake ../cmake -GXcode cmake --build . --config Debug Then you can run the test suite like this: bin/Debug/ctest -C Debug -j 4 We have nightly testing of several Xcode versions reported here: https://open.cdash.org/index.php?project=CMake -Brad From Arnau.Quintana at king.com Fri Feb 5 11:35:26 2016 From: Arnau.Quintana at king.com (Arnau Quintana) Date: Fri, 5 Feb 2016 16:35:26 +0000 Subject: [cmake-developers] Xcode generator is adding old attributes on .pbxproj In-Reply-To: <56B4BB9C.1090009@kitware.com> References: <56B4BB9C.1090009@kitware.com> Message-ID: <61F736FE-7D52-4F57-A76A-C12D8CC2FF87@king.com> Hi Brad, Thanks for the quick response! :) The changes to remove ?refType? are quite safe. I see no big problems there. The same for ?buildSettings? as this attribute is empty for the ?PBXProject? section. About ?buildStyles?, as I see on the cmake code, it is used only to set ?COPY_PHASE_STRIP=NO?. I might be missing some reason, but I am not sure cmake should set ?NO? by default. But this might be a topic for a separate discussion. Anyway, on our project we set this property to ?NO" for internal builds (debug) and to ?YES" for live versions. We do that in our build scripts, using ?set_target_property?, but by analysing this issue I found out that this is not working either, and this setting is not correctly set on Xcode. I do not know if these are related. Any thoughts? I am curious about what tests are you running. Could you please point me to the relevant tests? I?ll keep you posted if I do any progress. Thanks again! Arnau On 05/02/16 16:11, "Brad King" wrote: >On 02/05/2016 09:23 AM, Arnau Quintana wrote: >> The problem is that the .pbxproj contains some attributes that seem to be deprecated. Specifically: >> >> * ?refType" for the ?PBXFileReference" isa >> * ?buildSettings? and ?buildStyles? for ?PBXProject" isa >> >> Xcode is nice enough to open the project and regenerate the .pbxproj. >> >> If I open the project with Xcode >> >> * ?refType? is jus removed from the .pbxproj file. Also, a new project does not contain this attribute. >> * ?buildSettings? and ?buildStyles? are left there. But a new project is not creating them. >> >> Are there any ongoing efforts to fix this? > >I'm not aware of such effort, and this is the first I've seen a report >of problems like this. Over the years I've run the entire test suite >of CMake with every version of Xcode through 7.2 and have not seen any >failure due to such content. I don't normally develop in Xcode though. > >> maybe we could remove this, as Xcode 1.5 seems to be old enough > >Yes. > >> If someone else is working on this, I?d gladly join efforts :) > >If you can provide a patch to fix this, then great! I've added >Gregor Jasny to Cc because he may be interested in this too. > >Thanks, >-Brad > From b95705030 at ntu.edu.tw Fri Feb 5 14:41:27 2016 From: b95705030 at ntu.edu.tw (Yi-Hong Lyu) Date: Sat, 6 Feb 2016 03:41:27 +0800 Subject: [cmake-developers] Question related to Visual Studio 14 2015 [MyTarget] Message-ID: Hello all, I am a cmake newbie. Now I have two compiler that target MyTarget. The first one is a modified cl.exe, and the other one is the clang-cl.exe. Because they don't target x86/x64, both headers/libraries are supposed not to be included/linked. Instead I just want to include/link headers/libraries of MyTarget. Here are my some questions: 1. What I need to do is to add an option MyTarget for arch of "Visual Studio 14 2015 [arch]", just like "Visual Studio 14 2015 [Win64]" or "Visual Studio 14 2015 [ARM]"? 2. How can I support cl.exe and clang-cl.exe by Visual Studio 14 2015 [MyTarget]"? Should I add options cl.exe/clang-cl.exe for toolset-name of "-T "? 3. Is there any way to make sure that all x86/x64 headers/libraries are not included/linked? I'd like only include/link headers/libraries of MyTarget. Thanks for your reply, any comments are welcomed. Yi-Hong -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Fri Feb 5 17:14:27 2016 From: ewmailing at gmail.com (Eric Wing) Date: Fri, 5 Feb 2016 14:14:27 -0800 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: <56B39386.1000709@kitware.com> References: <568FE434.1020501@kitware.com> <569556D8.80308@kitware.com> <5696683B.2050703@kitware.com> <5697EF44.60001@kitware.com> <5699597B.80108@kitware.com> <569E644B.2020404@kitware.com> <569FA49B.2070005@kitware.com> <56B39386.1000709@kitware.com> Message-ID: On 2/4/16, Brad King wrote: > On 01/29/2016 03:16 PM, Eric Wing wrote: >> I need more guidance here. I'm not connecting the dots. >> My problem seems to be that the execute_process() in >> CMakeDetermineCompilerId.cmake is trying to invoke the command: >> 'swift CompilerId/main.swift' > [snip] >> Looking at the execute_process() that gets invoked (final one in the >> big if/elseif block of CMAKE_DETERMINE_COMPILER_ID_BUILD), the only >> way to get the flags I need are via CMAKE_${lang}_COMPILER_ID_FLAGS. > > Some refactoring may be needed to allow language-specific behavior > to add flags that must be there for the check. Add an explicit > internal variable or other code path to support it (that is just > not set for other languages). The semantics of selecting flags > from the environment in CMAKE_${lang}_COMPILER_ID_FLAGS must not > change. > > Thanks, > -Brad > > Okay, thanks, will do. A quick update on my progress. - I started looking at the DEFINE system for Swift. It has a very simplified form of what we would do in C. You can doo -DFOO for #if FOO // do something #endif But it doesn't allow for anything more complicated like values. So this is not supported: -DFOO=1 So currently there doesn't seem to be any compiler failure, it just doesn't do anything useful. Currently I'm using ADD_DEFINITIONS. And that works. However, since this blends C/C++/Obj-C/Swift into the same pool, it doesn't feel right. (I think Xcode has separate definitions for Swift.) Right now if I'm clever and don't pick any definitions that conflict, I can use the system. And the more complex ones are simply ignored by Swift. But longer term, I'm thinking these may need to be split up. - Second, I got word from a Swift engineer that the 'swift' frontend compiler is not a supported tool and can break the interface. I should be using swiftc. Furthermore, I was told that the file-by-file compilation which 'swift' allows is not really supported and the output I'm seeing from Xcode is more debug information than what's really going on. They seemed adamant that the all files in one-shot via swiftc was the correct path and what I was doing was unreliable and also loses information for the debugger and libraries. Anyway, I'm still reflecting on this about what to do next. The reality is that what I have right now works (for me), and solves a bunch of problems that their current tools do not solve (Xcode is more proof of that). The current path has pretty minimal changes to CMake as well. I'm still reflecting and will probably need to press them for more specifics, but based on all the realities of the situation, I'm thinking I should press on with this initial implementation to get something useable if not perfect. But longer term, we probably need to look at swiftc and one-shot. From Gilles.Khouzam at microsoft.com Fri Feb 5 17:20:24 2016 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Fri, 5 Feb 2016 22:20:24 +0000 Subject: [cmake-developers] CMake can't generate Windows 10 store app with VS2015 Update 1 In-Reply-To: <483EC079-93D1-4330-8F1B-11DC682E3866@gmx.at> References: <483EC079-93D1-4330-8F1B-11DC682E3866@gmx.at> Message-ID: Hi Roman, I can help with this. You should be good with VS 2015 and the Windows 10 SDK. After you installed the SDK, did you get the same error message or a different one? From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Roman W?ger Sent: Friday, February 5, 2016 07:41 To: cmake-developers at cmake.org Subject: Re: [cmake-developers] CMake can't generate Windows 10 store app with VS2015 Update 1 Ok, I've installed all options from the SDK (https://dev.windows.com/en-us/downloads/windows-10-sdk) but it doesn't solve the issue. Is there something other to install? What things does CMake require? Best Regards Roman Am 05.02.2016 um 14:54 schrieb Roman W?ger >: Hello, I?ve Installed Windows 10 Professional with VS2015 Update 1 and CMake 3.4.3. When I run configure: cmake -G "Visual Studio 14 Win64" -DCMAKE_SYSTEM_NAME:STRING=WindowsStore -DCMAKE_SYSTEM_VERSION:STRING=10.0 ..\source Then I became the following error message: CMake Error at CMakeLists.txt:3 (PROJECT): A Windows Store component with CMake requires both the Windows Desktop SDK as well as the Windows Store '10.0' SDK. Please make sure that you have both installed -- Configuring incomplete, errors occurred! Did I need something additional to get it working? Thanks in advance Best Regards Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjasny at googlemail.com Sat Feb 6 05:42:28 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 6 Feb 2016 11:42:28 +0100 Subject: [cmake-developers] Xcode generator is adding old attributes on .pbxproj In-Reply-To: <61F736FE-7D52-4F57-A76A-C12D8CC2FF87@king.com> References: <56B4BB9C.1090009@kitware.com> <61F736FE-7D52-4F57-A76A-C12D8CC2FF87@king.com> Message-ID: <56B5CE14.4010403@googlemail.com> Hello, some time ago I started a project to make the CMake generated pbxproj identical to the one Xcode writes. Some patches of that effort are already in master, some lack some cleanup. It would be great working with you on individual patches to 'modernize' generated pbxproj files. Patches would be a superb start. Note: you could use the xcproj tool to ask Xcode to re-generate the project by running "xcproj touch". I also intend to work on generating schema directly from CMake but this will take some time. Thanks, Gregor From gjasny at googlemail.com Sat Feb 6 05:49:07 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 6 Feb 2016 11:49:07 +0100 Subject: [cmake-developers] Drop support for older Xcode versions? Message-ID: <56B5CFA3.5090107@googlemail.com> Hello, I'd like to get your feedback on deprecating or dropping support for older Xcode versions. During changes on the Xcode generator it gets harder and harder to test against old and very old Xcode versions like 3 and 4. Are there still users around for these versions of Xcode? PS: I'm talking here about the Xcode generator which creates Xcode projects, not the Makefile or Ninja generator. Thanks, Gregor From steveire at gmail.com Sat Feb 6 14:18:00 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 06 Feb 2016 20:18 +0100 Subject: [cmake-developers] CMake 3.5 generation time References: <56B35287.9010309@kitware.com> <56B39116.3090101@kitware.com> Message-ID: Bartosz Kosiorek wrote: > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0c97d32f The relevant part of that patch (from the point of view of separating configure time code from generate time code) is the removal of the use of TotalTargets at generate time. Mappings could be re-introduced in cmGlobalGenerator, maybe with names indicating that their purpose is faster searching, and separated between cmTargets and cmGeneratorTargets: TargetMap TargetSearchIndex; TargetMap ImportedTargetSearchIndex; GeneratorTargetMap GeneratorTargetSearchIndex; Thanks, Steve. From steveire at gmail.com Sat Feb 6 14:26:12 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 06 Feb 2016 20:26:12 +0100 Subject: [cmake-developers] Review request: extract-cmMessenger branch References: <56B063F2.8080206@gmail.com> Message-ID: Michael Scott wrote: >> Yes. Did you have a close look at the commits? I'm not really sure they >> are correct, and I wonder if you have any thoughts on the first one which >> discusses interface? > I went back and had a closer look at the major changes. I think on the > whole the cmMessenger class is good and a clear improvement over the > previous organisation, however I imagine in its current form it would be > perhaps a bit tricky extending it for other environments (e.g. > displaying messages as GUI modal notifications), which I understood to > be one of the overall aims of the branch (correct me if I've > misunderstood of course though). The aim of the branch is only to extract the class. That allows the further work on it. When it is extracted, it can be refactored with a virtual interface as you describe, and as is described in the 'cmMessenger: Extract from cmake class' commit. Thanks, Steve. From ewmailing at gmail.com Sat Feb 6 18:46:35 2016 From: ewmailing at gmail.com (Eric Wing) Date: Sat, 6 Feb 2016 15:46:35 -0800 Subject: [cmake-developers] Drop support for older Xcode versions? In-Reply-To: <56B5CFA3.5090107@googlemail.com> References: <56B5CFA3.5090107@googlemail.com> Message-ID: On 2/6/16, Gregor Jasny via cmake-developers wrote: > Hello, > > I'd like to get your feedback on deprecating or dropping support for > older Xcode versions. During changes on the Xcode generator it gets > harder and harder to test against old and very old Xcode versions like 3 > and 4. > > Are there still users around for these versions of Xcode? > > PS: I'm talking here about the Xcode generator which creates Xcode > projects, not the Makefile or Ninja generator. > > Thanks, > Gregor > -- > I personally am not using them. My more serious problem is that the Xcode projects being generated now are not keeping up with modern Xcode and the features that need to be accessible/set. The reality of Apple development is you must be on the latest stable Xcode if you need to ship apps on the Mac or iOS Store, otherwise Apple can reject your app. Their design philosophy, regardless if you agree with it or not, is to build with the latest and build against backwards compatibility deployment targets, not build with the oldest and pray it will work with future changes that couldn't be predicted at the time. Their platform, their rules. So I'm all in favor of dropping legacy platforms if it means ultimately helping make the Xcode generator work better for modern Xcode. General rule of thumb for Apple development is support the latest and -1 version. If you can do more, fine, but don't compromise the recent stuff in order to achieve distant backwards compatibility. -Eric From christian.askeland at gmail.com Sun Feb 7 11:25:29 2016 From: christian.askeland at gmail.com (Christian Askeland) Date: Sun, 7 Feb 2016 17:25:29 +0100 Subject: [cmake-developers] [PATCH] Bug fix: Dylibs inside .framework folders fails in BundleUtilities.cmake. In-Reply-To: <56B4BE1B.5050200@kitware.com> References: <56B4BE1B.5050200@kitware.com> Message-ID: > On 5. feb. 2016, at 16.22, Brad King wrote: > > On 02/04/2016 01:34 PM, Christian Askeland wrote: >> The specific cause is when e.g. >> >> /Library/Frameworks/GStreamer.framework/Versions/1.0/lib/libgio-2.0.0.dylib >> >> is detected by fixup_bundle. BundleUtilities.cmake/set_bundle_key_values() >> interprets this as a framework, thus doing a string replace that creates an >> embedded_item that is equal to the original path, i.e. it is not embedded. >> >> The fix is to rely on the correct framework detection in >> GetPrerequisite.cmake/gp_item_default_embedded_path() instead. > [snip] >> - if(item MATCHES "[^/]+\\.framework/") >> + # Use default_embedded_path from gp_item_default_embedded_path() to query whether the item is a framework >> + if(default_embedded_path MATCHES "/Frameworks") > > If the project uses gp_item_default_embedded_path_override then > we cannot rely on the value from gp_item_default_embedded_path. Good point, I didn't see that one. > Is there another way to detect whether the item is actually the > main framework library itself or just something else inside one? > We could reuse the check from gp_item_default_embedded_path(), instead of looking at the result from that function: if((item NOT MATCHES "\\.dylib$") AND (item MATCHES "[^/]+\\.framework/")) I haven't tested the line above, but can do so tomorrow and post a new patch, if it looks reasonable. > Thanks, > -Brad > -Christian From paul.wilkinson at cantab.net Sun Feb 7 15:46:27 2016 From: paul.wilkinson at cantab.net (Paul Wilkinson) Date: Sun, 7 Feb 2016 20:46:27 +0000 Subject: [cmake-developers] [PATCH] Help: fix mistake in cmake-buildsystem(7) Message-ID: The COMPATIBLE_INTERFACE_NUMBER_MAX example now sets INTERFACE_CONTAINER_SIZE_REQUIRED on lib1Version2 and lib1Version3 (it previously set it on lib1Version2 twice and never on lib1Version3. Probably a copy-paste mistake?) --- Help/manual/cmake-buildsystem.7.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Help/manual/cmake-buildsystem.7.rst b/Help/manual/cmake-buildsystem.7.rst index 4a04f31..9004bb2 100644 --- a/Help/manual/cmake-buildsystem.7.rst +++ b/Help/manual/cmake-buildsystem.7.rst @@ -427,7 +427,7 @@ specified will be calculated: ) add_library(lib1Version3 SHARED lib1_v3.cpp) - set_property(TARGET lib1Version2 PROPERTY INTERFACE_CONTAINER_SIZE_REQUIRED 1000) + set_property(TARGET lib1Version3 PROPERTY INTERFACE_CONTAINER_SIZE_REQUIRED 1000) add_executable(exe1 exe1.cpp) # CONTAINER_SIZE_REQUIRED will be "200" -- 1.9.1 From mantis at public.kitware.com Sun Feb 7 17:24:06 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 7 Feb 2016 17:24:06 -0500 Subject: [cmake-developers] [CMake 0015956]: TryCompile generation of cmake failed Message-ID: <8bba0711413a6bbe65d23c15d1b15202@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15956 ====================================================================== Reported By: davidk Assigned To: ====================================================================== Project: CMake Issue ID: 15956 Category: (No Category) Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-07 17:24 EST Last Modified: 2016-02-07 17:24 EST ====================================================================== Summary: TryCompile generation of cmake failed Description: CMake 3.1.3 fails to compile a project, but CMake 3.0 works well. It seems like the problem occurs when CMake tries to check the avaible compiler features. Yes, I have a working c/c++ compiler installed (gcc 5.3). I'm executing CMake with root privileges, so there shouldn't be any permission problems. Steps to Reproduce: Try to configure kdelibs4support (A KDE library) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-07 17:24 davidk New Issue 2016-02-07 17:24 davidk File Added: CMakeError.log ====================================================================== From mantis at public.kitware.com Sun Feb 7 17:45:28 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 7 Feb 2016 17:45:28 -0500 Subject: [cmake-developers] [CMake 0015957]: cmake-gui.1 man page should not be installed unless --qt-gui is given Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15957 ====================================================================== Reported By: Orion Poplawski Assigned To: ====================================================================== Project: CMake Issue ID: 15957 Category: CMake Reproducibility: always Severity: trivial Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-07 17:45 EST Last Modified: 2016-02-07 17:45 EST ====================================================================== Summary: cmake-gui.1 man page should not be installed unless --qt-gui is given Description: cmake-gui.1 man page should not be installed unless --qt-gui is given ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-07 17:45 Orion PoplawskiNew Issue ====================================================================== From mantis at public.kitware.com Sun Feb 7 17:53:19 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 7 Feb 2016 17:53:19 -0500 Subject: [cmake-developers] [CMake 0015958]: ctest FTP failure Message-ID: <23d555e6ceef05736992bfb5b5345234@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15958 ====================================================================== Reported By: Orion Poplawski Assigned To: ====================================================================== Project: CMake Issue ID: 15958 Category: CTest Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-07 17:53 EST Last Modified: 2016-02-07 17:53 EST ====================================================================== Summary: ctest FTP failure Description: See https://bugzilla.redhat.com/show_bug.cgi?id=1305310 332: Expected stderr to match: 332: 332: expect-err> Error message was: ([Cc]ould *n.t resolve host:? '?-no-site-'?|The requested URL returned error:.*) 332: expect-err> Problems when submitting via FTP 332: 332: Actual stderr: 332: 332: actual-err> Error when uploading file: /home/bob/rpmbuild/BUILD/cmake-3.4.3/build/Tests/RunCMake/ctest_submit/FailDrop-ftp-build/Testing/20160206-1516/Configure.xml 332: actual-err> Error message was: Could not resolve host: -no-site-; Name or service not known 332: actual-err> Problems when submitting via FTP Additional Information: diff -urt cmake-3.4.3-orig/Tests/RunCMake/ctest_submit/CDashSubmitQuiet-stderr.txt cmake-3.4.3/Tests/RunCMake/ctest_submit/CDashSubmitQuiet-stderr.txt --- cmake-3.4.3-orig/Tests/RunCMake/ctest_submit/CDashSubmitQuiet-stderr.txt 2016-01-25 17:57:22.000000000 +0100 +++ cmake-3.4.3/Tests/RunCMake/ctest_submit/CDashSubmitQuiet-stderr.txt 2016-02-06 15:52:14.309214430 +0100 @@ -1,3 +1,3 @@ *Error when uploading file: .*/Configure.xml - *Error message was: ([Cc]ould *n.t resolve host:? '?-no-site-'?|The requested URL returned error:.*) + *Error message was: ([Cc]ould *n.t resolve host:? '?-no-site-'?.*|The requested URL returned error:.*) *Problems when submitting via HTTP diff -urt cmake-3.4.3-orig/Tests/RunCMake/ctest_submit/FailDrop-ftp-stderr.txt cmake-3.4.3/Tests/RunCMake/ctest_submit/FailDrop-ftp-stderr.txt --- cmake-3.4.3-orig/Tests/RunCMake/ctest_submit/FailDrop-ftp-stderr.txt 2016-01-25 17:57:22.000000000 +0100 +++ cmake-3.4.3/Tests/RunCMake/ctest_submit/FailDrop-ftp-stderr.txt 2016-02-06 16:20:06.557615425 +0100 @@ -1,2 +1,2 @@ -Error message was: ([Cc]ould *n.t resolve host:? '?-no-site-'?|The requested URL returned error:.*) +Error message was: ([Cc]ould *n.t resolve host:? '?-no-site-'?.*|The requested URL returned error:.*) Problems when submitting via FTP diff -urt cmake-3.4.3-orig/Tests/RunCMake/ctest_submit/FailDrop-https-stderr.txt cmake-3.4.3/Tests/RunCMake/ctest_submit/FailDrop-https-stderr.txt --- cmake-3.4.3-orig/Tests/RunCMake/ctest_submit/FailDrop-https-stderr.txt 2016-01-25 17:57:22.000000000 +0100 +++ cmake-3.4.3/Tests/RunCMake/ctest_submit/FailDrop-https-stderr.txt 2016-02-06 16:19:54.332442544 +0100 @@ -1,2 +1,2 @@ -Error message was: ([Cc]ould *n.t resolve host:? '?-no-site-'?|The requested URL returned error:.*|Protocol "https" not supported or disabled in .*|.* was built with SSL disabled.*) +Error message was: ([Cc]ould *n.t resolve host:? '?-no-site-'?.*|The requested URL returned error:.*|Protocol "https" not supported or disabled in .*|.* was built with SSL disabled.*) Problems when submitting via HTTP diff -urt cmake-3.4.3-orig/Tests/RunCMake/ctest_submit/FailDrop-http-stderr.txt cmake-3.4.3/Tests/RunCMake/ctest_submit/FailDrop-http-stderr.txt --- cmake-3.4.3-orig/Tests/RunCMake/ctest_submit/FailDrop-http-stderr.txt 2016-01-25 17:57:22.000000000 +0100 +++ cmake-3.4.3/Tests/RunCMake/ctest_submit/FailDrop-http-stderr.txt 2016-02-06 16:19:17.430908893 +0100 @@ -1,2 +1,2 @@ -Error message was: ([Cc]ould *n.t resolve host:? '?-no-site-'?|The requested URL returned error:.*) +Error message was: ([Cc]ould *n.t resolve host:? '?-no-site-'?.*|The requested URL returned error:.*) Problems when submitting via HTTP ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-07 17:53 Orion PoplawskiNew Issue ====================================================================== From cedric.perthuis at gmail.com Sun Feb 7 19:01:47 2016 From: cedric.perthuis at gmail.com (Cedric Perthuis) Date: Sun, 7 Feb 2016 16:01:47 -0800 Subject: [cmake-developers] Visual Studio 2015 Makefile Project (GDB) Message-ID: Hi, Visual studio has a new interesting extension which adds the project type "Makefile Project (GDB)". I am interested in exploring adding this project type to cmake, and probably to the Visual Studio 2015 generator. It's used to build and debug a program using GDB over an SSH connection, it's mainly targeted at developing Linux programs from the Visual Studio IDE. It doesn't include the build, it only hooks the build command of VS to a user defined windows command. Up to that command to use SSH to execute code on the target. It's a VS 2015 NMake project type with 3 config files for build command, run command, and SSH parameters. Some of the interesting parts of the vcxproj LinuxDebugger ssh gdb gdb {8E0AD268-B47B-4ED3-B9E0-F93E5CB1077B} Makefile true v140 false false <_ApplicableDebuggers>Desktop LinuxDebugger And the 3 config files: Neither the project nor the config files include any source file (I am sure we can add cpp files but they won't be associated with any compiler). The project has slots for build and debug command. As a user you have to write a build command which transfers of sources via SSH and do the compilation yourself. Here's an example of build command that the user can use build.bat $(RemoteHostName) $(RemoteUserName) $(PrivateKey) $(SecureShellExecutable) $(RemoteWorkingDirectory) $(RemoteExecutable) The build.bat would be something along those lines: "%SecureShellExecutable%" %RemoteUserName%@%RemoteHostName% -i "%PrivateKey%" "mkdir -p %RemoteWorkingDirectory%" "%SecureShellCopy%" -i "%PrivateKey%" source.cpp %RemoteUserName%@ %RemoteHostName%:%RemoteWorkingDirectory%/source.cpp "%SecureShellExecutable%" %RemoteUserName%@%RemoteHostName% -i "%PrivateKey%" "cd %RemoteWorkingDirectory%;g++ -g source.cpp -o %RemoteExecutable%" Adding a generator for this is probably straightforward, but to respect the format of the other cmake (and make it easier for the developer), I think it should go further and also generate a linux makefile. - the vs2015 generator can be augmented to create this new project type - the linux makefile can already be generated from the makefile generator. My question is what would be a good way to combine those 2. I was thinking of trying to invoke the makefile generator from the vs2015 generator? Any thoughts or advice? Thanks, Cedric -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric.perthuis at gmail.com Sun Feb 7 23:38:37 2016 From: cedric.perthuis at gmail.com (Cedric Perthuis) Date: Sun, 7 Feb 2016 20:38:37 -0800 Subject: [cmake-developers] Visual Studio 2015 Makefile Project (GDB) In-Reply-To: References: Message-ID: I did some experiments, and I think it's a bit easier than I thought. I don't think I need to generate the linux makefile from the Visual Studio generator on windows. I would just add few new cmake options for the Visual Studio GDB project type and among those the "build command" option. And as a user, in the build command option, I can simply execute a script on the target which calls cmake there to generate the makefile and then call make. On Sun, Feb 7, 2016 at 4:01 PM, Cedric Perthuis wrote: > Hi, > > Visual studio has a new interesting extension which adds the project type > "Makefile Project (GDB)". > > I am interested in exploring adding this project type to cmake, and > probably to the Visual Studio 2015 generator. > > It's used to build and debug a program using GDB over an SSH connection, > it's mainly targeted at developing Linux programs from the Visual Studio > IDE. It doesn't include the build, it only hooks the build command of VS to > a user defined windows command. Up to that command to use SSH to execute > code on the target. > > It's a VS 2015 NMake project type with 3 config files for build command, > run command, and SSH parameters. Some of the interesting parts of the > vcxproj > > > LinuxDebugger > ssh > gdb > gdb > {8E0AD268-B47B-4ED3-B9E0-F93E5CB1077B} > > > Label="Configuration"> > Makefile > true > v140 > > > > > false > false > <_ApplicableDebuggers>Desktop > LinuxDebugger > > > And the 3 config files: > > > > > > > Neither the project nor the config files include any source file (I am > sure we can add cpp files but they won't be associated with any compiler). > The project has slots for build and debug command. As a user you have to > write a build command which transfers of sources via SSH and do the > compilation yourself. > > Here's an example of build command that the user can use > > build.bat $(RemoteHostName) $(RemoteUserName) $(PrivateKey) > $(SecureShellExecutable) $(RemoteWorkingDirectory) $(RemoteExecutable) > > The build.bat would be something along those lines: > "%SecureShellExecutable%" %RemoteUserName%@%RemoteHostName% -i > "%PrivateKey%" "mkdir -p %RemoteWorkingDirectory%" > "%SecureShellCopy%" -i "%PrivateKey%" source.cpp %RemoteUserName%@ > %RemoteHostName%:%RemoteWorkingDirectory%/source.cpp > "%SecureShellExecutable%" %RemoteUserName%@%RemoteHostName% -i > "%PrivateKey%" "cd %RemoteWorkingDirectory%;g++ -g source.cpp -o > %RemoteExecutable%" > > Adding a generator for this is probably straightforward, but to respect > the format of the other cmake (and make it easier for the developer), I > think it should go further and also generate a linux makefile. > > - the vs2015 generator can be augmented to create this new project type > - the linux makefile can already be generated from the makefile generator. > > My question is what would be a good way to combine those 2. I was thinking > of trying to invoke the makefile generator from the vs2015 generator? > > Any thoughts or advice? > > Thanks, > Cedric > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Mon Feb 8 02:56:41 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 8 Feb 2016 02:56:41 -0500 Subject: [cmake-developers] [CMake 0015959]: Using CMake-Gui to run generate for Windows followed by generate for Unix generates incorrect Unix makefiles Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15959 ====================================================================== Reported By: Jon Kristensen Assigned To: ====================================================================== Project: CMake Issue ID: 15959 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-08 02:56 EST Last Modified: 2016-02-08 02:56 EST ====================================================================== Summary: Using CMake-Gui to run generate for Windows followed by generate for Unix generates incorrect Unix makefiles Description: Running a generator that uses the Windows Shell, and then running a generator that uses the Unix shell without exiting Cmake-gui first, causes the Unix makefiles to have the wrong shell command (SHELL = cmd.exe) and Windows path names (with ?\?s instead of ?/?s). Steps to Reproduce: 1. Start cmake-gui 2. Select a project that uses the Visual Studio 2015 generator and run generate 3. Select a project that uses the CDT4 ? Unix makefiles and run generate Additional Information: Assumed cause (based on cmake-3.4.3 source distribution) : The selection of shell seems to be based on the variable cmState::windowsShell This variable is set to false in the cmState constructor, and is set to true (through a call to member SetWindowsShell(true) from all generators that use a Windows shell. But I could find no code that resets it if a non-Windows-Shell generator is run at a later time ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-08 02:56 Jon Kristensen New Issue ====================================================================== From Arnau.Quintana at king.com Mon Feb 8 02:51:33 2016 From: Arnau.Quintana at king.com (Arnau Quintana) Date: Mon, 8 Feb 2016 07:51:33 +0000 Subject: [cmake-developers] Xcode generator is adding old attributes on .pbxproj In-Reply-To: <56B5CE14.4010403@googlemail.com> References: <56B4BB9C.1090009@kitware.com> <61F736FE-7D52-4F57-A76A-C12D8CC2FF87@king.com> <56B5CE14.4010403@googlemail.com> Message-ID: Hi Gregor, I am so glad to hear this! :) It will be great to join efforts. I have used xcproj, and it is kind of a quick and temporal solution for us (and maybe others), but I really want to understand all the implications and what cmake generates for Xcode projects. For instance, I found out that some options are not set up correctly on the original pbxproj, and xcproj is not setting up them in the new one. It would be better to get cmake set them properly on the first place. :) About the schemes, that is also a great idea. It would be nice that cmake could do that, so people do not need to rely on other tools for the schemes. It is good to know that there is other people working on this. Thanks, Arnau On 06/02/16 11:42, "Gregor Jasny" wrote: >Hello, > >some time ago I started a project to make the CMake generated pbxproj >identical to the one Xcode writes. Some patches of that effort are >already in master, some lack some cleanup. > >It would be great working with you on individual patches to 'modernize' >generated pbxproj files. Patches would be a superb start. > >Note: you could use the xcproj tool to ask Xcode to re-generate the >project by running "xcproj touch". > >I also intend to work on generating schema directly from CMake but this >will take some time. > >Thanks, >Gregor From costy.petrisor at gmail.com Mon Feb 8 06:39:51 2016 From: costy.petrisor at gmail.com (Costy Petrisor) Date: Mon, 8 Feb 2016 11:39:51 +0000 Subject: [cmake-developers] [PATCH] updated a couple of hidden includes made to support CMake's dependency scanning Message-ID: Hello, I don't know if this patch helps or not, I am not a CMake contributor, but while checking the code for how a feature is implemented, I found that a few hidden includes (to support CMake's dependency scanning) were not up to date. I did not found a mailing list for kwsys, so I emailed this one instead. I built this patch in CMake's copy of kwsys, not the standalone kwsys repo. Hope it helps, Costy --- >From 556ee6b4fe653925d5d71e64194002958368d64b Mon Sep 17 00:00:00 2001 From: Costy Petrisor Date: Mon, 8 Feb 2016 11:27:53 +0000 Subject: [PATCH] updated a couple of hidden includes made to support CMake's dependency scanning --- CommandLineArguments.cxx | 1 + ProcessWin32.c | 2 +- SystemInformation.cxx | 1 - SystemTools.cxx | 1 + testHashSTL.cxx | 1 - testIOS.cxx | 6 ++++++ 6 files changed, 9 insertions(+), 3 deletions(-) diff --git a/CommandLineArguments.cxx b/CommandLineArguments.cxx index 3636836..f713294 100644 --- a/CommandLineArguments.cxx +++ b/CommandLineArguments.cxx @@ -20,6 +20,7 @@ #if 0 # include "CommandLineArguments.hxx.in" # include "Configure.hxx.in" +# include "String.hxx.in" #endif #include diff --git a/ProcessWin32.c b/ProcessWin32.c index 1f8749f..eabd85f 100644 --- a/ProcessWin32.c +++ b/ProcessWin32.c @@ -17,7 +17,7 @@ duplicate the above list of headers. */ #if 0 # include "Process.h.in" -# include "Encoding_c.h.in" +# include "Encoding.h.in" #endif /* diff --git a/SystemInformation.cxx b/SystemInformation.cxx index cddcc8d..a33bb6f 100644 --- a/SystemInformation.cxx +++ b/SystemInformation.cxx @@ -43,7 +43,6 @@ #if 0 # include "SystemInformation.hxx.in" # include "Process.h.in" -# include "Configure.hxx.in" #endif #include diff --git a/SystemTools.cxx b/SystemTools.cxx index e3428f8..3d8c79a 100644 --- a/SystemTools.cxx +++ b/SystemTools.cxx @@ -39,6 +39,7 @@ // Work-around CMake dependency scanning limitation. This must // duplicate the above list of headers. #if 0 +# include "RegularExpression.hxx.in" # include "SystemTools.hxx.in" # include "Directory.hxx.in" # include "FStream.hxx.in" diff --git a/testHashSTL.cxx b/testHashSTL.cxx index ab1f83e..ae66ceb 100644 --- a/testHashSTL.cxx +++ b/testHashSTL.cxx @@ -18,7 +18,6 @@ #if 0 # include "hash_map.hxx.in" # include "hash_set.hxx.in" -# include "hashtable.hxx.in" #endif #include diff --git a/testIOS.cxx b/testIOS.cxx index 396a09d..5ff7955 100644 --- a/testIOS.cxx +++ b/testIOS.cxx @@ -18,6 +18,12 @@ #include #include /* strlen */ +// Work-around CMake dependency scanning limitation. This must +// duplicate the above list of headers. +#if 0 +# include "Configure.hxx.in" +#endif + int testIOS(int, char*[]) { std::ostringstream ostr; -- 2.7.0.windows.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mabuze at aon.at Mon Feb 8 06:55:25 2016 From: mabuze at aon.at (Horst Kronstorfer) Date: Mon, 8 Feb 2016 12:55:25 +0100 Subject: [cmake-developers] [PATCH] Help: Fix command specification for cmake_minimum_required Message-ID: <1454932525-29654-1-git-send-email-mabuze@aon.at> Implementation indicates that at least two components of VERSION must be specified (see Source/cmCMakeMinimumRequired.cxx.) Therefore the minor version is not optional. --- Help/command/cmake_minimum_required.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Help/command/cmake_minimum_required.rst b/Help/command/cmake_minimum_required.rst index 8573218..dc65a9e 100644 --- a/Help/command/cmake_minimum_required.rst +++ b/Help/command/cmake_minimum_required.rst @@ -5,7 +5,7 @@ Set the minimum required version of cmake for a project. :: - cmake_minimum_required(VERSION major[.minor[.patch[.tweak]]] + cmake_minimum_required(VERSION major.minor[.patch[.tweak]] [FATAL_ERROR]) If the current version of CMake is lower than that required it will -- 2.5.0 From sean at rogue-research.com Mon Feb 8 10:21:21 2016 From: sean at rogue-research.com (Sean McBride) Date: Mon, 8 Feb 2016 10:21:21 -0500 Subject: [cmake-developers] Drop support for older Xcode versions? In-Reply-To: <56B5CFA3.5090107@googlemail.com> References: <56B5CFA3.5090107@googlemail.com> Message-ID: <20160208152121.1630645796@mail.rogue-research.com> On Sat, 6 Feb 2016 11:49:07 +0100, Gregor Jasny via cmake-developers said: >I'd like to get your feedback on deprecating or dropping support for >older Xcode versions. During changes on the Xcode generator it gets >harder and harder to test against old and very old Xcode versions like 3 >and 4. > >Are there still users around for these versions of Xcode? Wikipedia has a nice table of Xcode & OS X: The problem with supporting only current - 1 as Eric suggests is that also excludes older versions of OS X, see the 'min OS X to run' column. What's the oldest version of Xcode that CMake currently supports? Personally, I think supporting Xcode 5.0+ would be reasonable at this point. It was released about 2.5 years ago and can run on OS X 10.8. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From apbarrero at gmail.com Mon Feb 8 10:29:50 2016 From: apbarrero at gmail.com (=?UTF-8?Q?Antonio_P=C3=A9rez_Barrero?=) Date: Mon, 08 Feb 2016 15:29:50 +0000 Subject: [cmake-developers] [PATCH] FindProtobuf: check version In-Reply-To: References: <1454401750-31859-1-git-send-email-antonioperez@by.com.es> Message-ID: Hi, thanks for feedback, I'll rework the patch. I was planning to actually submit three patches covering the following: * Version checking * Interface variables rename, keeping backwards compatibility. * Fix a bug when setting Protobuf_LIBRARIES on Un*x systems. So what's the best way to submit them: * A separate format-patch for each. * An all together patch. * Fork github's repo, create a branch and send a link here. Thanks, Antonio El mar., 2 feb. 2016 a las 16:18, Rolf Eike Beer () escribi?: > > + > > + set(Protobuf_VERSION 0) > > Just set it to an empty string. > > > + set(Protobuf_LIB_VERSION "") > > + file(STRINGS ${_Protobuf_COMMON_HEADER} _Protobuf_COMMON_H_CONTENTS > > REGEX "#define GOOGLE_PROTOBUF_VERSION ") > > I would replace the spaces with "[ \t]+" so a formatting change will not > break the extraction, also below. > > > + set(_Protobuf_VERSION_REGEX "([0-9]+)") > > No need for that variable, just put it into the matches argument below. > > > + if("${_Protobuf_COMMON_H_CONTENTS}" MATCHES "#define > > GOOGLE_PROTOBUF_VERSION ${_Protobuf_VERSION_REGEX}") > > + set(Protobuf_VERSION "${CMAKE_MATCH_1}") > > + endif() > > + unset(_Protobuf_COMMON_H_CONTENTS) > > + > > + math(EXPR Protobuf_MAJOR_VERSION "${Protobuf_VERSION} / 1000000") > > + math(EXPR Protobuf_MINOR_VERSION "${Protobuf_VERSION} / 1000 % > > 1000") > > + math(EXPR Protobuf_SUBMINOR_VERSION "${Protobuf_VERSION} % 1000") > > You are not required to export these variables, only if you expect it to > be useful for something beyond version checking. If anyone needs > specific version fiddling Protobuf_VERSION can be used. > > Eike > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Feb 8 10:31:17 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 8 Feb 2016 10:31:17 -0500 Subject: [cmake-developers] Drop support for older Xcode versions? In-Reply-To: <20160208152121.1630645796@mail.rogue-research.com> References: <56B5CFA3.5090107@googlemail.com> <20160208152121.1630645796@mail.rogue-research.com> Message-ID: <56B8B4C5.9090806@kitware.com> On 02/07/2016 01:54 PM, Michael Jackson wrote: >> What is the oldest version of OS X that CMake actually runs on? >> I guess I would support the last version of Xcode that actually >> ran on that platform. In reality this is probably 10.6.8? [snip] On 02/08/2016 10:21 AM, Sean McBride wrote: > What's the oldest version of Xcode that CMake currently supports? We still have nightly testing on OS X 10.4 with Xcode 2.5. It was in support of the i386/ppc universal release binary but that was dropped as of CMake 3.4. Now it is really only "just in case" and because the machine running the tests has not died yet. I'm not opposed to dropping Xcode generator support for it since anyone with such an old machine can always use the makefile generator. Sean, it looks like you are still running nightly tests on OS X 10.6 with Xcode 4.2: https://open.cdash.org/viewNotes.php?buildid=4226138 and OS X 10.5 with Xcode 3.1: https://open.cdash.org/viewNotes.php?buildid=4226202 but perhaps do not need the actual Xcode IDE generator to work. > Personally, I think supporting Xcode 5.0+ would be reasonable at this point. > It was released about 2.5 years ago and can run on OS X 10.8. Given Apple's encouragement of developers to always update I think that would be reasonable for the Xcode IDE generator. Xcode older than 6 or so will not even run on OS X 10.11. Let's give this thread a while to see if anyone else has feedback. Thanks, -Brad From brad.king at kitware.com Mon Feb 8 10:31:21 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 8 Feb 2016 10:31:21 -0500 Subject: [cmake-developers] Drop support for older Xcode versions? In-Reply-To: <20160208152121.1630645796@mail.rogue-research.com> References: <56B5CFA3.5090107@googlemail.com> <20160208152121.1630645796@mail.rogue-research.com> Message-ID: <56B8B4C9.1070502@kitware.com> On 02/07/2016 01:54 PM, Michael Jackson wrote: >> What is the oldest version of OS X that CMake actually runs on? >> I guess I would support the last version of Xcode that actually >> ran on that platform. In reality this is probably 10.6.8? [snip] On 02/08/2016 10:21 AM, Sean McBride wrote: > What's the oldest version of Xcode that CMake currently supports? We still have nightly testing on OS X 10.4 with Xcode 2.5. It was in support of the i386/ppc universal release binary but that was dropped as of CMake 3.4. Now it is really only "just in case" and because the machine running the tests has not died yet. I'm not opposed to dropping Xcode generator support for it since anyone with such an old machine can always use the makefile generator. Sean, it looks like you are still running nightly tests on OS X 10.6 with Xcode 4.2: https://open.cdash.org/viewNotes.php?buildid=4226138 and OS X 10.5 with Xcode 3.1: https://open.cdash.org/viewNotes.php?buildid=4226202 but perhaps do not need the actual Xcode IDE generator to work. > Personally, I think supporting Xcode 5.0+ would be reasonable at this point. > It was released about 2.5 years ago and can run on OS X 10.8. Given Apple's encouragement of developers to always update I think that would be reasonable for the Xcode IDE generator. Xcode older than 6 or so will not even run on OS X 10.11. Let's give this thread a while to see if anyone else has feedback. Thanks, -Brad From brad.king at kitware.com Mon Feb 8 10:31:52 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 8 Feb 2016 10:31:52 -0500 Subject: [cmake-developers] [PATCH] updated a couple of hidden includes made to support CMake's dependency scanning In-Reply-To: References: Message-ID: <56B8B4E8.3080202@kitware.com> On 02/08/2016 06:39 AM, Costy Petrisor wrote: > I did not found a mailing list for kwsys, so I emailed this one instead. That's fine, thanks. I applied it for testing in upstream KWSys here: http://review.source.kitware.com/20765 After integration there it will be updated in CMake. Thanks! -Brad From brad.king at kitware.com Mon Feb 8 10:31:59 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 8 Feb 2016 10:31:59 -0500 Subject: [cmake-developers] [PATCH] Help: fix mistake in cmake-buildsystem(7) In-Reply-To: References: Message-ID: <56B8B4EF.4050705@kitware.com> On 02/07/2016 03:46 PM, Paul Wilkinson wrote: > The COMPATIBLE_INTERFACE_NUMBER_MAX example now sets > INTERFACE_CONTAINER_SIZE_REQUIRED on lib1Version2 and lib1Version3 (it > previously set it on lib1Version2 twice and never on > lib1Version3. Probably a copy-paste mistake?) Applied, thanks: Help: Fix mistake in cmake-buildsystem(7) example https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d8c90800 -Brad From brad.king at kitware.com Mon Feb 8 10:32:11 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 8 Feb 2016 10:32:11 -0500 Subject: [cmake-developers] [PATCH] Bug fix: Dylibs inside .framework folders fails in BundleUtilities.cmake. In-Reply-To: References: <56B4BE1B.5050200@kitware.com> Message-ID: <56B8B4FB.2040509@kitware.com> On 02/07/2016 11:25 AM, Christian Askeland wrote: > We could reuse the check from gp_item_default_embedded_path(), instead of > looking at the result from that function: > > if((item NOT MATCHES "\\.dylib$") AND (item MATCHES "[^/]+\\.framework/")) > > I haven't tested the line above, but can do so tomorrow and post a new patch, > if it looks reasonable. Yes, I think that looks good. Thanks, -Brad From brad.king at kitware.com Mon Feb 8 10:32:04 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 8 Feb 2016 10:32:04 -0500 Subject: [cmake-developers] [PATCH] Help: Fix command specification for cmake_minimum_required In-Reply-To: <1454932525-29654-1-git-send-email-mabuze@aon.at> References: <1454932525-29654-1-git-send-email-mabuze@aon.at> Message-ID: <56B8B4F4.1040306@kitware.com> On 02/08/2016 06:55 AM, Horst Kronstorfer wrote: > Implementation indicates that at least two components of VERSION must > be specified (see Source/cmCMakeMinimumRequired.cxx.) Therefore the > minor version is not optional. Applied, thanks: Help: Fix command specification for cmake_minimum_required https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3b91d16 -Brad From alinm.elena at gmail.com Mon Feb 8 10:35:04 2016 From: alinm.elena at gmail.com (Alin Marin Elena) Date: Mon, 08 Feb 2016 15:35:04 +0000 Subject: [cmake-developers] FeatureSummary and Fortran In-Reply-To: References: Message-ID: <1914976.Ws0G0VLGNO@baphomet.dl.ac.uk> Hi, I was playing to day with FeatureSummary and Fortran and I discovered the two do not like each other too much . While MPI is obviously found in here... Feature summary claims it did not -- The Fortran compiler identification is GNU 5.3.1 -- Check for working Fortran compiler: /usr/bin/gfortran -- Check for working Fortran compiler: /usr/bin/gfortran -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether /usr/bin/gfortran supports Fortran 90 -- Checking whether /usr/bin/gfortran supports Fortran 90 -- yes -- Found MPI_Fortran: /opt/openmpi/gcc/1.10.1/lib64/libmpi_usempif08.so;/opt/ openmpi/gcc/1.10.1/lib64/libmpi_usempi_ignore_tkr.so;/opt/openmpi/gcc/1.10.1/ lib64/libmpi_mpifh.so;/opt/openmpi/gcc/1.10.1/lib64/libmpi.so -- -- The following REQUIRED packages have not been found: * MPI CMake Error at /usr/share/cmake/Modules/FeatureSummary.cmake:556 (message): feature_summary() Error: REQUIRED package(s) are missing, aborting CMake run. Call Stack (most recent call first): CMakeLists.txt:6 (feature_summary) -- Configuring incomplete, errors occurred! See also "/home/alin/playground/cmake/summary/build/CMakeFiles/ CMakeOutput.log". if I replace Fortran as language with C all is fine as expected. (The same happens if I add C to the project) A simple simple way to reproduce is the following CMakeLists.txt project(testM Fortran) cmake_minimum_required(VERSION 2.8) include(FeatureSummary) find_package(MPI REQUIRED) feature_summary(WHAT ALL FATAL_ON_MISSING_REQUIRED_PACKAGES) I see this on linux cmake 3.4.3 I wonder if this is a bug or a feature? Regards, Alin -- Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From ben.boeckel at kitware.com Mon Feb 8 10:45:34 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 8 Feb 2016 10:45:34 -0500 Subject: [cmake-developers] [PATCH] FindProtobuf: check version In-Reply-To: References: <1454401750-31859-1-git-send-email-antonioperez@by.com.es> Message-ID: <20160208154534.GA30843@megas.kitware.com> On Mon, Feb 08, 2016 at 15:29:50 +0000, Antonio P?rez Barrero wrote: > thanks for feedback, I'll rework the patch. I was planning to actually > submit three patches covering the following: > > * Version checking > * Interface variables rename, keeping backwards compatibility. > * Fix a bug when setting Protobuf_LIBRARIES on Un*x systems. Looks like a sensible breakdown to me. > So what's the best way to submit them: > > * A separate format-patch for each. This one. Sending it as a series of 3 patches is best (and easy if you use git send-email). Best is that the earlier patches fix bugs and such so that if they are OK, they're more easily applied independently if later patches have issues which need resolving yet. Thanks, --Ben From sean at rogue-research.com Mon Feb 8 10:48:30 2016 From: sean at rogue-research.com (Sean McBride) Date: Mon, 8 Feb 2016 10:48:30 -0500 Subject: [cmake-developers] Drop support for older Xcode versions? In-Reply-To: <56B8B4C5.9090806@kitware.com> References: <56B5CFA3.5090107@googlemail.com> <20160208152121.1630645796@mail.rogue-research.com> <56B8B4C5.9090806@kitware.com> Message-ID: <20160208154830.1125542189@mail.rogue-research.com> On Mon, 8 Feb 2016 10:31:17 -0500, Brad King said: >Sean, it looks like you are still running nightly tests on OS X >10.6 with Xcode 4.2: > > https://open.cdash.org/viewNotes.php?buildid=4226138 > >and OS X 10.5 with Xcode 3.1: > > https://open.cdash.org/viewNotes.php?buildid=4226202 Yeah, mostly because those machines haven't died either. :) If/when it's decided to drop those Xcodes, I'll switch those builds to makefile generator. >Given Apple's encouragement of developers to always update... They certainly do, as Eric described. However, just like everyone else, Apple often ships regressions in Xcode and it's sometimes vital to be able to use older versions. Similarly, if you want to deploy an app to an older OS, it's very useful to be able to build-run-debug on that OS, and since the newest Xcodes only run on the newest OSes, one needs an older Xcode to test/debug on older OSes. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From apbarrero at gmail.com Mon Feb 8 11:47:21 2016 From: apbarrero at gmail.com (Antonio Perez Barrero) Date: Mon, 8 Feb 2016 17:47:21 +0100 Subject: [cmake-developers] [PATCH] FindProtobuf: fix wrong library list for Unix Message-ID: <1454950041-28132-1-git-send-email-antonioperez@by.com.es> Avoid looking for debug library unless configuring for MSVC. Before this change the variable PROTOBUF_LIBRARIES under unix was 'optimized;/usr/lib/libprotobuf.so;debug;/usr/lib/libprotobuf.so' --- Modules/FindProtobuf.cmake | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake index 2f13b09..a07aa83 100644 --- a/Modules/FindProtobuf.cmake +++ b/Modules/FindProtobuf.cmake @@ -219,10 +219,12 @@ function(_protobuf_find_libraries name filename) PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Release) mark_as_advanced(${name}_LIBRARY) - find_library(${name}_LIBRARY_DEBUG - NAMES ${filename} - PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug) - mark_as_advanced(${name}_LIBRARY_DEBUG) + if(MSVC) + find_library(${name}_LIBRARY_DEBUG + NAMES ${filename} + PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug) + mark_as_advanced(${name}_LIBRARY_DEBUG) + endif() if(NOT ${name}_LIBRARY_DEBUG) # There is no debug library -- 1.9.1 From brad.king at kitware.com Mon Feb 8 13:23:34 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 8 Feb 2016 13:23:34 -0500 Subject: [cmake-developers] CMake 3.5 generation time In-Reply-To: <56B4BCEA.6020201@kitware.com> References: <56B35287.9010309@kitware.com> <56B39116.3090101@kitware.com> <56B4BCEA.6020201@kitware.com> Message-ID: <56B8DD26.9010504@kitware.com> On 02/05/2016 10:16 AM, Brad King wrote: > It looks like these methods: > > cmGlobalGenerator::FindTargetImpl > cmGlobalGenerator::FindGeneratorTargetImpl > cmGlobalGenerator::FindImportedTargetImpl > > are all now using linear searches instead of algorithmically > efficient data structures like before. This should fix it: Fix internal target lookup performance regression https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6cbf6a51 Improve internal generator target structure lookup https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9b7d5871 -Brad From brad.king at kitware.com Mon Feb 8 13:28:11 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 8 Feb 2016 13:28:11 -0500 Subject: [cmake-developers] [PATCH] FindProtobuf: fix wrong library list for Unix In-Reply-To: <1454950041-28132-1-git-send-email-antonioperez@by.com.es> References: <1454950041-28132-1-git-send-email-antonioperez@by.com.es> Message-ID: <56B8DE3B.7070502@kitware.com> On 02/08/2016 11:47 AM, Antonio Perez Barrero wrote: > Avoid looking for debug library unless configuring for MSVC. [snip] > - find_library(${name}_LIBRARY_DEBUG > - NAMES ${filename} > - PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug) > - mark_as_advanced(${name}_LIBRARY_DEBUG) > + if(MSVC) > + find_library(${name}_LIBRARY_DEBUG > + NAMES ${filename} > + PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug) > + mark_as_advanced(${name}_LIBRARY_DEBUG) > + endif() It is possible someone builds a debug-named library on unix too. See `select_library_configurations` and its uses in other find modules. That is the conventional way to normalize libraries across configurations. Thanks, -Brad From brad.king at kitware.com Mon Feb 8 13:32:25 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 8 Feb 2016 13:32:25 -0500 Subject: [cmake-developers] Question related to Visual Studio 14 2015 [MyTarget] In-Reply-To: References: Message-ID: <56B8DF39.2020704@kitware.com> On 02/05/2016 02:41 PM, Yi-Hong Lyu wrote: > 1. What I need to do is to add an option MyTarget for arch of > "Visual Studio 14 2015 [arch]", just like "Visual Studio 14 2015 [Win64]" > or "Visual Studio 14 2015 [ARM]"? Naming the architecture as part of the generator name is a legacy behavior. See the "-A " option. > 2. How can I support cl.exe and clang-cl.exe by Visual Studio 14 2015 [MyTarget]"? > Should I add options cl.exe/clang-cl.exe for toolset-name of "-T "? The -T option is indeed the CMake side of it. I'm not familiar with what else has to be done on the host to make VS understand the toolset name though. > 3. Is there any way to make sure that all x86/x64 headers/libraries are not included/linked? > I'd like only include/link headers/libraries of MyTarget. CMake doesn't add any system include directories or link directories. For command line builds those need to be part of the environment. For VS IDE builds they are made available by the IDE when running the toolchain based on the options discussed above. -Brad From apbarrero at gmail.com Mon Feb 8 16:24:35 2016 From: apbarrero at gmail.com (=?UTF-8?Q?Antonio_P=C3=A9rez_Barrero?=) Date: Mon, 08 Feb 2016 21:24:35 +0000 Subject: [cmake-developers] [PATCH] FindProtobuf: fix wrong library list for Unix In-Reply-To: <56B8DE3B.7070502@kitware.com> References: <1454950041-28132-1-git-send-email-antonioperez@by.com.es> <56B8DE3B.7070502@kitware.com> Message-ID: El lun., 8 feb. 2016 a las 19:28, Brad King () escribi?: > On 02/08/2016 11:47 AM, Antonio Perez Barrero wrote: > > Avoid looking for debug library unless configuring for MSVC. > [snip] > > - find_library(${name}_LIBRARY_DEBUG > > - NAMES ${filename} > > - PATHS > ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug) > > - mark_as_advanced(${name}_LIBRARY_DEBUG) > > + if(MSVC) > > + find_library(${name}_LIBRARY_DEBUG > > + NAMES ${filename} > > + PATHS > ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug) > > + mark_as_advanced(${name}_LIBRARY_DEBUG) > > + endif() > > It is possible someone builds a debug-named library on unix too. > See `select_library_configurations` and its uses in other find > modules. That is the conventional way to normalize libraries > across configurations. > > Yes, it is possible, but currently it's not looking for the debug library with a different name, just in a different path that is unlikely to exist in a Unix system. Having the PROTOBUF_LIBRARIES variable getting the afore mentioned value messes up the client code using `find_package(Protobuf)` on Unix. I might be wrong, but I think this patch solves one issue, while not introducing another for debug libraries under Unix, since it wasn't working either before applying it. Thanks, Antonio -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Feb 8 16:39:00 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 8 Feb 2016 16:39:00 -0500 Subject: [cmake-developers] [PATCH] FindProtobuf: fix wrong library list for Unix In-Reply-To: References: <1454950041-28132-1-git-send-email-antonioperez@by.com.es> <56B8DE3B.7070502@kitware.com> Message-ID: <56B90AF4.2030206@kitware.com> On 02/08/2016 04:24 PM, Antonio P?rez Barrero wrote: > Yes, it is possible, but currently it's not looking for the debug > library with a different name, just in a different path that is > unlikely to exist in a Unix system. The fact that a separate find_library is called for it and the result is stored in a separate (user-settable) cache entry means that it is possible to get two different values. This convention is well established in several find modules. > Having the PROTOBUF_LIBRARIES variable getting the afore mentioned > value messes up the client code using `find_package(Protobuf)` on Unix. The only supported use for PROTOBUF_LIBRARIES is to pass it to target_link_libraries, and that interprets the 'optimized' and 'debug' keywords. This is shown in the module documentation example: target_link_libraries(bar ${PROTOBUF_LIBRARIES}) The documentation makes no other guarantees about the variable value. -Brad From mantis at public.kitware.com Mon Feb 8 21:46:00 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 8 Feb 2016 21:46:00 -0500 Subject: [cmake-developers] [CMake 0015960]: cmake-gui crashes when I click configure or generate on GLFW project Message-ID: <475cd8b9a30b9334ffd252efe6a13a0e@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15960 ====================================================================== Reported By: Matt Schoen Assigned To: ====================================================================== Project: CMake Issue ID: 15960 Category: CMake Reproducibility: always Severity: crash Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-08 21:45 EST Last Modified: 2016-02-08 21:45 EST ====================================================================== Summary: cmake-gui crashes when I click configure or generate on GLFW project Description: I get a bunch of Access Violations if I open up a VS2015 debugger after the crash. I'm trying to do the first step of the process after pointing the tool at the source directory. Using native compilers. Current version of GLFW is commit hash is f51cf8114821b9c25d28b5572469de3c18ef446a Using cmake 3.5.0-rc1 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-08 21:45 Matt Schoen New Issue ====================================================================== From konstantin at podsvirov.pro Mon Feb 8 22:50:01 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Tue, 09 Feb 2016 06:50:01 +0300 Subject: [cmake-developers] [PATCH] FindProtobuf: fix wrong library list for Unix In-Reply-To: <56B90AF4.2030206@kitware.com> References: <1454950041-28132-1-git-send-email-antonioperez@by.com.es> <56B8DE3B.7070502@kitware.com> <56B90AF4.2030206@kitware.com> Message-ID: <2988241454989801@web22m.yandex.ru> Wonderful project "protobuf" ("protobuf" with a small letter "f") starting with version 3.0 (which is around the corner - now beta 2), will be built with CMake on Windows, and will contain CONFIG scripts with a description of the exported package and an imported goal. That's the name of the project: https://github.com/google/protobuf/blob/master/cmake/CMakeLists.txt#L5 All targets will be installed in the standard paths, which optionally can be configured to your needs (use the GNUInstallDirs module): https://github.com/google/protobuf/blob/master/cmake/install.cmake#L10 There is also the option to configure Postfix in a debug configuration (protobuf_DEBUG_POSTFIX - default "d"): https://github.com/google/protobuf/blob/master/cmake/CMakeLists.txt#L26 So for protobuf >= 3.0 on Windows you can use design: find_package(protobuf CONFIG) These new features were created with my participation. I tried to create a configuration compatible with the all of us known module. Here is a template script compatibility for the module: https://github.com/google/protobuf/blob/master/cmake/protobuf-module.cmake.in Unfortunately, for platforms other than Windows, use CMake to build protobuf not officially planned, but carried out private studies confirm the fact that cmake/CMakeLists workable on other platforms. Thus the project "protobuf" already cmake/CMakeLists.txt and is open to modifications and development for the benefit of the CMake community. While we will continue to work as follows: find_package(Protobuf [MODULE]) But over time, I hope to do just so: find_package(protobuf CONFIG) All suggestions and comments as always are welcome. And for publicity :-) You can try pre-built protobuf me 3.0 for Windows (MSVC2013) from Dad's Project (installers "testing"): http://dad.podsvirov.pro/house/installers (sorry for possible mistakes in text) 09.02.2016, 00:39, "Brad King" : > On 02/08/2016 04:24 PM, Antonio P?rez Barrero wrote: >> Yes, it is possible, but currently it's not looking for the debug >> library with a different name, just in a different path that is >> unlikely to exist in a Unix system. > > The fact that a separate find_library is called for it and the result > is stored in a separate (user-settable) cache entry means that it is > possible to get two different values. This convention is well established > find in several modules. > >> Having the variable PROTOBUF_LIBRARIES getting the afore mentioned >> value messes up the client code using `find_package(Protobuf)` on Unix. > > The only supported use for PROTOBUF_LIBRARIES is to pass it to > target_link_libraries, and that interprets the 'optimized' and 'debug' > keywords. This is shown in the module documentation example: > > target_link_libraries(bar ${PROTOBUF_LIBRARIES}) > > The documentation makes no other guarantees about the variable value. > > -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 Regards, Konstantin Podsvirov From tim at klingt.org Tue Feb 9 00:48:47 2016 From: tim at klingt.org (Tim Blechmann) Date: Tue, 9 Feb 2016 13:48:47 +0800 Subject: [cmake-developers] Drop support for older Xcode versions? In-Reply-To: <20160208154830.1125542189@mail.rogue-research.com> References: <56B5CFA3.5090107@googlemail.com> <20160208152121.1630645796@mail.rogue-research.com> <56B8B4C5.9090806@kitware.com> <20160208154830.1125542189@mail.rogue-research.com> Message-ID: >> Given Apple's encouragement of developers to always update... > > They certainly do, as Eric described. However, just like everyone > else, Apple often ships regressions in Xcode and it's sometimes vital > to be able to use older versions. Similarly, if you want to deploy > an app to an older OS, it's very useful to be able to build-run-debug > on that OS, and since the newest Xcodes only run on the newest OSes, > one needs an older Xcode to test/debug on older OSes. if a project relies on an old xcode version, does it need to use the most up-to-date cmake? also, there are always make/ninja generators ... From apbarrero at gmail.com Tue Feb 9 03:51:34 2016 From: apbarrero at gmail.com (=?UTF-8?Q?Antonio_P=C3=A9rez_Barrero?=) Date: Tue, 09 Feb 2016 08:51:34 +0000 Subject: [cmake-developers] [PATCH] FindProtobuf: check version In-Reply-To: <20160202145808.GB3429@megas.kitware.com> References: <1454401750-31859-1-git-send-email-antonioperez@by.com.es> <20160202145808.GB3429@megas.kitware.com> Message-ID: > > > + math(EXPR Protobuf_MAJOR_VERSION "${Protobuf_VERSION} / 1000000") > > + math(EXPR Protobuf_MINOR_VERSION "${Protobuf_VERSION} / 1000 % 1000") > > + math(EXPR Protobuf_SUBMINOR_VERSION "${Protobuf_VERSION} % 1000") > > Would string manipulation be better here? I don't know how to make it better. I took FindBoost.cmake code as template here. Which could be a better way? Thanks, Antonio -------------- next part -------------- An HTML attachment was scrubbed... URL: From apbarrero at gmail.com Tue Feb 9 05:10:28 2016 From: apbarrero at gmail.com (=?UTF-8?Q?Antonio_P=C3=A9rez_Barrero?=) Date: Tue, 09 Feb 2016 10:10:28 +0000 Subject: [cmake-developers] [PATCH] FindProtobuf: fix wrong library list for Unix In-Reply-To: <56B90AF4.2030206@kitware.com> References: <1454950041-28132-1-git-send-email-antonioperez@by.com.es> <56B8DE3B.7070502@kitware.com> <56B90AF4.2030206@kitware.com> Message-ID: > > On 02/08/2016 04:24 PM, Antonio P?rez Barrero wrote: > > Yes, it is possible, but currently it's not looking for the debug > > library with a different name, just in a different path that is > > unlikely to exist in a Unix system. > > The fact that a separate find_library is called for it and the result > is stored in a separate (user-settable) cache entry means that it is > possible to get two different values. This convention is well established > in several find modules. > > > Having the PROTOBUF_LIBRARIES variable getting the afore mentioned > > value messes up the client code using `find_package(Protobuf)` on Unix. > > The only supported use for PROTOBUF_LIBRARIES is to pass it to > target_link_libraries, and that interprets the 'optimized' and 'debug' > keywords. This is shown in the module documentation example: > > target_link_libraries(bar ${PROTOBUF_LIBRARIES}) > > The documentation makes no other guarantees about the variable value. > Thanks for your explanantion, that makes sense. I had issues because I was appending the value of PROTOBUF_LIBRARIES to a list and then removing duplicates before calling `target_link_libraries(bar ${LIST})`. So when the PROTOBUF_LIBRARIES values was `optimized;/usr/lib/libprotobuf.so;debug;/usr/lib/libprotobuf.so` I was missing the link flag for /usr/lib/libprotobuf.so in Debug builds. Skipping the duplicates removal step solves my issue. Anyway, the root cause is the `find_library` is finding the same library for optimized and debug configuration. So, would a patch like this be benefial? diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake index 2f13b09..35929a4 100644 --- a/Modules/FindProtobuf.cmake +++ b/Modules/FindProtobuf.cmake @@ -224,7 +224,7 @@ function(_protobuf_find_libraries name filename) PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug) mark_as_advanced(${name}_LIBRARY_DEBUG) - if(NOT ${name}_LIBRARY_DEBUG) + if((NOT ${name}_LIBRARY_DEBUG) OR (${name}_LIBRARY STREQUAL ${name}_LIBRARY_DEBUG)) # There is no debug library set(${name}_LIBRARY_DEBUG ${${name}_LIBRARY} PARENT_SCOPE) set(${name}_LIBRARIES ${${name}_LIBRARY} PARENT_SCOPE) --- Thanks, Antonio -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Tue Feb 9 05:13:45 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 09 Feb 2016 11:13:45 +0100 Subject: [cmake-developers] [PATCH] FindProtobuf: fix wrong library list for Unix In-Reply-To: References: <1454950041-28132-1-git-send-email-antonioperez@by.com.es> <56B8DE3B.7070502@kitware.com> <56B90AF4.2030206@kitware.com> Message-ID: <6d007e752b75d779619e5446a884e18c@sf-mail.de> Am 09.02.2016 11:10, schrieb Antonio P?rez Barrero: >> >> On 02/08/2016 04:24 PM, Antonio P?rez Barrero wrote: >> > Yes, it is possible, but currently it's not looking for the debug >> > library with a different name, just in a different path that is >> > unlikely to exist in a Unix system. >> >> The fact that a separate find_library is called for it and the result >> is stored in a separate (user-settable) cache entry means that it is >> possible to get two different values. This convention is well >> established >> in several find modules. >> >> > Having the PROTOBUF_LIBRARIES variable getting the afore mentioned >> > value messes up the client code using `find_package(Protobuf)` on Unix. >> >> The only supported use for PROTOBUF_LIBRARIES is to pass it to >> target_link_libraries, and that interprets the 'optimized' and 'debug' >> keywords. This is shown in the module documentation example: >> >> target_link_libraries(bar ${PROTOBUF_LIBRARIES}) >> >> The documentation makes no other guarantees about the variable value. >> > > Thanks for your explanantion, that makes sense. I had issues because I > was > appending the value of PROTOBUF_LIBRARIES to a list and then removing > duplicates before calling `target_link_libraries(bar ${LIST})`. So when > the > PROTOBUF_LIBRARIES values was > `optimized;/usr/lib/libprotobuf.so;debug;/usr/lib/libprotobuf.so` I was > missing the link flag for /usr/lib/libprotobuf.so in Debug builds. > Skipping > the duplicates removal step solves my issue. > > Anyway, the root cause is the `find_library` is finding the same > library > for optimized and debug configuration. So, would a patch like this be > benefial? > > diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake > index 2f13b09..35929a4 100644 > --- a/Modules/FindProtobuf.cmake > +++ b/Modules/FindProtobuf.cmake > @@ -224,7 +224,7 @@ function(_protobuf_find_libraries name filename) > PATHS > ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug) > mark_as_advanced(${name}_LIBRARY_DEBUG) > > - if(NOT ${name}_LIBRARY_DEBUG) > + if((NOT ${name}_LIBRARY_DEBUG) OR (${name}_LIBRARY STREQUAL > ${name}_LIBRARY_DEBUG)) > # There is no debug library > set(${name}_LIBRARY_DEBUG ${${name}_LIBRARY} PARENT_SCOPE) > set(${name}_LIBRARIES ${${name}_LIBRARY} PARENT_SCOPE) Just use SelectLibraryConfigurations, that does the same automatically if they are identical, and also handles the cases where only debug, but not release is found. Greetings, Eike From mantis at public.kitware.com Tue Feb 9 08:14:36 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 9 Feb 2016 08:14:36 -0500 Subject: [cmake-developers] [CMake 0015961]: CMake Regex does not support lookahead regular expressions. Message-ID: <2088e2d8053dd7cc35f153f0b1832c8c@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15961 ====================================================================== Reported By: raffael casagrande Assigned To: ====================================================================== Project: CMake Issue ID: 15961 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-09 08:14 EST Last Modified: 2016-02-09 08:14 EST ====================================================================== Summary: CMake Regex does not support lookahead regular expressions. Description: Trying to use a Regular expression that contains a lookahead clause is not supported by CMake. Steps to Reproduce: Try to execute the following CMake statement: string(REGEX MATH "(?!red|green|blue)" _bla ${CMAKE_CURRENT_LIST_DIR}) It will fail with: string sub-command REGEX, mode REPLACE failed to compile regex "(?!red|green|blue)". ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-09 08:14 raffael casagrandeNew Issue ====================================================================== From ddurham at davyandbeth.com Tue Feb 9 09:49:33 2016 From: ddurham at davyandbeth.com (Davy Durham) Date: Tue, 9 Feb 2016 08:49:33 -0600 Subject: [cmake-developers] Drop support for older Xcode versions? In-Reply-To: References: <56B5CFA3.5090107@googlemail.com> <20160208152121.1630645796@mail.rogue-research.com> <56B8B4C5.9090806@kitware.com> <20160208154830.1125542189@mail.rogue-research.com> Message-ID: <56B9FC7D.9080705@davyandbeth.com> I'll say that in my line of work, we still have to support OS X 10.6 (just dropped 10.5 support) .. And we're doing this at Apple's own request/demand! It's not fun. I've had to hack tools around to get somewhat newer tool chains to continue to work, but it's been /great/ that cmake hasn't been an obstacle in this endeavour. On 02/08/2016 11:48 PM, Tim Blechmann wrote: >>> Given Apple's encouragement of developers to always update... >> They certainly do, as Eric described. However, just like everyone >> else, Apple often ships regressions in Xcode and it's sometimes vital >> to be able to use older versions. Similarly, if you want to deploy >> an app to an older OS, it's very useful to be able to build-run-debug >> on that OS, and since the newest Xcodes only run on the newest OSes, >> one needs an older Xcode to test/debug on older OSes. > if a project relies on an old xcode version, does it need to use the > most up-to-date cmake? also, there are always make/ninja generators ... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ddurham at davyandbeth.com Tue Feb 9 10:45:34 2016 From: ddurham at davyandbeth.com (Davy Durham) Date: Tue, 9 Feb 2016 09:45:34 -0600 Subject: [cmake-developers] Drop support for older Xcode versions? In-Reply-To: <56B9FC7D.9080705@davyandbeth.com> References: <56B5CFA3.5090107@googlemail.com> <20160208152121.1630645796@mail.rogue-research.com> <56B8B4C5.9090806@kitware.com> <20160208154830.1125542189@mail.rogue-research.com> <56B9FC7D.9080705@davyandbeth.com> Message-ID: <56BA099E.2090708@davyandbeth.com> I should also have mentioned that we're supporting a number of other platforms at the same time.. hence our use of cmake. And would rather not have to maintain cmake files that are lowest-common-denominator for the version of cmake that has to continue working on OS X 10.6 On 02/09/2016 08:49 AM, Davy Durham wrote: > I'll say that in my line of work, we still have to support OS X 10.6 > (just dropped 10.5 support) .. And we're doing this at Apple's own > request/demand! It's not fun. I've had to hack tools around to get > somewhat newer tool chains to continue to work, but it's been /great/ > that cmake hasn't been an obstacle in this endeavour. > > > > > > On 02/08/2016 11:48 PM, Tim Blechmann wrote: >>>> Given Apple's encouragement of developers to always update... >>> They certainly do, as Eric described. However, just like everyone >>> else, Apple often ships regressions in Xcode and it's sometimes vital >>> to be able to use older versions. Similarly, if you want to deploy >>> an app to an older OS, it's very useful to be able to build-run-debug >>> on that OS, and since the newest Xcodes only run on the newest OSes, >>> one needs an older Xcode to test/debug on older OSes. >> if a project relies on an old xcode version, does it need to use the >> most up-to-date cmake? also, there are always make/ninja generators ... >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gilles.Khouzam at microsoft.com Tue Feb 9 12:15:05 2016 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Tue, 9 Feb 2016 17:15:05 +0000 Subject: [cmake-developers] Question related to Visual Studio 14 2015 [MyTarget] In-Reply-To: <56B8DF39.2020704@kitware.com> References: <56B8DF39.2020704@kitware.com> Message-ID: I'm trying to understand what is necessary to make this work. I'll circle back when I find out more information. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Monday, February 8, 2016 10:32 To: Yi-Hong Lyu Cc: cmake-developers at cmake.org; Gilles Khouzam Subject: Re: [cmake-developers] Question related to Visual Studio 14 2015 [MyTarget] On 02/05/2016 02:41 PM, Yi-Hong Lyu wrote: > 1. What I need to do is to add an option MyTarget for arch of "Visual > Studio 14 2015 [arch]", just like "Visual Studio 14 2015 [Win64]" > or "Visual Studio 14 2015 [ARM]"? Naming the architecture as part of the generator name is a legacy behavior. See the "-A " option. > 2. How can I support cl.exe and clang-cl.exe by Visual Studio 14 2015 [MyTarget]"? > Should I add options cl.exe/clang-cl.exe for toolset-name of "-T "? The -T option is indeed the CMake side of it. I'm not familiar with what else has to be done on the host to make VS understand the toolset name though. > 3. Is there any way to make sure that all x86/x64 headers/libraries are not included/linked? > I'd like only include/link headers/libraries of MyTarget. CMake doesn't add any system include directories or link directories. For command line builds those need to be part of the environment. For VS IDE builds they are made available by the IDE when running the toolchain based on the options discussed above. -Brad From jamesbigler at gmail.com Tue Feb 9 13:00:13 2016 From: jamesbigler at gmail.com (James Bigler) Date: Tue, 09 Feb 2016 18:00:13 +0000 Subject: [cmake-developers] Changes for v3.5.0 Message-ID: Will changes integrated into master automatically be slated for either v3.5.0 RC2 or v.3.5.0 final? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Feb 9 13:50:25 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 9 Feb 2016 13:50:25 -0500 Subject: [cmake-developers] Changes for v3.5.0 In-Reply-To: References: Message-ID: <56BA34F1.7020504@kitware.com> On 02/09/2016 01:00 PM, James Bigler wrote: > Will changes integrated into master automatically be slated for either > v3.5.0 RC2 or v.3.5.0 final? No, the development window for 3.5 closed on Feb 1: https://cmake.org/pipermail/cmake-developers/2016-February/027637.html -Brad From irwin at beluga.phys.uvic.ca Tue Feb 9 14:39:30 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 9 Feb 2016 11:39:30 -0800 (PST) Subject: [cmake-developers] Changes for v3.5.0 In-Reply-To: <56BA34F1.7020504@kitware.com> References: <56BA34F1.7020504@kitware.com> Message-ID: On 2016-02-09 13:50-0500 Brad King wrote: > On 02/09/2016 01:00 PM, James Bigler wrote: >> Will changes integrated into master automatically be slated for either >> v3.5.0 RC2 or v.3.5.0 final? > > No, the development window for 3.5 closed on Feb 1: > > https://cmake.org/pipermail/cmake-developers/2016-February/027637.html Hi Brad: So what branch should we follow if we want to test the on-going 3.5.x effort? I assumed it would be "release", but one of the key fixes to 3.5.0-rc1 is the efficiency one from my perspective, but I cannot find either "Fix internal target lookup performance regression" or "Improve internal generator target structure lookup" at . Are those changes being "cooked" a bit longer or are they already in the release branch under some different title? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From brad.king at kitware.com Tue Feb 9 14:51:25 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 9 Feb 2016 14:51:25 -0500 Subject: [cmake-developers] Changes for v3.5.0 In-Reply-To: References: <56BA34F1.7020504@kitware.com> Message-ID: <56BA433D.5080808@kitware.com> On 02/09/2016 02:39 PM, Alan W. Irwin wrote: > So what branch should we follow if we want to test the on-going 3.5.x > effort? > > I assumed it would be "release" Yes. I just merged several of the fixes there this morning. > but one of the key fixes to 3.5.0-rc1 is the efficiency one [snip] > Are those changes being "cooked" a bit longer or are they already in > the release branch under some different title? They are cooking in 'master' for few days. This will give Bartosz (who reported the performance problem) some time to confirm the fixes work. The fixes are also available in the nightly binaries since those are built from 'next'. -Brad From mantis at public.kitware.com Tue Feb 9 15:00:36 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 9 Feb 2016 15:00:36 -0500 Subject: [cmake-developers] [CMake 0015962]: can't unzip jar file on windows Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15962 ====================================================================== Reported By: nitroamos Assigned To: ====================================================================== Project: CMake Issue ID: 15962 Category: CMake Reproducibility: always Severity: minor Priority: low Status: new ====================================================================== Date Submitted: 2016-02-09 15:00 EST Last Modified: 2016-02-09 15:00 EST ====================================================================== Summary: can't unzip jar file on windows Description: I'd like to use cmake to unpack a .jar file. To do this, I use the following command in my CMakeLists.txt: execute_process(COMMAND ${CMAKE_COMMAND} -E tar xf ${MY_JAR} --format=zip ${CMAKE_CURRENT_BINARY_DIR}/ ) Which I run through the CMake GUI. This command works as intended on OSX. On Windows, I get the following error when configuring: COMMAND C:/Program Files (x86)/CMake/bin/cmake.exe -E tar xf my.jar --format=zip build CMake Error: Problem with archive_write_header(): Can't create '\\?\C:\Program Files (x86)\CMake\META-INF\MANIFEST.MF' CMake Error: Current file: META-INF/MANIFEST.MF CMake Error: Problem extracting tar: my.jar Steps to Reproduce: cmake_minimum_required(VERSION 2.8.9) project(extractjar) message("COMMAND ${CMAKE_COMMAND} -E tar xf ${CMAKE_SOURCE_DIR}/my.jar --format=zip ${CMAKE_CURRENT_BINARY_DIR}/") execute_process(COMMAND ${CMAKE_COMMAND} -E tar xf ${CMAKE_SOURCE_DIR}/my.jar --format=zip ${CMAKE_CURRENT_BINARY_DIR}/ ) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-09 15:00 nitroamos New Issue ====================================================================== From insertinterestingnamehere at gmail.com Tue Feb 9 15:32:20 2016 From: insertinterestingnamehere at gmail.com (Ian Henriksen) Date: Tue, 09 Feb 2016 20:32:20 +0000 Subject: [cmake-developers] Question related to Visual Studio 14 2015 [MyTarget] In-Reply-To: References: <56B8DF39.2020704@kitware.com> Message-ID: On Tue, Feb 9, 2016 at 10:15 AM Gilles Khouzam wrote: > I'm trying to understand what is necessary to make this work. I'll circle > back when I find out more information. > > -----Original Message----- > From: Brad King [mailto:brad.king at kitware.com] > Sent: Monday, February 8, 2016 10:32 > To: Yi-Hong Lyu > Cc: cmake-developers at cmake.org; Gilles Khouzam < > Gilles.Khouzam at microsoft.com> > Subject: Re: [cmake-developers] Question related to Visual Studio 14 2015 > [MyTarget] > > On 02/05/2016 02:41 PM, Yi-Hong Lyu wrote: > > 1. What I need to do is to add an option MyTarget for arch of "Visual > > Studio 14 2015 [arch]", just like "Visual Studio 14 2015 [Win64]" > > or "Visual Studio 14 2015 [ARM]"? > > Naming the architecture as part of the generator name is a legacy behavior. > See the "-A " option. > > > 2. How can I support cl.exe and clang-cl.exe by Visual Studio 14 2015 > [MyTarget]"? > > Should I add options cl.exe/clang-cl.exe for toolset-name of "-T > "? > > The -T option is indeed the CMake side of it. I'm not familiar with what > else has to be done on the host to make VS understand the toolset name > though. > > > 3. Is there any way to make sure that all x86/x64 headers/libraries are > not included/linked? > > I'd like only include/link headers/libraries of MyTarget. > > CMake doesn't add any system include directories or link directories. For > command line builds those need to be part of the environment. For VS IDE > builds they are made available by the IDE when running the toolchain based > on the options discussed above. > I've been experimenting with this lately. When building with NMake, adding the flag "-fms-compatibility-version=19.00.23506" got clang to act like the right version of MSVC. MSVC 2013 is the default right now. When building with the generator "Visual Studio 14 2015 Win64", adding the toolset flag "-TLLVM-vs2014" got clang to work. https://github.com/boostorg/hana/wiki/Setting-up-Clang-on-Windows was really helpful in figuring some of this out. All that aside, seamless interaction between clang-cl and MSVC 2015 is definitely still a work in progress. Best, -Ian Henriksen > > -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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Feb 9 16:29:02 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 9 Feb 2016 16:29:02 -0500 Subject: [cmake-developers] FeatureSummary and Fortran In-Reply-To: <1914976.Ws0G0VLGNO@baphomet.dl.ac.uk> References: <1914976.Ws0G0VLGNO@baphomet.dl.ac.uk> Message-ID: <56BA5A1E.7070505@kitware.com> On 02/08/2016 10:35 AM, Alin Marin Elena wrote: > I was playing to day with FeatureSummary and Fortran and I discovered the two > do not like each other too much . While MPI is obviously found in here... > Feature summary claims it did not > > -- Found MPI_Fortran: /opt/openmpi/gcc/1.10.1/lib64/libmpi_usempif08.so;/opt/ > openmpi/gcc/1.10.1/lib64/libmpi_usempi_ignore_tkr.so;/opt/openmpi/gcc/1.10.1/ > lib64/libmpi_mpifh.so;/opt/openmpi/gcc/1.10.1/lib64/libmpi.so Technically it was "MPI_Fortran" that was found. It looks like FindMPI distinguishes each of the languages as a kind of sub-package: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindMPI.cmake;hb=v3.4.3#l14 This is different from most other find modules because the results need to be language-specific. The actual MPI_FOUND variable is set only based on MPI_CXX_FOUND or MPI_C_FOUND for compatibility with when there was no language distinction: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindMPI.cmake;hb=v3.4.3#l620 I think MPI_Fortran_FOUND was left out of that because there was no support for Fortran MPI originally and this language distinction was added as part of adding support for Fortran. I was not involved with that development process myself so I do not know for sure. One could look at updating the code to treat setting MPI_FOUND as an official result (as needed by find_package with REQUIRED) rather than only for compatibility. This would mean reconciling MPI_C_FOUND, MPI_CXX_FOUND, and MPI_Fortran_FOUND. I'm not sure the proper approach because we do not know which languages the caller actually needs. -Brad From mantis at public.kitware.com Tue Feb 9 16:52:46 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 9 Feb 2016 16:52:46 -0500 Subject: [cmake-developers] [CMake 0015963]: strange behaviour running readlink via execute_process Message-ID: <03e7298fb28742b2b7e02d6bd4f6ec7c@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15963 ====================================================================== Reported By: Bruce Adams Assigned To: ====================================================================== Project: CMake Issue ID: 15963 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-09 16:52 EST Last Modified: 2016-02-09 16:52 EST ====================================================================== Summary: strange behaviour running readlink via execute_process Description: I'm trying to use readlink -f to get the absolute path to a shared library following all symlinks. >readlink -f /opt/gcc4.9.3/lib64/libstdc++.so.6 /opt/gcc4.9.3/lib64/libstdc++.so.6.0.20 but when I do this in cmake it doesn't expand the full path E.g. set(CPP11_PATH ${CMAKE_CURRENT_BINARY_DIR}/) execute_process(COMMAND ldd ${CPP11_PATH} COMMAND grep libstdc++ COMMAND awk "{ print $3; }" OUTPUT_VARIABLE LIBSTDCPP_PATH) message("LIBSTDCPP_PATH=${LIBSTDCPP_PATH}") execute_process(COMMAND readlink -f ${LIBSTDCPP_PATH} OUTPUT_VARIABLE LIBSTDCPP_ABSPATH) message("LIBSTDCPP_ABSPATH=${LIBSTDCPP_ABSPATH}") prints: LIBSTDCPP_PATH=/opt/gcc4.9.3/lib64/libstdc++.so.6 LIBSTDCPP_ABSPATH=/opt/gcc4.9.3/lib64/libstdc++.so.6 This also happens if I wrap it in a shell script: execute_process(COMMAND doreadlink.sh ${LIBSTDCPP_PATH} OUTPUT_VARIABLE LIBSTDCPP_ABSPATH2) message("LIBSTDCPP_ABSPATH2=${LIBSTDCPP_ABSPATH2}") >LIBSTDCPP_ABSPATH2=/opt/gcc4.9.3/lib64/libstdc++.so.6 Steps to Reproduce: cmake_minimum_required(VERSION 2.8) project(TEST CXX) CMake script as below set(CPP11_PATH ${CMAKE_CURRENT_BINARY_DIR}/cpp11) execute_process(COMMAND g++ ${CMAKE_CURRENT_SOURCE_DIR}/cpp11.cpp -o${CPP11_PATH}) execute_process(COMMAND ldd ${CPP11_PATH} COMMAND grep libstdc++ COMMAND awk "{ print $3; }" OUTPUT_VARIABLE LIBSTDCPP_PATH) message("LIBSTDCPP_PATH=${LIBSTDCPP_PATH}") execute_process(COMMAND readlink -f ${LIBSTDCPP_PATH} OUTPUT_VARIABLE LIBSTDCPP_ABSPATH) message("LIBSTDCPP_ABSPATH=${LIBSTDCPP_ABSPATH}") Additional Information: The following is an effective work around execute_process(COMMAND ldd ${CPP11_PATH} COMMAND grep libstdc++ COMMAND awk "{ print $3; }" COMMAND xargs readlink -f OUTPUT_VARIABLE LIBSTDCPP_PATH) Originally raised on stackoverflow: http://stackoverflow.com/questions/35299970/strange-behaviour-with-readlink-under-cmake ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-09 16:52 Bruce Adams New Issue ====================================================================== From steveire at gmail.com Tue Feb 9 18:07:44 2016 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 10 Feb 2016 00:07:44 +0100 Subject: [cmake-developers] CMake Daemon blog References: Message-ID: Stephen Kelly wrote: > Hi, > > I just made a blog and video about the advanced features and possibilities > that a daemon mode for CMake can bring: > > https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ > The lack of response on the list to any of this is quite disappointing. From steveire at gmail.com Tue Feb 9 18:09:07 2016 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 10 Feb 2016 00:09:07 +0100 Subject: [cmake-developers] Developer tasks - Daemon mode Message-ID: The Daemon mode for CMake is online here: https://github.com/steveire/CMake/tree/cmake-daemon The commit messages and some of the commits contain indications of things that need to be done before such a mode could be introduced into CMake, such as writing a new failsafe parser and implementing some of the features in the branch so that they work well in all cases. I won't repeat those tasks in a list here, but they prevent the Daemon from becoming upstreamable. There are other tasks which prevent the Daemon being upstreamable to cmake proper. These are not tasks for raw-beginners: 1) Using libuv filesystem notification to re-generate the cmState when buildsystem files change (and notifying the client through the protocol about resulting changes in the generated buildsystem). This is by far the most essential. 2) Prune state which is created while operating. The parts of the protocol which execute some cmake code (eg, debugging and code completion) create cmState::Snapshots without cleaning them up afterward (or possibly using an LRU cache if such a thing would make sense). I can provide guidance to anyone wishing to complete them, or any of the tasks described in the cmake-daemon branch. Thanks, Steve. From steveire at gmail.com Tue Feb 9 18:12:21 2016 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 10 Feb 2016 00:12:21 +0100 Subject: [cmake-developers] Developer tasks - Refactoring Message-ID: In order to make it possible to implement fully featured user tools like the cmake daemon https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ ... and to make it possible to use multiple toolchains at once http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7272 ... and turn CMake into a fully capable modern cross-compiling buildsystem http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10873 ... the implementation of CMake needs to improve. At least if any of those advanced features are to be maintainable. A large amount of the steps to get there involve refactoring the existing CMake code to be more flexible. I have been doing that since April last year, but I want to open up the task list to other collaborators and newcomers in particular. Here are some entry-level refactoring tasks which have a useful impact on CMake, and which lead to more familiarity with the code for whoever does them. Feel free to ask for further guidance on any task. 1) Make cmLocalGenerator not inherit cmOutputConverter * Change enums like cmLocalGenerator::START_OUTPUT with sed. See https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eac15298 for a similar sed command to achieve this. * Remove inheritance. Implement Convert() methods in cmLocalGenerator for source compatibility which instantiate and use a cmOutputConverter as in https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d8b79ad 2) Reduce generate-time use of cmMakefile definitions * The intention is to remove direct use of cmMakefile from generate-time code. * Use an IDE to find uses of cmGeneratorTarget::Makefile and cmGeneratorTarget::Target * Replace use of 'low-level' GetDefinition from cmMakefile with more 'high-level' methods on cmGeneratorTarget. Eg this->Target->Target->GetMakefile()->GetDefinition("CMAKE_STRIP") in cmComputeLinkInformation could be replaced with a new std::string cmGeneratorTarget::GetCMakeStripTool() const; or similar. 3) Compute cmGeneratorTarget state non-lazily in its constructor. * Historically target state for generators was computed lazily because it might need to be cleared and re-computed. That is no-longer true. * For example, the LinkInformation is populated lazily in cmGeneratorTarget::GetLinkInformation. * Instead the LinkInformation could be populated in the cmGeneratorTarget constructor for all known configurations. That is what generators will request during generate-time anyway. * Doing this will make it possible to split a cmComputedTarget out of cmGeneratorTarget. Thanks, Steve. From steveire at gmail.com Tue Feb 9 18:44:55 2016 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 10 Feb 2016 00:44:55 +0100 Subject: [cmake-developers] CMake Daemon References: Message-ID: Stephen Kelly wrote: > Tam?s Ken?z wrote: > >> That's great and really does open a new world for IDEs! > > Thanks! Let's see if the interest grows. > > I've just pushed the daemon code here: > > https://github.com/steveire/cmake/tree/cmake-daemon Tobias made a pull request there. Rather than review it there, I will review it here for visibility. https://github.com/steveire/CMake/pull/2 The branch is quite it hard to review, or even to see the particular changes, due to large commits and diff noise. If the Daemon reaches a level of completeness that it could be upstreamed (See http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15740 ) then these commits (including all of my commits on the branch) would have to be rewritten, split, made reviewable etc making heavy use of `rebase -i`. In a way, we don't have to do that now, but I'm also not very enthusiastic about making the `cmake-daemon` branch commits unreadable. I would add your commits to the branch if they we split and in the appropriate place (eg, with the cmServerProtocol0_1 change early in the cmake-daemon branch). The changes in your branch are good and useful to more than just QtCreator. Things that I like in your branch: * Explicit cmServerRequest and cmServerResponse APIs, which enforce the type and cookie consistency. * Returning cmServerResponse objects from the cmServerProtocol instead of invoking the server from the cmServerProtocol. * A way to version the protocol in a future-proof way with C++ classes. * Implementation of daemon and protocol error messaging infrastructure. (Reporting errors from cmake code requires other refactoring: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607/focus=15636) So I think that is progress! Thanks, Steve. From tobias.hunger at gmail.com Wed Feb 10 03:42:20 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Wed, 10 Feb 2016 09:42:20 +0100 Subject: [cmake-developers] CMake Daemon blog In-Reply-To: References: Message-ID: Hey, I did send a MR on github:-) But I agree, I had also hoped for more active participation. Best Regards, Tobias On Wed, Feb 10, 2016 at 12:07 AM, Stephen Kelly wrote: > Stephen Kelly wrote: > >> Hi, >> >> I just made a blog and video about the advanced features and possibilities >> that a daemon mode for CMake can bring: >> >> https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ >> > > > The lack of response on the list to any of this is quite disappointing. > > -- > > 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 From mantis at public.kitware.com Wed Feb 10 03:51:34 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 10 Feb 2016 03:51:34 -0500 Subject: [cmake-developers] [CMake 0015964]: Borland Makefile generation Script Message-ID: <9fe75c6b6e99f8b93ec3980685a18d58@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15964 ====================================================================== Reported By: David We Assigned To: ====================================================================== Project: CMake Issue ID: 15964 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-10 03:51 EST Last Modified: 2016-02-10 03:51 EST ====================================================================== Summary: Borland Makefile generation Script Description: The Borland makefiles are not configured correctly. These defines are missing after the cmake process is finished. #define HAVE_STRTOULL 1 #define HAVE_GETADDRINFO 1 #define HAVE_NTOHLL 1 Additional Information: I'am using the bcc32 from RadStudio Seattle ( XE10 ). ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-10 03:51 David We New Issue ====================================================================== From apbarrero at gmail.com Wed Feb 10 04:36:04 2016 From: apbarrero at gmail.com (=?UTF-8?Q?Antonio_P=C3=A9rez_Barrero?=) Date: Wed, 10 Feb 2016 09:36:04 +0000 Subject: [cmake-developers] [PATCH] FindProtobuf: fix wrong library list for Unix In-Reply-To: <6d007e752b75d779619e5446a884e18c@sf-mail.de> References: <1454950041-28132-1-git-send-email-antonioperez@by.com.es> <56B8DE3B.7070502@kitware.com> <56B90AF4.2030206@kitware.com> <6d007e752b75d779619e5446a884e18c@sf-mail.de> Message-ID: El mar., 9 feb. 2016 a las 11:13, Rolf Eike Beer () escribi?: > Am 09.02.2016 11:10, schrieb Antonio P?rez Barrero: > >> > >> On 02/08/2016 04:24 PM, Antonio P?rez Barrero wrote: > >> > Yes, it is possible, but currently it's not looking for the debug > >> > library with a different name, just in a different path that is > >> > unlikely to exist in a Unix system. > >> > >> The fact that a separate find_library is called for it and the result > >> is stored in a separate (user-settable) cache entry means that it is > >> possible to get two different values. This convention is well > >> established > >> in several find modules. > >> > >> > Having the PROTOBUF_LIBRARIES variable getting the afore mentioned > >> > value messes up the client code using `find_package(Protobuf)` on > Unix. > >> > >> The only supported use for PROTOBUF_LIBRARIES is to pass it to > >> target_link_libraries, and that interprets the 'optimized' and 'debug' > >> keywords. This is shown in the module documentation example: > >> > >> target_link_libraries(bar ${PROTOBUF_LIBRARIES}) > >> > >> The documentation makes no other guarantees about the variable value. > >> > > > > Thanks for your explanantion, that makes sense. I had issues because I > > was > > appending the value of PROTOBUF_LIBRARIES to a list and then removing > > duplicates before calling `target_link_libraries(bar ${LIST})`. So when > > the > > PROTOBUF_LIBRARIES values was > > `optimized;/usr/lib/libprotobuf.so;debug;/usr/lib/libprotobuf.so` I was > > missing the link flag for /usr/lib/libprotobuf.so in Debug builds. > > Skipping > > the duplicates removal step solves my issue. > > > > Anyway, the root cause is the `find_library` is finding the same > > library > > for optimized and debug configuration. So, would a patch like this be > > benefial? > > > > diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake > > index 2f13b09..35929a4 100644 > > --- a/Modules/FindProtobuf.cmake > > +++ b/Modules/FindProtobuf.cmake > > @@ -224,7 +224,7 @@ function(_protobuf_find_libraries name filename) > > PATHS > > ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug) > > mark_as_advanced(${name}_LIBRARY_DEBUG) > > > > - if(NOT ${name}_LIBRARY_DEBUG) > > + if((NOT ${name}_LIBRARY_DEBUG) OR (${name}_LIBRARY STREQUAL > > ${name}_LIBRARY_DEBUG)) > > # There is no debug library > > set(${name}_LIBRARY_DEBUG ${${name}_LIBRARY} PARENT_SCOPE) > > set(${name}_LIBRARIES ${${name}_LIBRARY} PARENT_SCOPE) > > Just use SelectLibraryConfigurations, that does the same automatically > if they are identical, and also handles the cases where only debug, but > not release is found. > Thanks, I tried that and got it working. I'll submit another patch as the change covers a related but different issue. Regards, Antonio > Greetings, > > Eike > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From apbarrero at gmail.com Wed Feb 10 04:36:31 2016 From: apbarrero at gmail.com (Antonio Perez Barrero) Date: Wed, 10 Feb 2016 10:36:31 +0100 Subject: [cmake-developers] [PATCH] FindProtobuf: prevent redundant PROTOBUF_LIBRARIES Message-ID: <1455096991-10548-1-git-send-email-antonioperez@by.com.es> Before this change, the variable PROTOBUF_LIBRARIES might get redundant value for debug and optimized configurations, e.g. 'optimized;/usr/lib/libprotobuf.so;debug;/usr/lib/libprotobuf.so' --- Modules/FindProtobuf.cmake | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake index 2f13b09..57c6e62 100644 --- a/Modules/FindProtobuf.cmake +++ b/Modules/FindProtobuf.cmake @@ -213,6 +213,8 @@ endif() # Internal function: search for normal library as well as a debug one # if the debug one is specified also include debug/optimized keywords # in *_LIBRARIES variable +include(SelectLibraryConfigurations) + function(_protobuf_find_libraries name filename) find_library(${name}_LIBRARY NAMES ${filename} @@ -224,18 +226,10 @@ function(_protobuf_find_libraries name filename) PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug) mark_as_advanced(${name}_LIBRARY_DEBUG) - if(NOT ${name}_LIBRARY_DEBUG) - # There is no debug library - set(${name}_LIBRARY_DEBUG ${${name}_LIBRARY} PARENT_SCOPE) - set(${name}_LIBRARIES ${${name}_LIBRARY} PARENT_SCOPE) - else() - # There IS a debug library - set(${name}_LIBRARIES - optimized ${${name}_LIBRARY} - debug ${${name}_LIBRARY_DEBUG} - PARENT_SCOPE - ) - endif() + select_library_configurations(${name}) + set(${name}_LIBRARY_DEBUG ${${name}_LIBRARY_DEBUG} PARENT_SCOPE) + set(${name}_LIBRARY ${${name}_LIBRARY} PARENT_SCOPE) + set(${name}_LIBRARIES ${${name}_LIBRARIES} PARENT_SCOPE) endfunction() # Internal function: find threads library -- 1.9.1 From gang65 at poczta.onet.pl Wed Feb 10 05:34:22 2016 From: gang65 at poczta.onet.pl (Bartosz Kosiorek) Date: Wed, 10 Feb 2016 11:34:22 +0100 Subject: [cmake-developers] Changes for v3.5.0 In-Reply-To: <56BA433D.5080808@kitware.com> References: <56BA34F1.7020504@kitware.com> <56BA433D.5080808@kitware.com> Message-ID: Good Morning/Evening. I have great news. With Nighly Build 3.5.20160208 the regression was gone, and the Generation performance is almost the as with CMake 3.4.3. Here are details: Version 3.2.2 real 2m0.780s user 1m55.704s sys 0m2.360s Version 3.4.3 real 1m30.223s user 1m24.816s sys 0m3.004s Version 3.5.0rc1 real 6m20.086s user 6m15.836s sys 0m3.600s Version nigtly build 3.5.20160208 real 1m29.047s user 1m24.232s sys 0m3.040s Thank you Bartosz 2016-02-09 20:51 GMT+01:00 Brad King : > On 02/09/2016 02:39 PM, Alan W. Irwin wrote: > > So what branch should we follow if we want to test the on-going 3.5.x > > effort? > > > > I assumed it would be "release" > > Yes. I just merged several of the fixes there this morning. > > > but one of the key fixes to 3.5.0-rc1 is the efficiency one > [snip] > > Are those changes being "cooked" a bit longer or are they already in > > the release branch under some different title? > > They are cooking in 'master' for few days. This will give Bartosz > (who reported the performance problem) some time to confirm the fixes > work. > > The fixes are also available in the nightly binaries since those > are built from 'next'. > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hunger at gmail.com Wed Feb 10 05:37:16 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Wed, 10 Feb 2016 11:37:16 +0100 Subject: [cmake-developers] CMake Daemon In-Reply-To: References: Message-ID: Hi Stephen, I will then continue down that road. Next steps are a way to consistently report progress as well as being able to have several protocol versions at the same time and have a client pick one. I will just put them atop my current branch, as that is going to need basically the same amount of retro-active integration into similar places as the current changes. I am not keen on doing that twice:-) Best Regards, Tobias On Wed, Feb 10, 2016 at 12:44 AM, Stephen Kelly wrote: > Stephen Kelly wrote: > >> Tam?s Ken?z wrote: >> >>> That's great and really does open a new world for IDEs! >> >> Thanks! Let's see if the interest grows. >> >> I've just pushed the daemon code here: >> >> https://github.com/steveire/cmake/tree/cmake-daemon > > Tobias made a pull request there. Rather than review it there, I will review > it here for visibility. > > https://github.com/steveire/CMake/pull/2 > > The branch is quite it hard to review, or even to see the particular > changes, due to large commits and diff noise. If the Daemon reaches a level > of completeness that it could be upstreamed (See > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15740 > > ) then these commits (including all of my commits on the branch) would have > to be rewritten, split, made reviewable etc making heavy use of `rebase -i`. > > In a way, we don't have to do that now, but I'm also not very enthusiastic > about making the `cmake-daemon` branch commits unreadable. I would add your > commits to the branch if they we split and in the appropriate place (eg, > with the cmServerProtocol0_1 change early in the cmake-daemon branch). > > The changes in your branch are good and useful to more than just QtCreator. > > Things that I like in your branch: > > * Explicit cmServerRequest and cmServerResponse APIs, which enforce the type > and cookie consistency. > * Returning cmServerResponse objects from the cmServerProtocol instead of > invoking the server from the cmServerProtocol. > * A way to version the protocol in a future-proof way with C++ classes. > * Implementation of daemon and protocol error messaging infrastructure. > (Reporting errors from cmake code requires other refactoring: > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607/focus=15636) > > So I think that is progress! > > Thanks, > > Steve. > > > > -- > > 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 From mantis at public.kitware.com Wed Feb 10 07:26:59 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 10 Feb 2016 07:26:59 -0500 Subject: [cmake-developers] [CMake 0015965]: D3DCOMPILER_XX.dll included by fixup_bundle Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15965 ====================================================================== Reported By: Robin KERDILES Assigned To: ====================================================================== Project: CMake Issue ID: 15965 Category: CMake Reproducibility: always Severity: trivial Priority: none Status: new ====================================================================== Date Submitted: 2016-02-10 07:26 EST Last Modified: 2016-02-10 07:26 EST ====================================================================== Summary: D3DCOMPILER_XX.dll included by fixup_bundle Description: D3DCOMPILER_XX.dll is included by fixup_bundle when I resolve dependencies where it should not because this is provided by system. Steps to Reproduce: * Try to build a CMake project using directx libraries (at least linking to d3dcompiler) and use fixup_bundle on executables. Additional Information: * Windows 10 Pro 1511 (10.0.10586) x64 * Visual Studio Enterprise 2015 Update 1 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-10 07:26 Robin KERDILES New Issue ====================================================================== From mantis at public.kitware.com Wed Feb 10 08:53:59 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 10 Feb 2016 08:53:59 -0500 Subject: [cmake-developers] [CMake 0015966]: BundleUtilities unconditionally removes RPATH in copy_resolved_item_into_bundle Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15966 ====================================================================== Reported By: Florian Apolloner Assigned To: ====================================================================== Project: CMake Issue ID: 15966 Category: CCMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-10 08:53 EST Last Modified: 2016-02-10 08:53 EST ====================================================================== Summary: BundleUtilities unconditionally removes RPATH in copy_resolved_item_into_bundle Description: copy_resolved_item_into_bundle always removes the RPATH for libraries copied into the bundle: https://github.com/Kitware/CMake/blob/0def7e6e70d809958cb605e93dbe3d02baf05265/Modules/BundleUtilities.cmake#L625 This is often fine, but if your libraries depend on other libraries which are not available on the system, this will prevent the from getting found. In my case it was app -> libQt5Core.so.5 -> libicu.so whereas libQt5Core.so.5 from the precompiled SDK has $ORIGIN as RPATH since libicu is shipped along with it. Could be just drop that check or make it configurable? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-10 08:53 Florian ApollonerNew Issue ====================================================================== From brad.king at kitware.com Wed Feb 10 09:16:47 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 10 Feb 2016 09:16:47 -0500 Subject: [cmake-developers] Changes for v3.5.0 In-Reply-To: References: <56BA34F1.7020504@kitware.com> <56BA433D.5080808@kitware.com> Message-ID: <56BB464F.7090005@kitware.com> On 02/10/2016 05:34 AM, Bartosz Kosiorek wrote: > I have great news. > With Nighly Build 3.5.20160208 the regression was gone Great, thanks for testing this! -Brad From mantis at public.kitware.com Wed Feb 10 09:31:34 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 10 Feb 2016 09:31:34 -0500 Subject: [cmake-developers] [CMake 0015967]: CMAKE_AUTOMOC + OBJECT library in a subdirectory -> Failing ninja builds Message-ID: <696ebabd9a9e322622f912dc53ade0fb@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15967 ====================================================================== Reported By: Artur K. Assigned To: ====================================================================== Project: CMake Issue ID: 15967 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-10 09:31 EST Last Modified: 2016-02-10 09:31 EST ====================================================================== Summary: CMAKE_AUTOMOC + OBJECT library in a subdirectory -> Failing ninja builds Description: Projects using this combination of features fail to build with: " Assembler messages: Fatal error: can't create lib/CMakeFiles/*****.dir: Is a directory " the same project works perfectly when a Makefile is generated. Steps to Reproduce: 1. Unpack the provided minimal project: 2. run `mkdir bld; cd bld; cmake -G "Ninja" ..; ninja` Additional Information: ninja version = 1.6.0 qt5 version = 5.5.1 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-10 09:31 Artur K. New Issue 2016-02-10 09:31 Artur K. File Added: cmake_qt5_automoc_object.tar.gz ====================================================================== From michael.stuermer at schaeffler.com Wed Feb 10 09:03:00 2016 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Wed, 10 Feb 2016 14:03:00 +0000 Subject: [cmake-developers] C# support ready for review Message-ID: <903866b8ac604d15a1bfb1d3c8c7afe1@DE013666.schaeffler.com> Native C# support is ready for review. I split the patch in two parts: part 1: Some preparational stuff that does not really change or enable anything. Documentation and Test files as well as the required CMake module is added. The changes to existing code are small, only few methods in existing classes are added/changed. Changes to existing code should be easy to review in this part part 2: This contains the main work. Almost everything takes place within cmVisualStudio10TargetGenerator. In addition to C# support three more target properties were introduced: - VS_USER_PROPS_CXX (allows use of custom .user.props MSBuild file in .vcxproj files) - VS_USER_PROPS_CSHARP (allows use of custom .user.props MSBuild file in .csproj files) - VS_DEBUGGER_WORKING_DIRECTORY (allows setting of debugger working directory in .vcxproj files) I tested the features using Visual Studio 2010-2015 in 32/64 bit and everything works on my machine so far. Please review/test/comment and give feedback what is necessary to get native C# support in upstream cmake. best regards, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-prepared-C-support.patch Type: application/octet-stream Size: 41066 bytes Desc: 0001-prepared-C-support.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-implemented-C-support.patch Type: application/octet-stream Size: 43761 bytes Desc: 0002-implemented-C-support.patch URL: From charles.huet at gmail.com Wed Feb 10 10:57:14 2016 From: charles.huet at gmail.com (Charles Huet) Date: Wed, 10 Feb 2016 15:57:14 +0000 Subject: [cmake-developers] Ninja and add_subdirectory EXCLUDE_FROM_ALL Message-ID: Hi, I have a folder in my build that is added as such: "add_subdirectory(folder EXCLUDE_FROM_ALL)" When using Unix Makefiles (or MSVC) this causes the subfolder to contain a new Makefile, allowing me to build easily the whole subdir. I cannot find such a facility with Ninja, which is very annoying (since the folder I add this way are demos, there are quite a lot of targets to build). Am I missing something or is this a feature I could add ? Best -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Wed Feb 10 12:13:57 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 10 Feb 2016 12:13:57 -0500 Subject: [cmake-developers] [CMake 0015968]: Ninja generator is non-deterministic Message-ID: <05bae8227341841e3d5c76c9c091bdeb@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15968 ====================================================================== Reported By: Chris Assigned To: ====================================================================== Project: CMake Issue ID: 15968 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2016-02-10 12:13 EST Last Modified: 2016-02-10 12:13 EST ====================================================================== Summary: Ninja generator is non-deterministic Description: CMake's Ninja generator is non-deterministic on our project (LLVM). This is trivially reproducible by configuring llvm into a clean directory multiple times and comparing the results. This is a very real problem for our project because the nondeterminism in the generated ninja build seems to be the cause of non-determinism in our build outputs. One of the important methods of compiler testing is what we call a 3-stage build. The process is basically: (1) build clang (2) use clang from step 1 to build clang again (3) use clang from step 2 to build clang again (4) ensure clang from step 2 and clang from step 3 are binary identical Today this works using the CMake Unix Makefile generator, but not using the Ninja generator. This issue reproduces on CMake 3.4.x and CMake 3.5.0 rc1. I assume it probably goes back quite a long ways too. Steps to Reproduce: mkdir scratch cd scratch cmake -G Ninja cp build.ninja .. rm -rf cmake -G Ninja diff build.ninja ../build.ninja ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-10 12:13 Chris New Issue ====================================================================== From brad.king at kitware.com Wed Feb 10 13:47:10 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 10 Feb 2016 13:47:10 -0500 Subject: [cmake-developers] Ninja and add_subdirectory EXCLUDE_FROM_ALL In-Reply-To: References: Message-ID: <56BB85AE.8090204@kitware.com> On 02/10/2016 10:57 AM, Charles Huet wrote: > When using Unix Makefiles (or MSVC) this causes the subfolder to contain > a new Makefile, allowing me to build easily the whole subdir. > > I cannot find such a facility with Ninja The Makefile generator naturally lays makefiles out with launch points in each directory. The Xcode generator and Visual Studio generators generate projects that can be loaded in the respective IDEs for each source directory with a project() command in its CMakeLists.txt file: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGlobalXCodeGenerator.cxx;hb=v3.4.3#l407 https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGlobalVisualStudio7Generator.cxx;hb=v3.4.3#l383 They contain the relevant subsets of the build system needed for their subdirectories. Currently the Ninja generator does not have this feature. It may be possible to add but would take some investigation into how intrusive the changes would be. -Brad From brad.king at kitware.com Wed Feb 10 13:47:11 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 10 Feb 2016 13:47:11 -0500 Subject: [cmake-developers] [PATCH] FindProtobuf: prevent redundant PROTOBUF_LIBRARIES In-Reply-To: <1455096991-10548-1-git-send-email-antonioperez@by.com.es> References: <1455096991-10548-1-git-send-email-antonioperez@by.com.es> Message-ID: <56BB85AF.4060200@kitware.com> On 02/10/2016 04:36 AM, Antonio Perez Barrero wrote: > find_library(${name}_LIBRARY [snip] > + select_library_configurations(${name}) > + set(${name}_LIBRARY_DEBUG ${${name}_LIBRARY_DEBUG} PARENT_SCOPE) > + set(${name}_LIBRARY ${${name}_LIBRARY} PARENT_SCOPE) > + set(${name}_LIBRARIES ${${name}_LIBRARIES} PARENT_SCOPE) Thanks. IIRC select_library_configurations needs the two inputs to be _LIBRARY_DEBUG and _LIBRARY_RELEASE. We'll have to change the first find_library call to use _RELEASE. The whole block can be arranged in the form if(${name}_LIBRARY) set(${name}_LIBRARIES "${${name}_LIBRARY}") else() ...current block, but with _RELEASE name... endif() in order to be compatible with build scripts that expect to set just ${name}_LIBRARY in the cache. -Brad From eike at sf-mail.de Wed Feb 10 13:50:00 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 10 Feb 2016 19:50 +0100 Subject: [cmake-developers] [PATCH] FindProtobuf: prevent redundant PROTOBUF_LIBRARIES In-Reply-To: <1455096991-10548-1-git-send-email-antonioperez@by.com.es> References: <1455096991-10548-1-git-send-email-antonioperez@by.com.es> Message-ID: <1765644.rWUaK10oYK@caliban.sf-tec.de> Am Mittwoch, 10. Februar 2016, 10:36:31 schrieb Antonio Perez Barrero: > Before this change, the variable PROTOBUF_LIBRARIES might get redundant > value for debug and optimized configurations, e.g. > 'optimized;/usr/lib/libprotobuf.so;debug;/usr/lib/libprotobuf.so' > --- > Modules/FindProtobuf.cmake | 18 ++++++------------ > 1 file changed, 6 insertions(+), 12 deletions(-) > > diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake > index 2f13b09..57c6e62 100644 > --- a/Modules/FindProtobuf.cmake > +++ b/Modules/FindProtobuf.cmake > @@ -213,6 +213,8 @@ endif() > # Internal function: search for normal library as well as a debug one > # if the debug one is specified also include debug/optimized keywords > # in *_LIBRARIES variable > +include(SelectLibraryConfigurations) For modules that are part of CMake use include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake) This makes sure exactly the version of SLC the module was designed to use will be used, i.e. those shipped with the exact same version of CMake. Greetings, Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From robert.maynard at kitware.com Wed Feb 10 15:40:19 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 10 Feb 2016 15:40:19 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake 3.5.0-rc2 now ready for testing! Message-ID: I am proud to announce the second CMake 3.5 release candidate. Sources and binaries are available at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.5 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.5/release/3.5.html Some of the more significant features of CMake 3.5 are: * The precompiled Windows binary provided on "cmake.org" is now a ".msi" package instead of an installer executable. One may need to manually uninstall CMake versions lower than 3.5 before installing the new package. * The "cmake-gui(1)" learned an option to set the toolset to be used with VS IDE and Xcode generators, much like the existing "-T" option to "cmake(1)". * Find modules for Boost, FLEX, GTest, GTK2, PNG, TIFF, and XercesC now provide imported targets. * The "FindOpenMP" module learned to support Clang. * A new platform file for cross-compiling in the Cray Linux Environment to target compute nodes was added. See Cross Compiling for the Cray Linux Environment for usage details. * The "Compile Features" functionality is now aware of features supported by Clang compilers on Windows (MinGW). * Support was added for the ARM Compiler (arm.com) with compiler id "ARMCC". * When building for embedded Apple platforms like iOS CMake learned to build and install combined targets which contain both a device and a simulator build. This behavior can be enabled by setting the "IOS_INSTALL_COMBINED" target property. * The "CPackDMG" module learned new variable to specify AppleScript file run to customize appearance of "DragNDrop" installer folder, including background image setting using supplied PNG or multi- resolution TIFF file. See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and "CPACK_DMG_BACKGROUND_IMAGE" variables. Deprecated and Removed Features: * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "cmake(1)" "-E time" command now properly passes arguments with spaces or special characters through to the child process. This may break scripts that worked around the bug with their own extra quoting or escaping. CMake 3.5 Release Notes *********************** Changes made since CMake 3.4 include the following. New Features ============ GUI --- * The "cmake-gui(1)" gained options to control warnings about deprecated functionality. * The "cmake-gui(1)" learned an option to set the toolset to be used with VS IDE and Xcode generators, much like the existing "-T" option to "cmake(1)". * The "cmake-gui(1)" gained a Regular Expression Explorer which may be used to create and evaluate regular expressions in real-time. The explorer window is available via the "Tools" menu. Command-Line ------------ * The "-Wdev" and "-Wno-dev" "cmake(1)" options now also enable and suppress the deprecated warnings output by default. * The suppression of developer warnings as errors can now be controlled with the new "-Werror=dev" and "-Wno-error=dev" "cmake(1)" options. * The "cmake(1)" "-E" command-line tools "copy", "copy_if_different", "copy_directory", and "make_directory" learned to support multiple input files or directories. Commands -------- * The "cmake_parse_arguments()" command is now implemented natively. The "CMakeParseArguments" module remains as an empty placeholder for compatibility. * The "install(DIRECTORY)" command learned to support "generator expressions" in the list of directories. Variables --------- * The "CMAKE_ERROR_DEPRECATED" variable can now be set using the "-Werror=deprecated" and "-Wno-error=deprecated" "cmake(1)" options. * The "CMAKE_WARN_DEPRECATED" variable can now be set using the "-Wdeprecated" and "-Wno-deprecated" "cmake(1)" options. Properties ---------- * The "VS_GLOBAL_" target property is now implemented for VS 2010 and above. Previously it worked only in VS 2008 and below. Modules ------- * The "ExternalProject" module learned a new "GIT_REMOTE_NAME" option to control the "git clone --origin" value. * The "FindBoost" module now provides imported targets such as "Boost::boost" and "Boost::filesystem". * The "FindFLEX" module "FLEX_TARGET" macro learned a new "DEFINES_FILE" option to specify a custom output header to be generated. * The "FindGTest" module now provides imported targets. * The "FindGTK2" module, when "GTK2_USE_IMPORTED_TARGETS" is enabled, now sets "GTK2_LIBRARIES" to contain the list of imported targets instead of the paths to the libraries. Moreover it now sets a new "GTK2_TARGETS" variable containing all the targets imported. * The "FindOpenMP" module learned to support Clang. * The "FindOpenSSL" module gained a new "OPENSSL_MSVC_STATIC_RT" option to search for libraries using the MSVC static runtime. * The "FindPNG" module now provides imported targets. * The "FindTIFF" module now provides imported targets. * A "FindXalanC" module was introduced to find the Apache Xalan-C++ XSL transform processing library. * The "FindXercesC" module now provides imported targets. Platforms --------- * Support was added for the ARM Compiler (arm.com) with compiler id "ARMCC". * A new platform file for cross-compiling in the Cray Linux Environment to target compute nodes was added. See Cross Compiling for the Cray Linux Environment for usage details. * The "Compile Features" functionality is now aware of features supported by Clang compilers on Windows (MinGW). * When building for embedded Apple platforms like iOS CMake learned to build and install combined targets which contain both a device and a simulator build. This behavior can be enabled by setting the "IOS_INSTALL_COMBINED" target property. CPack ----- * The "CPackDMG" module learned new variable to specify AppleScript file run to customize appearance of "DragNDrop" installer folder, including background image setting using supplied PNG or multi- resolution TIFF file. See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and "CPACK_DMG_BACKGROUND_IMAGE" variables. * The "CPackDeb" module learned to set the optional config file "Source" field using a monolithic or per-component variable. See "CPACK_DEBIAN_PACKAGE_SOURCE". * The "CPackDeb" module learned to set Package, Section and Priority control fields per-component. See variables "CPACK_DEBIAN__PACKAGE_SECTION" and "CPACK_DEBIAN__PACKAGE_PRIORITY". * The "CPack DragNDrop generator" learned to add multi-lingual SLAs to a DMG which is presented to the user when they try to mount the DMG. See the "CPACK_DMG_SLA_LANGUAGES" and "CPACK_DMG_SLA_DIR" variables for details. * The "CPackNSIS" module learned new variables to add bitmaps to the installer. See the "CPACK_NSIS_MUI_WELCOMEFINISHPAGE_BITMAP" and "CPACK_NSIS_MUI_UNWELCOMEFINISHPAGE_BITMAP" variables. * The "CPackRPM" module learned to set Name and Group control fields per-component. See "CPACK_RPM__PACKAGE_NAME" and "CPACK_RPM__PACKAGE_GROUP". Other ----- * Warnings about deprecated functionality are now enabled by default. They may be suppressed with "-Wno-deprecated" or by setting the "CMAKE_WARN_DEPRECATED" variable to false. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "cmake(1)" "-E time" command now properly passes arguments with spaces or special characters through to the child process. This may break scripts that worked around the bug with their own extra quoting or escaping. Other Changes ============= * The "Visual Studio 14 2015" generator learned to map the "/debug:fastlink" linker flag to the ".vcxproj" file property. * The "FindGTK2" module now configures the "GTK2::sigc++" imported target to enable c++11 on its dependents when using sigc++ 2.5.1 or higher. * The precompiled Windows binary provided on "cmake.org" is now a ".msi" package instead of an installer executable. One may need to manually uninstall CMake versions lower than 3.5 before installing the new package. ---------------------------------------------------------------------------- Changes made since CMake 3.5.0-rc1: Brad King (10): Fix dependency scanning configuration in subdirectories Tests: Use newer policy settings in RunCMake.install test install(EXPORT): Fix crash on target in another directory ExternalProject: Be compatible with projects setting CMAKE_CFG_INTDIR Install ccmake.1 and cmake-gui.1 conditionally with their tools (#15957) Tests: Avoid OS X 10.5 limitation warning in RunCMake.install test Fix internal target lookup performance regression Improve internal generator target structure lookup cmCurl: Fix compilation with system curl versions prior to 7.21.5 CMake 3.5.0-rc2 Horst Kronstorfer (1): Help: Fix command specification for cmake_minimum_required Nils Gladitz (1): CMake: Prevent WiX installations over existing NSIS installations Orion Poplawski (1): Tests: Extend ctest_submit host lookup failure matching (#15958) Paul Wilkinson (1): Help: Fix mistake in cmake-buildsystem(7) example From robert.maynard at kitware.com Wed Feb 10 15:44:24 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 10 Feb 2016 15:44:24 -0500 Subject: [cmake-developers] Changes for v3.5.0 In-Reply-To: <56BB464F.7090005@kitware.com> References: <56BA34F1.7020504@kitware.com> <56BA433D.5080808@kitware.com> <56BB464F.7090005@kitware.com> Message-ID: CMake 3.5.0-rc2 has been released and includes these performance fixes. On Wed, Feb 10, 2016 at 9:16 AM, Brad King wrote: > On 02/10/2016 05:34 AM, Bartosz Kosiorek wrote: >> I have great news. >> With Nighly Build 3.5.20160208 the regression was gone > > Great, thanks for testing this! > > -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 From irwin at beluga.phys.uvic.ca Wed Feb 10 17:02:50 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 10 Feb 2016 14:02:50 -0800 (PST) Subject: [cmake-developers] Changes for v3.5.0 In-Reply-To: <56BB464F.7090005@kitware.com> References: <56BA34F1.7020504@kitware.com> <56BA433D.5080808@kitware.com> <56BB464F.7090005@kitware.com> Message-ID: On 2016-02-10 09:16-0500 Brad King wrote: > On 02/10/2016 05:34 AM, Bartosz Kosiorek wrote: >> I have great news. >> With Nighly Build 3.5.20160208 the regression was gone > > Great, thanks for testing this! I got curious about how this affected the timing of configuration of the PLplot build so here are my results for that where in all cases I am taking timing numbers from the second run of cmake (starting with an empty build tree each time cmake is invoked) to account for all speed gains from ccache and memory caching. All CMake versions used below were built by me on Linux (Debian jessie) with the bootstrap method using export CFLAGS='-O3' export CXXFLAGS='-O3'. So this speed test between the various CMake versions should be a reasonably level playing field. Time required to configure PLplot with various versions of cmake: 3.3.2: real 0m15.678s user 0m11.472s sys 0m2.432s 3.4.3: real 0m16.351s user 0m11.988s sys 0m2.468s 3.5.0-rc2 (that tagged version from the git release branch this morning) real 0m16.167s user 0m11.812s sys 0m2.568s The 0.7 second increase in real time between 3.3.2 and 3.4.3 likely indicates a small (~4 per cent) but acceptable systematic regression in efficiency between those two versions. However, the 0.2 second decrease in real time between 3.4.3 and 3.5.0-rc2 is likely close to the measurement errors. Nevertheless, that result is consistent with Bartosz's result that the original large regression in efficiency he found for 3.5.0-rc1 compared to prior versions has now been completely solved for 3.5.0-rc2. My thanks to Bartosz for finding this efficiency regression for 3.5.0-rc1, and my thanks to Brad for fixing it for 3.5.0-rc2. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From tobias.hunger at gmail.com Wed Feb 10 17:04:41 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Wed, 10 Feb 2016 23:04:41 +0100 Subject: [cmake-developers] CMake Daemon In-Reply-To: References: Message-ID: Hi Stephen, stupid question: How do I run the server-mode autotests? I just implemented a unified way to do progress reporting and want to make sure that did not break too much. Running Tests/Server/daemon-test.py manually works, but how do I run all those tests configured in the CMakeLists.txt? The builddirectory does not contain a Tests/Server directory to run make test in:-/ Best Regards, Tobias On Wed, Feb 10, 2016 at 12:44 AM, Stephen Kelly wrote: > Stephen Kelly wrote: > >> Tam?s Ken?z wrote: >> >>> That's great and really does open a new world for IDEs! >> >> Thanks! Let's see if the interest grows. >> >> I've just pushed the daemon code here: >> >> https://github.com/steveire/cmake/tree/cmake-daemon > > Tobias made a pull request there. Rather than review it there, I will review > it here for visibility. > > https://github.com/steveire/CMake/pull/2 > > The branch is quite it hard to review, or even to see the particular > changes, due to large commits and diff noise. If the Daemon reaches a level > of completeness that it could be upstreamed (See > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15740 > > ) then these commits (including all of my commits on the branch) would have > to be rewritten, split, made reviewable etc making heavy use of `rebase -i`. > > In a way, we don't have to do that now, but I'm also not very enthusiastic > about making the `cmake-daemon` branch commits unreadable. I would add your > commits to the branch if they we split and in the appropriate place (eg, > with the cmServerProtocol0_1 change early in the cmake-daemon branch). > > The changes in your branch are good and useful to more than just QtCreator. > > Things that I like in your branch: > > * Explicit cmServerRequest and cmServerResponse APIs, which enforce the type > and cookie consistency. > * Returning cmServerResponse objects from the cmServerProtocol instead of > invoking the server from the cmServerProtocol. > * A way to version the protocol in a future-proof way with C++ classes. > * Implementation of daemon and protocol error messaging infrastructure. > (Reporting errors from cmake code requires other refactoring: > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607/focus=15636) > > So I think that is progress! > > Thanks, > > Steve. > > > > -- > > 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 From steveire at gmail.com Wed Feb 10 18:02:24 2016 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 11 Feb 2016 00:02:24 +0100 Subject: [cmake-developers] CMake Daemon References: Message-ID: Tobias Hunger wrote: > Hi Stephen, > > stupid question: How do I run the server-mode autotests? > > I just implemented a unified way to do progress reporting and want to > make sure that did not break too much. Running > Tests/Server/daemon-test.py manually works, but how do I run all those > tests configured in the CMakeLists.txt? The builddirectory does not > contain a Tests/Server directory to run make test in:-/ After building cmake, run ctest -R Server in the build directory Alternatively, cd to Tests/Server in the source directory and mkdir build cd build cmake .. The tests are run at cmake time. Thanks, Steve. From ewmailing at gmail.com Wed Feb 10 18:25:31 2016 From: ewmailing at gmail.com (Eric Wing) Date: Wed, 10 Feb 2016 15:25:31 -0800 Subject: [cmake-developers] Drop support for older Xcode versions? In-Reply-To: <56B9FC7D.9080705@davyandbeth.com> References: <56B5CFA3.5090107@googlemail.com> <20160208152121.1630645796@mail.rogue-research.com> <56B8B4C5.9090806@kitware.com> <20160208154830.1125542189@mail.rogue-research.com> <56B9FC7D.9080705@davyandbeth.com> Message-ID: On 2/9/16, Davy Durham wrote: > I'll say that in my line of work, we still have to support OS X 10.6 > (just dropped 10.5 support) .. And we're doing this at Apple's own > request/demand! It's not fun. I've had to hack tools around to get > somewhat newer tool chains to continue to work, but it's been /great/ > that cmake hasn't been an obstacle in this endeavour. Supporting 10.6...this is what I'm referring to. In Apple's world, this means you are on 10.11 using Xcode 7.3 and setting the Deployment target to 10.6. I know for hard cases, it is never that simple, but do you really need to be on 10.6 to develop for 10.6? A corollary issue is that when you buy a new Mac, it usually can't boot an operating system older than the one it shipped with. Backwards compatibility is hard. This suggests two alternative paths: - CMake archives older versions. You can always download the last official supported version for CMake that runs on 10.6. - We split the Xcode generators into per-version buckets. (Xcode 3, 4, 5, 6, 7). Work freezes on older generators after awhile, but hopefully won't break. (Yeah, I know core CMake changes can get dicey, which is why I didn't really want to suggest this.) Anyway food for thought. From tobias.hunger at gmail.com Wed Feb 10 18:26:00 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Thu, 11 Feb 2016 00:26:00 +0100 Subject: [cmake-developers] CMake Daemon In-Reply-To: References: Message-ID: Hi Stephen, thanks for that information! Now I can finally fix the tests again (and add a couple for the error cases my branch handles;-). I did play some more and implemented support for consistent progress reporting and multiple protocol versions now in my branch at https://github.com/hunger/CMake/tree/cmake-daemon This unfortunately resulted in the interaction with the daemon changing a bit:-( Upon start the daemon now sends: {"supportedProtocolVersions":[{"major":0,"minor":1}],"type":"hello"} You need to reply with something along the lines off: {"type":"handshake", "protocolVersion": { "major": 0 }} Daemon will respond with: {"cookie":"","inResponseTo":"handshake","type":"reply"} and listen for commands. "version" will work at this point, but you need to do: {"type":"initialize", "buildDirectory":"/some/build/dir"} to trigger the actual parsing of data. Afterwards all the usual commands are available as before. I did not yet update the tests with this change, so I did not create a MR yet. I also want to do some small (but intrusive) changes to how cmServerResponse objects are created. Best Regards, Tobias From mantis at public.kitware.com Thu Feb 11 02:58:31 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 11 Feb 2016 02:58:31 -0500 Subject: [cmake-developers] [CMake 0015969]: String property broken in cmake 3.5.0-rc2 with XCode Message-ID: <5f88abc763d57d277ce914c88e3260d8@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15969 ====================================================================== Reported By: A. Klitzing Assigned To: ====================================================================== Project: CMake Issue ID: 15969 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-11 02:58 EST Last Modified: 2016-02-11 02:58 EST ====================================================================== Summary: String property broken in cmake 3.5.0-rc2 with XCode Description: We build our application for iOS with cmake and iOS toolchain file [1]. We pass some strings with "-D" property to the compiler. In cmake 3.5.0rc2 (rc1 not tested) the build will fail as the quotes of the strings are broken. Same code works with cmake 3.4.1. [1] https://github.com/cristeab/ios-cmake Steps to Reproduce: 1. cmake ../source -DCMAKE_BUILD_TYPE=release -DCMAKE_PREFIX_PATH=/[...]/dist -DCMAKE_TOOLCHAIN_FILE=../source/cmake/iOS.toolchain.cmake -GXcode 2. xcodebuild -target install -configuration Release 3. Compiler failed Additional Information: Snippets of compiler cmdline: See at -DVERSION= 3.5.0-rc2: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c++ -arch armv7 [.....] -std=c++11 -ObjC++ -fPIC -DVERSION=\\1.6.3+5-default-53920e4f2686\\ -MMD -MT dependencies [...] -c /.../src/main.cpp -o /.../build/src/XYZ.build/Release-iphoneos/XYZ.build/Objects-normal/armv7/main.o 3.4.1: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c++ -arch armv7 [.....] -std=c++11 -fPIC -DVERSION=\"1.6.3+5-default-53920e4f2686\" -MMD -MT dependencies -c /.../src/main.cpp -o /.../build/src/XYZ.build/Release-iphoneos/XYZ.build/Objects-normal/armv7/main.o We use a little wrapper for quoted strings as XCode, windres and other compilers works different here. FUNCTION(GET_QUOTED_STRING _dest _str _filename) IF(CMAKE_GENERATOR STREQUAL Xcode) SET(tmp_var \\\\"${_str}\\\\") ELSEIF(NOT ${arg} MATCHES ".rc$") SET(tmp_var \\"${_str}\\") ELSE() SET(tmp_var ${_str}) ENDIF() SET(${_dest} ${tmp_var} PARENT_SCOPE) ENDFUNCTION() FUNCTION(ADD_STRING_DEFINITION _str _def) IF(ARGN) FOREACH(arg ${ARGN}) IF (${arg} MATCHES "^AppTargetName") SET(ARG_TYPE TARGET) ELSE() SET(ARG_TYPE SOURCE) ENDIF() IF(NOT "${_str}" STREQUAL "") GET_QUOTED_STRING(tmp_var ${_str} ${arg}) SET(tmp_var =${tmp_var}) ENDIF() SET_PROPERTY(${ARG_TYPE} ${arg} APPEND_STRING PROPERTY COMPILE_FLAGS " -D${_def}${tmp_var}") ENDFOREACH() ELSE() IF(NOT "${_str}" STREQUAL "") GET_QUOTED_STRING(tmp_var ${_str} ${arg}) SET(tmp_var =${tmp_var}) ENDIF() ADD_DEFINITIONS(-D${_def}${tmp_var}) ENDIF() ENDFUNCTION() FUNCTION(ADD_DEFINITION _def) ADD_STRING_DEFINITION("" ${_def} ${ARGN}) ENDFUNCTION() ########################################## PROJECT(XYZ VERSION 1.6.3 CXX) SET(VERSION_MERCURIAL ${PROJECT_VERSION}+5-default-53920e4f2686) ADD_STRING_DEFINITION(${VERSION_MERCURIAL} "VERSION" main.cpp) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-11 02:58 A. Klitzing New Issue ====================================================================== From apbarrero at gmail.com Thu Feb 11 03:24:27 2016 From: apbarrero at gmail.com (Antonio Perez Barrero) Date: Thu, 11 Feb 2016 09:24:27 +0100 Subject: [cmake-developers] [PATCH] FindProtobuf: prevent redundant PROTOBUF_LIBRARIES Message-ID: <1455179067-6489-1-git-send-email-antonioperez@by.com.es> Before this change, the variable PROTOBUF_LIBRARIES might get redundant value for debug and optimized configurations, e.g. 'optimized;/usr/lib/libprotobuf.so;debug;/usr/lib/libprotobuf.so' --- Modules/FindProtobuf.cmake | 39 +++++++++++++++++++-------------------- 1 file changed, 19 insertions(+), 20 deletions(-) diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake index 2f13b09..02aca1c 100644 --- a/Modules/FindProtobuf.cmake +++ b/Modules/FindProtobuf.cmake @@ -213,28 +213,27 @@ endif() # Internal function: search for normal library as well as a debug one # if the debug one is specified also include debug/optimized keywords # in *_LIBRARIES variable +include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations) + function(_protobuf_find_libraries name filename) - find_library(${name}_LIBRARY - NAMES ${filename} - PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Release) - mark_as_advanced(${name}_LIBRARY) - - find_library(${name}_LIBRARY_DEBUG - NAMES ${filename} - PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug) - mark_as_advanced(${name}_LIBRARY_DEBUG) - - if(NOT ${name}_LIBRARY_DEBUG) - # There is no debug library - set(${name}_LIBRARY_DEBUG ${${name}_LIBRARY} PARENT_SCOPE) - set(${name}_LIBRARIES ${${name}_LIBRARY} PARENT_SCOPE) + if(${name}_LIBRARY) + set(${name}_LIBRARIES "${${name}_LIBRARY}" PARENT_SCOPE) else() - # There IS a debug library - set(${name}_LIBRARIES - optimized ${${name}_LIBRARY} - debug ${${name}_LIBRARY_DEBUG} - PARENT_SCOPE - ) + find_library(${name}_LIBRARY_RELEASE + NAMES ${filename} + PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Release) + mark_as_advanced(${name}_LIBRARY_RELEASE) + + find_library(${name}_LIBRARY_DEBUG + NAMES ${filename} + PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug) + mark_as_advanced(${name}_LIBRARY_DEBUG) + + select_library_configurations(${name}) + set(${name}_LIBRARY_RELEASE ${${name}_LIBRARY_RELEASE} PARENT_SCOPE) + set(${name}_LIBRARY_DEBUG ${${name}_LIBRARY_DEBUG} PARENT_SCOPE) + set(${name}_LIBRARY ${${name}_LIBRARY} PARENT_SCOPE) + set(${name}_LIBRARIES ${${name}_LIBRARIES} PARENT_SCOPE) endif() endfunction() -- 1.9.1 From christian.askeland at gmail.com Thu Feb 11 08:15:06 2016 From: christian.askeland at gmail.com (Christian Askeland) Date: Thu, 11 Feb 2016 14:15:06 +0100 Subject: [cmake-developers] [PATCH] Bug fix: Dylibs inside .framework folders fails in BundleUtilities.cmake. In-Reply-To: <56B8B4FB.2040509@kitware.com> References: <56B4BE1B.5050200@kitware.com> <56B8B4FB.2040509@kitware.com> Message-ID: The line is now tested in my build system, on three OS'es. Everything looks OK. New patch follows: The specific cause is when e.g. /Library/Frameworks/GStreamer.framework/Versions/1.0/lib/libgio-2.0.0.dylib is detected by fixup_bundle. BundleUtilities.cmake/set_bundle_key_values() interprets this as a framework, thus doing a string replace that creates an embedded_item that is equal to the original path, i.e. it is not embedded. The fix is to reuse the framework detection method found in GetPrerequisite.cmake/gp_item_default_embedded_path(), i.e. first checking for .dylib --- Modules/BundleUtilities.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake index 45dda40..73ff0af 100644 --- a/Modules/BundleUtilities.cmake +++ b/Modules/BundleUtilities.cmake @@ -479,7 +479,7 @@ function(set_bundle_key_values keys_var context item exepath dirs copyflag) get_item_rpaths("${resolved_item}" item_rpaths) - if(item MATCHES "[^/]+\\.framework/") + if((item NOT MATCHES "\\.dylib$") AND (item MATCHES "[^/]+\\.framework/")) # For frameworks, construct the name under the embedded path from the # opening "${item_name}.framework/" to the closing "/${item_name}": # -- 2.5.4 (Apple Git-61) On Mon, Feb 8, 2016 at 4:32 PM, Brad King wrote: > On 02/07/2016 11:25 AM, Christian Askeland wrote: > > We could reuse the check from gp_item_default_embedded_path(), instead of > > looking at the result from that function: > > > > if((item NOT MATCHES "\\.dylib$") AND (item MATCHES > "[^/]+\\.framework/")) > > > > I haven't tested the line above, but can do so tomorrow and post a new > patch, > > if it looks reasonable. > > Yes, I think that looks good. > > Thanks, > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Feb 11 09:00:55 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Feb 2016 09:00:55 -0500 Subject: [cmake-developers] [PATCH] Bug fix: Dylibs inside .framework folders fails in BundleUtilities.cmake. In-Reply-To: References: <56B4BE1B.5050200@kitware.com> <56B8B4FB.2040509@kitware.com> Message-ID: <56BC9417.2010700@kitware.com> On 02/11/2016 08:15 AM, Christian Askeland wrote: > New patch follows: Thanks, applied: BundleUtilities: Fix treatment of .dylib inside .framework folders https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e422f738 -Brad From brad.king at kitware.com Thu Feb 11 09:00:59 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Feb 2016 09:00:59 -0500 Subject: [cmake-developers] [PATCH] FindProtobuf: prevent redundant PROTOBUF_LIBRARIES In-Reply-To: <1455179067-6489-1-git-send-email-antonioperez@by.com.es> References: <1455179067-6489-1-git-send-email-antonioperez@by.com.es> Message-ID: <56BC941B.5060406@kitware.com> On 02/11/2016 03:24 AM, Antonio Perez Barrero wrote: > Before this change, the variable PROTOBUF_LIBRARIES might get redundant > value for debug and optimized configurations, e.g. > 'optimized;/usr/lib/libprotobuf.so;debug;/usr/lib/libprotobuf.so' Thanks, applied with minor updates: FindProtobuf: prevent redundant PROTOBUF_LIBRARIES https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=51b0501a -Brad From roman.wueger at gmx.at Thu Feb 11 09:48:18 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Thu, 11 Feb 2016 15:48:18 +0100 Subject: [cmake-developers] CMake Windows 10 Store App Message-ID: <4370407C-B9AA-4D44-A773-002A92CE7525@gmx.at> Hello, I use CMAKE_SYSTEM_NAME:STRING=WindowsStore and CMAKE_SYSTEM_VERSION=10.0 to build an universal app. However, does CMake also support *.appxupload and such bundles? And if so, how? Thanks in advance Best regards Roman From tobias.hunger at gmail.com Thu Feb 11 12:01:36 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Thu, 11 Feb 2016 18:01:36 +0100 Subject: [cmake-developers] [PATCH]: Fix compiler warnings (clang from trunk) Message-ID: Just a small patch to fix a couple of compiler warnings that drove me crazy. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-cmListFileCache-Fix-warnings-during-build.patch Type: text/x-patch Size: 736 bytes Desc: not available URL: From brad.king at kitware.com Thu Feb 11 13:39:53 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Feb 2016 13:39:53 -0500 Subject: [cmake-developers] [PATCH]: Fix compiler warnings (clang from trunk) In-Reply-To: References: Message-ID: <56BCD579.3010902@kitware.com> On 02/11/2016 12:01 PM, Tobias Hunger wrote: > Just a small patch to fix a couple of compiler warnings that drove me crazy. Thanks, applied: cmListFileCache: Fix warning about inconsistent use of class/struct https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e1ea1df0 -Brad From mantis at public.kitware.com Thu Feb 11 13:44:48 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 11 Feb 2016 13:44:48 -0500 Subject: [cmake-developers] [CMake 0015970]: CMake changes order of include directories when a directory is specified both as a SYSTEM and non-SYSTEM include Message-ID: <9c265d03375f41c3643f98742f305947@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15970 ====================================================================== Reported By: jbohren Assigned To: ====================================================================== Project: CMake Issue ID: 15970 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-11 13:44 EST Last Modified: 2016-02-11 13:44 EST ====================================================================== Summary: CMake changes order of include directories when a directory is specified both as a SYSTEM and non-SYSTEM include Description: I ran into a problem recently where a package I was building set a SYSTEM include directory which was already a non-SYSTEM include directory imported from a dependency. When this happened, CMake dropped the non-SYSTEM directory in favor of the SYSTEM one, causing my build to fail. According to GCC [1], it gives precedence to non-SYSTEM include directories, and specifying both for the same path produces a warning. [1] https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html > All directories named by -isystem are searched after all directories named by -I, no matter what their order was on the command line. If the same directory is named by both -I and -isystem, the -I option is ignored. GCC provides an informative message when this occurs if -v is used. With CMake, if both are specified, it drops the non-SYSTEM include and fails silently. For example, when building this project with any recent version of CMake on Linux, the build command is: ```bash /usr/bin/c++ -isystem /path/to/overlay/devel/include -I/opt/ros/indigo/include -o CMakeFiles/foo.dir/foo.cpp.o -c /home/jbohren/scratch/isystem/foo.cpp ``` But with the three `incude_directory` options given in `CMakeLists.txt`, I would expect it to read: ```bash /usr/bin/c++ -I/path/to/overlay/devel/include -I/opt/ros/indigo/include -isystem /path/to/overlay/devel/include -o CMakeFiles/foo.dir/foo.cpp.o -c /home/jbohren/scratch/isystem/foo.cpp ``` Even the following would maintain the order of the search paths, since the non-SYSTEM directories are all scanned before the SYSTEM ones: ```bash /usr/bin/c++ -I/path/to/overlay/devel/include -I/opt/ros/indigo/include -o CMakeFiles/foo.dir/foo.cpp.o -c /home/jbohren/scratch/isystem/foo.cpp ``` Steps to Reproduce: Build this trivial CMake project to observe the effect: https://github.com/jbohren/isystem ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-11 13:44 jbohren New Issue ====================================================================== From mantis at public.kitware.com Thu Feb 11 14:52:37 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 11 Feb 2016 14:52:37 -0500 Subject: [cmake-developers] [CMake 0015971]: CMake alias resolution appears to be inconsistently applied Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15971 ====================================================================== Reported By: Marcus D. Hanwell Assigned To: Robert Maynard ====================================================================== Project: CMake Issue ID: 15971 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 2016-02-11 14:52 EST Last Modified: 2016-02-11 14:52 EST ====================================================================== Summary: CMake alias resolution appears to be inconsistently applied Description: The Tomviz project extends ParaView, and uses a number of imported targets. Some of these come from VTK, others come from ParaView. When migrating to Qt 5 we hit a strange bug where the Qt 5 interface library aliases were not getting expanded unless we explicitly added them to the target_link_libraries line. Printing them out all the libraries were found, but the link line had -lQt5::Help etc. It looks like the Qt5::Widgets alias was the only one resolved. If I switch the order of finding ParaView and finding Qt5 around everything worked. If I find ParaView first, then Qt 5 it fails at linking, unless I add all of the libraries to the target_link_libraries, in which case it resolved them and the link step succeeded. This seems very inconsistent to me, perhaps it is intended for for reason due to the order in which you resolve aliases? It took something that was fairly resilient to call order previously and made it more brittle in our project. Additional Information: https://github.com/OpenChemistry/tomviz/commit/525336b3e94170ec2e2c463894de034d539898cc shows the commit I am hoping will make this consistent everywhere. If aliases make this strict ordering necessary that was not evident to me. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-11 14:52 Marcus D. HanwellNew Issue 2016-02-11 14:52 Marcus D. HanwellStatus new => assigned 2016-02-11 14:52 Marcus D. HanwellAssigned To => Robert Maynard ====================================================================== From taylor at braun-jones.org Thu Feb 11 15:35:14 2016 From: taylor at braun-jones.org (Taylor Braun-Jones) Date: Thu, 11 Feb 2016 15:35:14 -0500 Subject: [cmake-developers] 15954: Ninja generated superbuilds do not reinstall dependent projects Message-ID: I'm curious about bug 15954[1]. I'm having the same issue and I'd expect that many others would be running to the issue too since the Ninja generator and the ExternalProjects module have become quite popular. Could I get confirmation that it's a real bug and a quick pointer on where to look to fix it? Thanks, Taylor [1] https://cmake.org/Bug/view.php?id=15954 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Feb 11 15:44:41 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Feb 2016 15:44:41 -0500 Subject: [cmake-developers] 15954: Ninja generated superbuilds do not reinstall dependent projects In-Reply-To: References: Message-ID: <56BCF2B9.6080601@kitware.com> On 02/11/2016 03:35 PM, Taylor Braun-Jones wrote: > I'm curious about bug 15954[1]. I'm having the same issue and I'd expect > that many others would be running to the issue too since the Ninja > generator and the ExternalProjects module have become quite popular. > Could I get confirmation that it's a real bug and a quick pointer on > where to look to fix it? > > [1] https://cmake.org/Bug/view.php?id=15954 Actually I think that may have been fixed by: Ninja: Always re-run custom commands that have symbolic dependencies https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3477b26f which is in 3.5.0-rc2. Please try that version to check. -Brad From Gilles.Khouzam at microsoft.com Thu Feb 11 19:53:09 2016 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Fri, 12 Feb 2016 00:53:09 +0000 Subject: [cmake-developers] CMake Windows 10 Store App In-Reply-To: <4370407C-B9AA-4D44-A773-002A92CE7525@gmx.at> References: <4370407C-B9AA-4D44-A773-002A92CE7525@gmx.at> Message-ID: Hi Roman, The solution produced by CMake will be able to produce the appxupload bundle through Visual Studio. If you select your app project, in the build->Store menu you can create the app bundles. Are you looking to automate that? -----Original Message----- From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Roman W?ger Sent: Thursday, February 11, 2016 06:48 To: CMake Developer MailingList Subject: [cmake-developers] CMake Windows 10 Store App Hello, I use CMAKE_SYSTEM_NAME:STRING=WindowsStore and CMAKE_SYSTEM_VERSION=10.0 to build an universal app. However, does CMake also support *.appxupload and such bundles? And if so, how? Thanks in advance Best regards Roman -- Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=01%7c01%7cgilles.khouzam%40microsoft.com%7c3416bedca35349e6977308d332f26dce%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=FXx2mNGG3j9z%2bIk5kJQlm78idyf8obOU7EPpJkSsIhE%3d Please keep messages on-topic and check the CMake FAQ at: https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.cmake.org%2fWiki%2fCMake_FAQ&data=01%7c01%7cgilles.khouzam%40microsoft.com%7c3416bedca35349e6977308d332f26dce%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=FQaCHxP1kLgqbwI19FaYOh%2bHRt5gvYK8kFPPQh2shGg%3d Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcmake.org%2fcmake%2fhelp%2fsupport.html&data=01%7c01%7cgilles.khouzam%40microsoft.com%7c3416bedca35349e6977308d332f26dce%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=We1QJxq9SOTpxQ7lw0toN7hshEn3LEHjtZe9L%2bJL3jk%3d CMake Consulting: https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcmake.org%2fcmake%2fhelp%2fconsulting.html&data=01%7c01%7cgilles.khouzam%40microsoft.com%7c3416bedca35349e6977308d332f26dce%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=wzZUA0UiSCU0t8qxlJ2E35urkr3j7SqE5Z8C6%2bvQvN4%3d CMake Training Courses: https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcmake.org%2fcmake%2fhelp%2ftraining.html&data=01%7c01%7cgilles.khouzam%40microsoft.com%7c3416bedca35349e6977308d332f26dce%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=mlFgqO6k%2bcuKIHYUJ4ntzEYZNkNu2T1vN0W5PbEPPBQ%3d Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.kitware.com%2fopensource%2fopensource.html&data=01%7c01%7cgilles.khouzam%40microsoft.com%7c3416bedca35349e6977308d332f26dce%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Wrj57Y7RjmaLn7UnNkQp0aMqMOyDdXry%2bRl5VcC1GHk%3d Follow this link to subscribe/unsubscribe: https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fpublic.kitware.com%2fmailman%2flistinfo%2fcmake-developers&data=01%7c01%7cgilles.khouzam%40microsoft.com%7c3416bedca35349e6977308d332f26dce%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=q8Z56SvLk7vRlXZBm%2f%2fwHfpUQLY72nSMBWjahttOqjU%3d From apbarrero at gmail.com Fri Feb 12 02:23:44 2016 From: apbarrero at gmail.com (Antonio Perez Barrero) Date: Fri, 12 Feb 2016 08:23:44 +0100 Subject: [cmake-developers] [PATCH] FindProtobuf: check version Message-ID: <1455261824-22482-1-git-send-email-antonioperez@by.com.es> Check found libraries version to match user required version. Protobuf compiler executable version is checked to be aligned with found libraries, raising a warning message otherwise. --- Modules/FindProtobuf.cmake | 59 +++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 56 insertions(+), 3 deletions(-) diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake index 02aca1c..b3fcd23 100644 --- a/Modules/FindProtobuf.cmake +++ b/Modules/FindProtobuf.cmake @@ -15,6 +15,8 @@ # ``PROTOBUF_IMPORT_DIRS`` # List of additional directories to be searched for # imported .proto files. +# ``PROTOBUF_DEBUG`` +# Show debug messages. # # Defines the following variables: # @@ -302,10 +304,61 @@ find_program(PROTOBUF_PROTOC_EXECUTABLE ) mark_as_advanced(PROTOBUF_PROTOC_EXECUTABLE) +if(PROTOBUF_DEBUG) + message(STATUS "[ ${CMAKE_CURRENT_LIST_FILE}:${CMAKE_CURRENT_LIST_LINE} ] " + "requested version of Google Protobuf is ${Protobuf_FIND_VERSION}") +endif() + +if(PROTOBUF_INCLUDE_DIR) + set(_PROTOBUF_COMMON_HEADER ${PROTOBUF_INCLUDE_DIR}/google/protobuf/stubs/common.h) + + if(PROTOBUF_DEBUG) + message(STATUS "[ ${CMAKE_CURRENT_LIST_FILE}:${CMAKE_CURRENT_LIST_LINE} ] " + "location of common.h: ${_PROTOBUF_COMMON_HEADER}") + endif() + + set(PROTOBUF_VERSION "") + set(PROTOBUF_LIB_VERSION "") + file(STRINGS ${_PROTOBUF_COMMON_HEADER} _PROTOBUF_COMMON_H_CONTENTS REGEX "#define[ \t]+GOOGLE_PROTOBUF_VERSION[ \t]+") + if(_PROTOBUF_COMMON_H_CONTENTS MATCHES "#define[ \t]+GOOGLE_PROTOBUF_VERSION[ \t]+([0-9]+)") + set(PROTOBUF_LIB_VERSION "${CMAKE_MATCH_1}") + endif() + unset(_PROTOBUF_COMMON_H_CONTENTS) + + math(EXPR _PROTOBUF_MAJOR_VERSION "${PROTOBUF_LIB_VERSION} / 1000000") + math(EXPR _PROTOBUF_MINOR_VERSION "${PROTOBUF_LIB_VERSION} / 1000 % 1000") + math(EXPR _PROTOBUF_SUBMINOR_VERSION "${PROTOBUF_LIB_VERSION} % 1000") + set(PROTOBUF_VERSION "${_PROTOBUF_MAJOR_VERSION}.${_PROTOBUF_MINOR_VERSION}.${_PROTOBUF_SUBMINOR_VERSION}") + + if(PROTOBUF_DEBUG) + message(STATUS "[ ${CMAKE_CURRENT_LIST_FILE}:${CMAKE_CURRENT_LIST_LINE} ] " + "${_PROTOBUF_COMMON_HEADER} reveals protobuf ${PROTOBUF_VERSION}") + endif() -include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) -FIND_PACKAGE_HANDLE_STANDARD_ARGS(Protobuf DEFAULT_MSG - PROTOBUF_LIBRARY PROTOBUF_INCLUDE_DIR) + # Check Protobuf compiler version to be aligned with libraries version + execute_process(COMMAND ${PROTOBUF_PROTOC_EXECUTABLE} --version + OUTPUT_VARIABLE _PROTOBUF_PROTOC_EXECUTABLE_VERSION) + + if("${_PROTOBUF_PROTOC_EXECUTABLE_VERSION}" MATCHES "libprotoc ([0-9\.]+)") + set(_PROTOBUF_PROTOC_EXECUTABLE_VERSION "${CMAKE_MATCH_1}") + endif() + + if(PROTOBUF_DEBUG) + message(STATUS "[ ${CMAKE_CURRENT_LIST_FILE}:${CMAKE_CURRENT_LIST_LINE} ] " + "${PROTOBUF_PROTOC_EXECUTABLE} reveals version ${_PROTOBUF_PROTOC_EXECUTABLE_VERSION}") + endif() + + if(NOT "${_PROTOBUF_PROTOC_EXECUTABLE_VERSION}" VERSION_EQUAL "${PROTOBUF_VERSION}") + message(WARNING "Protobuf compiler version ${_PROTOBUF_PROTOC_EXECUTABLE_VERSION}" + " doesn't match library version ${PROTOBUF_VERSION}") + endif() +endif() + +include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs) +FIND_PACKAGE_HANDLE_STANDARD_ARGS(Protobuf + REQUIRED_VARS PROTOBUF_LIBRARIES PROTOBUF_INCLUDE_DIR + VERSION_VAR PROTOBUF_VERSION +) if(PROTOBUF_FOUND) set(PROTOBUF_INCLUDE_DIRS ${PROTOBUF_INCLUDE_DIR}) -- 1.9.1 From Melven.Roehrig-Zoellner at dlr.de Fri Feb 12 03:24:13 2016 From: Melven.Roehrig-Zoellner at dlr.de (Melven.Roehrig-Zoellner at dlr.de) Date: Fri, 12 Feb 2016 08:24:13 +0000 Subject: [cmake-developers] [PATCH]: CodeBlocks: improve support for different compilers Message-ID: <6CCDA91481A9E4418A996AE30C2278100215FF74@DLREXMBX01.intra.dlr.de> Just a small patch for the CodeBlocks generator (compiler tag in the generated CodeBlocks project file). Regards, Melven -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CodeBlocks-improve-support-for-different-compilers.patch Type: application/octet-stream Size: 3206 bytes Desc: 0001-CodeBlocks-improve-support-for-different-compilers.patch URL: From ddomenichelli at drdanz.it Fri Feb 12 03:59:04 2016 From: ddomenichelli at drdanz.it (Daniele E. Domenichelli) Date: Fri, 12 Feb 2016 09:59:04 +0100 Subject: [cmake-developers] Possible regression in cmake_parse_arguments in CMake v3.5.0-rc2 Message-ID: <56BD9ED8.2040103@drdanz.it> >From (at least) CMake 2.8.9 to CMake 3.4, this CMakeLists.txt --- cmake_minimum_required(VERSION 2.8.9) project(bar) include(CMakeParseArguments) macro(foo) set(_options ) set(_oneValueArgs FOO) set(_multiValueArgs ) cmake_parse_arguments(_FOO1 "${_options}" "${_oneValueArgs}" "${_multiValueArgs}" "${ARGN}") cmake_parse_arguments(_FOO2 "${_options}" "${_oneValueArgs}" "${_multiValueArgs}" ${ARGN}) message("_FOO1_FOO=${_FOO1_FOO}") message("_FOO2_FOO=${_FOO2_FOO}") endmacro() foo(FOO foo) --- would produce this output: _FOO1_FOO=foo _FOO2_FOO=foo In CMake v3.5.0-rc2 the output is the following: _FOO1_FOO= _FOO2_FOO=foo This means that the last argument is no longer handled in the same way as it was before. Is this an intended change? If it is, I think this is worth a policy, since I believe it will break a lot of code... Cheers, Daniele From matthias at maennich.net Fri Feb 12 07:16:47 2016 From: matthias at maennich.net (=?UTF-8?Q?Matthias_M=C3=A4nnich?=) Date: Fri, 12 Feb 2016 13:16:47 +0100 Subject: [cmake-developers] Possible regression in cmake_parse_arguments in CMake v3.5.0-rc2 In-Reply-To: <56BD9ED8.2040103@drdanz.it> References: <56BD9ED8.2040103@drdanz.it> Message-ID: Hi, the problem becomes obvious if one does: message("_FOO1_FOO=${_FOO1_FOO}") message("_FOO1_UNPARSED_ARGUMENTS=${_FOO1_UNPARSED_ARGUMENTS}") message("_FOO2_FOO=${_FOO2_FOO}") message("_FOO2_UNPARSED_ARGUMENTS=${_FOO2_UNPARSED_ARGUMENTS}") unfortunately I assumed that the vector of args I get in ::InitialPass() is already sanitized in regards to cmake list expansion. Fortunately the fix is rather small and we will send a patch here along with a test case. Sorry for the inconvenience and best regards, Matthias 2016-02-12 9:59 GMT+01:00 Daniele E. Domenichelli : > From (at least) CMake 2.8.9 to CMake 3.4, this CMakeLists.txt > > --- > cmake_minimum_required(VERSION 2.8.9) > project(bar) > > include(CMakeParseArguments) > > macro(foo) > set(_options ) > set(_oneValueArgs FOO) > set(_multiValueArgs ) > cmake_parse_arguments(_FOO1 "${_options}" > "${_oneValueArgs}" > "${_multiValueArgs}" > "${ARGN}") > cmake_parse_arguments(_FOO2 "${_options}" > "${_oneValueArgs}" > "${_multiValueArgs}" > ${ARGN}) > > message("_FOO1_FOO=${_FOO1_FOO}") > message("_FOO2_FOO=${_FOO2_FOO}") > > endmacro() > > foo(FOO foo) > --- > > > would produce this output: > > _FOO1_FOO=foo > _FOO2_FOO=foo > > > In CMake v3.5.0-rc2 the output is the following: > > _FOO1_FOO= > _FOO2_FOO=foo > > > This means that the last argument is no longer handled in the same way > as it was before. > > > Is this an intended change? If it is, I think this is worth a policy, > since I believe it will break a lot of code... > > > > Cheers, > Daniele > > -- > > 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 From dimitar.yordanov at sap.com Fri Feb 12 10:47:36 2016 From: dimitar.yordanov at sap.com (Yordanov, Dimitar) Date: Fri, 12 Feb 2016 15:47:36 +0000 Subject: [cmake-developers] [PATCH] Possible regression in cmake_parse_arguments in CMake v3.5.0-rc2 Message-ID: <5AA074723FDBE144A86F4BFBE1BD03FF99632C@DEWDFEMB11B.global.corp.sap> Hi, the attached patch should address the issue discussed by Daniele and Matthias. The test case provided was also added. Best wishes Dimitar >From 5d51943372608a071983921395423a3cb363d233 Mon Sep 17 00:00:00 2001 From: Dimitar Yordanov Date: Fri, 12 Feb 2016 16:19:22 +0100 Subject: [PATCH] Possible regression in cmake_parse_arguments in CMake v3.5.0-rc2 Dimitar Yordanov (1): CMakeParseArguments: Fix a regression when parsing ARGN Source/cmParseArgumentsCommand.cxx | 11 ++++++++++- .../RunCMake/cmake_parse_arguments/CornerCases.cmake | 19 +++++++++++++++++++ 2 files changed, 29 insertions(+), 1 deletion(-) -- 2.3.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CMakeParseArguments-Fix-a-regression-when-parsing-AR.patch Type: application/octet-stream Size: 2821 bytes Desc: 0001-CMakeParseArguments-Fix-a-regression-when-parsing-AR.patch URL: From brad.king at kitware.com Fri Feb 12 11:27:56 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 12 Feb 2016 11:27:56 -0500 Subject: [cmake-developers] [PATCH] Possible regression in cmake_parse_arguments in CMake v3.5.0-rc2 In-Reply-To: <5AA074723FDBE144A86F4BFBE1BD03FF99632C@DEWDFEMB11B.global.corp.sap> References: <5AA074723FDBE144A86F4BFBE1BD03FF99632C@DEWDFEMB11B.global.corp.sap> Message-ID: <56BE080C.1050504@kitware.com> On 02/12/2016 10:47 AM, Yordanov, Dimitar wrote: > the attached patch should address the issue discussed by Daniele and Matthias. > The test case provided was also added. Great, thanks. I updated the comment and commit message slightly and applied it: cmake_parse_arguments: Restore ;-list argument flattening https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c8c45a2c I've queued this for merge to 'release' for inclusion in 3.5.0-rc3. Please also follow up with some test cases that add ";" "\\;" "\\\\;" etc. within arguments to make sure they are treated the same way as before. Thanks, -Brad From plucinski.mariusz at gmail.com Sat Feb 13 06:08:25 2016 From: plucinski.mariusz at gmail.com (=?UTF-8?Q?Mariusz_Pluci=C5=84ski?=) Date: Sat, 13 Feb 2016 12:08:25 +0100 Subject: [cmake-developers] [PATCH] Proposal of fix for issue #12873 (AUTOMOC produces same output moc file if target has two source files resides in different sub-directory) Message-ID: Hello, CMake developers, I would like to propose a fix for an issue http://public.kitware.com/Bug/view.php?id=12873 (AUTOMOC produces same output moc file if target has two source files resides in different sub-directory). Proposed patch modifies names of generated moc_*.cpp files to make them unique across the project, by inserting also the names of the directories where the header is located. Part of the patch is also the change in test QtAutogen that verifies the fix. Best Regards Mariusz Plucinski -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-support-of-files-with-the-same-name-in-Automoc-1.patch Type: application/octet-stream Size: 4347 bytes Desc: not available URL: From mantis at public.kitware.com Sat Feb 13 18:11:39 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 13 Feb 2016 18:11:39 -0500 Subject: [cmake-developers] [CMake 0015973]: ASM-ATT: cannot set assembler using environment variable Message-ID: <541ad106b2ab0097c6482cb7930e362e@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15973 ====================================================================== Reported By: Pawe? Stankowski Assigned To: ====================================================================== Project: CMake Issue ID: 15973 Category: CMake Reproducibility: always Severity: trivial Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-13 18:11 EST Last Modified: 2016-02-13 18:11 EST ====================================================================== Summary: ASM-ATT: cannot set assembler using environment variable Description: Environment variable cannot be used for ATT dialect, because it contains dash in this variable's name ("ASM-ATT"). Bash and other shells won't parse assignment to variable containing such sign. There is an ugly workaround, though: env 'ASM-ATT=~/bin/i386-linux-as' cmake ../src CMakeDetermineASMCompiler.cmake checks for existance of environment variable ASM${ASM_DIALECT} at the early phase of lookup. This works nicely for NASM and MASM assemblers, because they use underscore instead of dash (ASM_NASM, ASM_MASM). Steps to Reproduce: 1. Install two gas assemblers: in system and other directory. 2. In a build directory try to point cmake to the non-default assembler: env 'ASM-ATT=' cmake ../src 3. Check which assembler was chosen: grep ASM-ATT_COMPILER:FILEPATH CMakeCache.txt Additional Information: I propose to solve that by replacing '-' by '_' when searching for environment variable in CMakeDetermineASMCompiler.cmake. It is possible to preserve backward compatibility by searching for both old and new variable. However, because it was so difficult to set ASM-ATT env variable, it is probably not needed. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-13 18:11 Pawe? StankowskiNew Issue ====================================================================== From mantis at public.kitware.com Sat Feb 13 18:55:10 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 13 Feb 2016 18:55:10 -0500 Subject: [cmake-developers] [CMake 0015974]: Some cmake variables not set for gas assembler Message-ID: <94dbc91530858ecaa8a1e345f0744179@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15974 ====================================================================== Reported By: Pawe? Stankowski Assigned To: ====================================================================== Project: CMake Issue ID: 15974 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-13 18:55 EST Last Modified: 2016-02-13 18:55 EST ====================================================================== Summary: Some cmake variables not set for gas assembler Description: CMAKE__COMPILER_VERSION - could be easily filled at least for gas - output from "--version" command is checked anyway. CMAKE_COMPILER_IS_GNUAS variable could be defined to simplify check whether gas was found. I proposed 'AS' as a part for consistency - GNU syntax is used for other names. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-13 18:55 Pawe? StankowskiNew Issue ====================================================================== From nicolas.despres at gmail.com Sun Feb 14 04:12:52 2016 From: nicolas.despres at gmail.com (=?UTF-8?Q?Nicolas_Despr=C3=A8s?=) Date: Sun, 14 Feb 2016 10:12:52 +0100 Subject: [cmake-developers] Using CMake generated ninja file as a subninja file In-Reply-To: <20160122165048.GB26825@megas.kitware.com> References: <20160106172504.GB6998@megas.kitware.com> <20160106183552.GA29325@megas.kitware.com> <20160122165048.GB26825@megas.kitware.com> Message-ID: Ben, I have pushed a complete version of the patch here: https://github.com/nicolasdespres/CMake/commits/ninja-output-path-prefix Since the last push, I have addressed the comments you made in your previous review (i.e. move some code to cmAlgorithm.h) and added a RunCMake.NinjaOutputPathPrefix tests. The 'default' statement is no longer generated when CMAKE_NINJA_OUTPUT_PATH_PREFIX is set because, unlike rules, "default" statement are not scoped. Thus, if the user does not include one in the top build.ninja only the default target of the subninja file was built. This was a surprising behaviour for me, since I expected to build all "leaf" output targets of the graph as usual when running ninja without argument. Let me know what you think about this change. Last note: some of the tests were failing on master (dec7d5c4de7870ec) on my machines (macbookpro and linux box), so I don't know if they are broken or not by my patch: 194 - CTestCoverageCollectGCOV (Failed) 393 - RunCMake.CommandLine (Failed) 401 - RunCMake.IfacePaths_INCLUDE_DIRECTORIES (Failed) Cheers, Nicolas On Fri, Jan 22, 2016 at 5:50 PM, Ben Boeckel wrote: > On Fri, Jan 22, 2016 at 17:34:03 +0100, Nicolas Despr?s wrote: > > I have pushed a first draft of the patch here: > > > > > https://github.com/nicolasdespres/CMake/commit/67a4faad47378c07c97a29dd229d6f9fa500763b > > > > I have tested with a small project and it looks good. > > Looks like a good start to me as well. I added some comments on the > commit. > > > I would like to add some regression tests but I don't know from where to > > start. > > > > The principle would be to duplicate and modify existing tests so that > > CMAKE_NINJA_OUTPUT_PATH_PREFIX is set to "sub/" and the build directory > is > > changed from _build to _build/sub. A dummy build.ninja file containing > > "subninja sub/build.ninja" should be generated in _build/build.ninja and > > ninja should be called from _build instead of _build/sub. > > > > It would be great if you could point me some existing tests that could > > serve as a base to do the above. > > The RunCMake test infrastructure would probably be the best place to > start. It could be modified to do some of this work. > > Thanks, > > --Ben > -- Nicolas Despr?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjklaim at gmail.com Sun Feb 14 06:58:03 2016 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Sun, 14 Feb 2016 12:58:03 +0100 Subject: [cmake-developers] CMake Daemon blog In-Reply-To: References: Message-ID: I'm surprised too that there isn't more feedback around here. This seems to be a marjor potential improvement and definitely necessary if CMake need to be usable in the coming years. On 10 February 2016 at 09:42, Tobias Hunger wrote: > Hey, I did send a MR on github:-) > > But I agree, I had also hoped for more active participation. > > Best Regards, > Tobias > > On Wed, Feb 10, 2016 at 12:07 AM, Stephen Kelly > wrote: > > Stephen Kelly wrote: > > > >> Hi, > >> > >> I just made a blog and video about the advanced features and > possibilities > >> that a daemon mode for CMake can bring: > >> > >> https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ > >> > > > > > > The lack of response on the list to any of this is quite disappointing. > > > > -- > > > > 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 > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hunger at gmail.com Sun Feb 14 07:47:20 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Sun, 14 Feb 2016 13:47:20 +0100 Subject: [cmake-developers] CMake Daemon blog In-Reply-To: References: Message-ID: Hi Klaim, I spent the WE to improve the unit tests in my fork of Stephen's cmake-daemon (which got broken when I added some basic protocol features earlier in the same fork). I could use some help in this task that does not involve C++ coding:-) Best Regards, Tobias Am 14.02.2016 12:58 schrieb "Klaim - Jo?l Lamotte" : > I'm surprised too that there isn't more feedback around here. > This seems to be a marjor potential improvement and definitely necessary > if CMake need to be usable in the coming years. > > On 10 February 2016 at 09:42, Tobias Hunger > wrote: > >> Hey, I did send a MR on github:-) >> >> But I agree, I had also hoped for more active participation. >> >> Best Regards, >> Tobias >> >> On Wed, Feb 10, 2016 at 12:07 AM, Stephen Kelly >> wrote: >> > Stephen Kelly wrote: >> > >> >> Hi, >> >> >> >> I just made a blog and video about the advanced features and >> possibilities >> >> that a daemon mode for CMake can bring: >> >> >> >> >> https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ >> >> >> > >> > >> > The lack of response on the list to any of this is quite disappointing. >> > >> > -- >> > >> > 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 >> -- >> >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Richter at hogyros.de Sun Feb 14 14:51:10 2016 From: Simon.Richter at hogyros.de (Simon Richter) Date: Sun, 14 Feb 2016 20:51:10 +0100 Subject: [cmake-developers] [PATCH 1/2] FindwxWidgets.cmake: Fix up wxWidgets_CXXFLAGS In-Reply-To: <1455479471-17371-1-git-send-email-Simon.Richter@hogyros.de> References: <1455479471-17371-1-git-send-email-Simon.Richter@hogyros.de> Message-ID: <1455479471-17371-2-git-send-email-Simon.Richter@hogyros.de> This variable contains a semicolon-separated list, but a string of space-separated options is needed. As -I and -D options are separated out, this usually does not cause any trouble, unless more than one option is needed. --- Modules/FindwxWidgets.cmake | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Modules/FindwxWidgets.cmake b/Modules/FindwxWidgets.cmake index 49ce57e..12cb1ca 100644 --- a/Modules/FindwxWidgets.cmake +++ b/Modules/FindwxWidgets.cmake @@ -787,6 +787,10 @@ else() string(REPLACE "-I" "" wxWidgets_INCLUDE_DIRS "${wxWidgets_INCLUDE_DIRS}") + # Flags are a string, not a list, fix it here + string(REPLACE ";" " " + wxWidgets_CXX_FLAGS "${wxWidgets_CXX_FLAGS}") + DBG_MSG_V("wxWidgets_DEFINITIONS=${wxWidgets_DEFINITIONS}") DBG_MSG_V("wxWidgets_INCLUDE_DIRS=${wxWidgets_INCLUDE_DIRS}") DBG_MSG_V("wxWidgets_CXX_FLAGS=${wxWidgets_CXX_FLAGS}") -- 2.1.4 From Simon.Richter at hogyros.de Sun Feb 14 14:51:11 2016 From: Simon.Richter at hogyros.de (Simon Richter) Date: Sun, 14 Feb 2016 20:51:11 +0100 Subject: [cmake-developers] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths In-Reply-To: <1455479471-17371-2-git-send-email-Simon.Richter@hogyros.de> References: <1455479471-17371-1-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-2-git-send-email-Simon.Richter@hogyros.de> Message-ID: <1455479471-17371-3-git-send-email-Simon.Richter@hogyros.de> CMake expects Windows style paths on MSYS, so use the cygpath utility to resolve them. --- Modules/FindwxWidgets.cmake | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/Modules/FindwxWidgets.cmake b/Modules/FindwxWidgets.cmake index 12cb1ca..ed34216 100644 --- a/Modules/FindwxWidgets.cmake +++ b/Modules/FindwxWidgets.cmake @@ -839,6 +839,34 @@ else() endif() endif() + # When using wx-config in MSYS, the include paths are UNIX style paths which may or may + # not work correctly depending on you MSYS/MinGW configuration. CMake expects native + # paths internally. + if(wxWidgets_FOUND AND MSYS) + find_program(_cygpath_exe cygpath ONLY_CMAKE_FIND_ROOT_PATH) + DBG_MSG_V("_cygpath_exe: ${_cygpath_exe}") + if(_cygpath_exe) + set(_tmp_path "") + foreach(_path ${wxWidgets_INCLUDE_DIRS}) + execute_process( + COMMAND cygpath -w ${_path} + OUTPUT_VARIABLE _native_path + RESULT_VARIABLE _retv + OUTPUT_STRIP_TRAILING_WHITESPACE + ERROR_QUIET + ) + if(_retv EQUAL 0) + file(TO_CMAKE_PATH ${_native_path} _native_path) + DBG_MSG_V("Path ${_path} converted to ${_native_path}") + set(_tmp_path "${_tmp_path} ${_native_path}") + endif() + endforeach() + DBG_MSG("Setting wxWidgets_INCLUDE_DIRS = ${_tmp_path}") + set(wxWidgets_INCLUDE_DIRS ${_tmp_path}) + separate_arguments(wxWidgets_INCLUDE_DIRS) + list(REMOVE_ITEM wxWidgets_INCLUDE_DIRS "") + endif() + endif() #===================================================================== # Neither UNIX_FIND_STYLE, nor WIN32_FIND_STYLE #===================================================================== -- 2.1.4 From Simon.Richter at hogyros.de Sun Feb 14 14:51:09 2016 From: Simon.Richter at hogyros.de (Simon Richter) Date: Sun, 14 Feb 2016 20:51:09 +0100 Subject: [cmake-developers] [PATCH 0/2] FindwxWidgets: two more msys patches Message-ID: <1455479471-17371-1-git-send-email-Simon.Richter@hogyros.de> Hi, these are two more patches from the KiCad project, more specifically Wayne Stambaugh -- all I did was separate them out, so these can't be attributed to me. These are required for KiCad to build correctly on MSYS2. Simon Simon Richter (2): FindwxWidgets.cmake: Fix up wxWidgets_CXXFLAGS FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths Modules/FindwxWidgets.cmake | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) -- 2.1.4 From mjklaim at gmail.com Sun Feb 14 18:39:26 2016 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Mon, 15 Feb 2016 00:39:26 +0100 Subject: [cmake-developers] CMake Daemon blog In-Reply-To: References: Message-ID: Nice work! I would love to help but I'm already overloaded with tons of work for now. :/ On 14 February 2016 at 13:47, Tobias Hunger wrote: > Hi Klaim, > > I spent the WE to improve the unit tests in my fork of Stephen's > cmake-daemon (which got broken when I added some basic protocol features > earlier in the same fork). > > I could use some help in this task that does not involve C++ coding:-) > > Best Regards, > Tobias > Am 14.02.2016 12:58 schrieb "Klaim - Jo?l Lamotte" : > >> I'm surprised too that there isn't more feedback around here. >> This seems to be a marjor potential improvement and definitely necessary >> if CMake need to be usable in the coming years. >> >> On 10 February 2016 at 09:42, Tobias Hunger >> wrote: >> >>> Hey, I did send a MR on github:-) >>> >>> But I agree, I had also hoped for more active participation. >>> >>> Best Regards, >>> Tobias >>> >>> On Wed, Feb 10, 2016 at 12:07 AM, Stephen Kelly >>> wrote: >>> > Stephen Kelly wrote: >>> > >>> >> Hi, >>> >> >>> >> I just made a blog and video about the advanced features and >>> possibilities >>> >> that a daemon mode for CMake can bring: >>> >> >>> >> >>> https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ >>> >> >>> > >>> > >>> > The lack of response on the list to any of this is quite disappointing. >>> > >>> > -- >>> > >>> > 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 >>> -- >>> >>> 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 >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hunger at gmail.com Mon Feb 15 13:24:34 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Mon, 15 Feb 2016 19:24:34 +0100 Subject: [cmake-developers] [Qt-creator] CMake daemon for user tools In-Reply-To: References: <56923C33.6030506@gmail.com> Message-ID: Hi Dominik, Am 15.02.2016 19:01 schrieb "Dominik Haumann" : > 1. Wouldn't it make sense you have a developer sprint ASAP for this? I'd be in, but I do not have the time to organize one. I could probably get a room in our office though (in Berlin). > 2. Reading about this deamon approach, rtags comes to my mind: rtags I personally do not consider rtags to be very interesting for my use-cases. But I am the wrong person for that topic anyway. > Given this background, I can see a lot of benefits in a cmake deamon > that provides all sorts of infos... So do I. I did a bit of hacking on a fork of Stephen's code ( https://github.com/hunger/CMake/tree/cmake-daemon) where I added some protocol improvements (more unified JSON messages going back and forth, consistent error reporting, consistent progress reporting, more unit tests, etc.). No new functionality, just a bit of polish here and there. Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.wueger at gmx.at Tue Feb 16 07:17:31 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Tue, 16 Feb 2016 13:17:31 +0100 Subject: [cmake-developers] Run program/command before test Message-ID: Hello, Is it possible with CMake >= 3.4.0 to run a program/command before the test and another program after the test was run? The meaning of that would be, that I want to start a small server program and run the "client" test. After the test was finished, kill the process of the server program or do a graceful shutdown of it. Thanks in advance Best Regards Roman From brad.king at kitware.com Tue Feb 16 10:49:04 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Feb 2016 10:49:04 -0500 Subject: [cmake-developers] Run program/command before test In-Reply-To: References: Message-ID: <56C344F0.2010703@kitware.com> On 02/16/2016 07:17 AM, Roman W?ger wrote: > Is it possible with CMake >= 3.4.0 to run a program/command before the > test and another program after the test was run? > > The meaning of that would be, that I want to start a small server > program and run the "client" test. After the test was finished, > kill the process of the server program or do a graceful shutdown of it. There is currently no builtin feature for that. Other than a few test output matching properties, ctest always expects the process to be independent and report results via its exit code. -Brad From brad.king at kitware.com Tue Feb 16 10:49:11 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Feb 2016 10:49:11 -0500 Subject: [cmake-developers] [PATCH] Proposal of fix for issue #12873 (AUTOMOC produces same output moc file if target has two source files resides in different sub-directory) In-Reply-To: References: Message-ID: <56C344F7.2060102@kitware.com> On 02/13/2016 06:08 AM, Mariusz Pluci?ski wrote: > I would like to propose a fix for an issue 12873 > > Part of the patch is also the change in test QtAutogen that verifies the fix. Thanks. Applied with minor tweaks: Automoc: Fix support of files with the same name (#12873) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9beb2744 -Brad From brad.king at kitware.com Tue Feb 16 10:49:17 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Feb 2016 10:49:17 -0500 Subject: [cmake-developers] [PATCH] FindProtobuf: check version In-Reply-To: <1455261824-22482-1-git-send-email-antonioperez@by.com.es> References: <1455261824-22482-1-git-send-email-antonioperez@by.com.es> Message-ID: <56C344FD.5080002@kitware.com> On 02/12/2016 02:23 AM, Antonio Perez Barrero wrote: > Check found libraries version to match user required version. Thanks. Applied with minor tweaks and a test case: FindProtobuf: check version https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb7a41ab -Brad From brad.king at kitware.com Tue Feb 16 10:49:24 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Feb 2016 10:49:24 -0500 Subject: [cmake-developers] [PATCH]: CodeBlocks: improve support for different compilers In-Reply-To: <6CCDA91481A9E4418A996AE30C2278100215FF74@DLREXMBX01.intra.dlr.de> References: <6CCDA91481A9E4418A996AE30C2278100215FF74@DLREXMBX01.intra.dlr.de> Message-ID: <56C34504.80107@kitware.com> On 02/12/2016 03:24 AM, Melven.Roehrig-Zoellner at dlr.de wrote: > Just a small patch for the CodeBlocks generator Thanks! Applied: CodeBlocks: improve support for different compilers https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=184da3f4 -Brad From brad.king at kitware.com Tue Feb 16 10:49:32 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Feb 2016 10:49:32 -0500 Subject: [cmake-developers] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths In-Reply-To: <1455479471-17371-3-git-send-email-Simon.Richter@hogyros.de> References: <1455479471-17371-1-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-2-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-3-git-send-email-Simon.Richter@hogyros.de> Message-ID: <56C3450C.5030608@kitware.com> On 02/14/2016 02:51 PM, Simon Richter wrote: > CMake expects Windows style paths on MSYS, so use the cygpath utility to > resolve them. Thanks. Is that utility guaranteed to exist? IIRC the original MSYS intentionally did not include such a utility. In the past I've used a helper function like this: native_path() { cmd //c echo "$1" | sed 's/^"//;s/"$//' } to convert paths in a shell script without the cygpath tool. -Brad From brad.king at kitware.com Tue Feb 16 10:50:03 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Feb 2016 10:50:03 -0500 Subject: [cmake-developers] [PATCH 1/2] FindwxWidgets.cmake: Fix up wxWidgets_CXXFLAGS In-Reply-To: <1455479471-17371-2-git-send-email-Simon.Richter@hogyros.de> References: <1455479471-17371-1-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-2-git-send-email-Simon.Richter@hogyros.de> Message-ID: <56C3452B.4080703@kitware.com> On 02/14/2016 02:51 PM, Simon Richter wrote: > This variable contains a semicolon-separated list, but a string of > space-separated options is needed. As -I and -D options are separated out, > this usually does not cause any trouble, unless more than one option is > needed. [snip] > + # Flags are a string, not a list, fix it here > + string(REPLACE ";" " " > + wxWidgets_CXX_FLAGS "${wxWidgets_CXX_FLAGS}") This was discussed here: https://cmake.org/Bug/view.php?id=15087#c36639 We cannot simply change the flags because existing code could be depending on the old value. We addressed it here instead as of CMake 3.1: UsewxWidgets: CFLAGS are expected to be a string here, not a list. https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e6fa6e60 Uses in other projects simply need to be fixed. -Brad From mantis at public.kitware.com Tue Feb 16 10:58:03 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 16 Feb 2016 10:58:03 -0500 Subject: [cmake-developers] [CMake 0015975]: GHS Multi Generator: COPY_FILE in try_compile does not work Message-ID: <49d59c7137f7ef51a98fa97f004ed03b@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15975 ====================================================================== Reported By: stw_sesa Assigned To: ====================================================================== Project: CMake Issue ID: 15975 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-16 10:58 EST Last Modified: 2016-02-16 10:58 EST ====================================================================== Summary: GHS Multi Generator: COPY_FILE in try_compile does not work Description: try_compile COPY_FILE: The GHS MULTI Compiler compiles+links the executable to "targetname.as", but the CMake Generator currently looks for "targetname" (without extension). As a folder with such a name exists in the build directory COPY_FILE copies the folder instead of the built executable and the try_compile execution does not fail. Steps to Reproduce: Create a simple CMakeLists.txt like this: try_compile( result "${CMAKE_BINARY_DIR}/CMakeFiles/CMakeTmp" "${CMAKE_SOURCE_DIR}/test.c" COPY_FILE "${CMAKE_BINARY_DIR}/test_executable" ) message(STATUS "result of try_compile: " ${result}) Create a simple test program as "test.c": int main(int argc, char *argv[]) { return 0; } Run CMake using GHS MULTI Generator (ARM Integrity). Actual result: try_compile succeeds and a empty folder "test_executable" is created in the build directory Expected result: try_compile succeeds and the built executable "test_executable" is located in the build directory Additional Information: I've tried setting set("CMAKE_EXECUTABLE_SUFFIX", ".as") manually at various locations but it didn't work. Either it wasn't set at all or overwritten; I don't know. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-16 10:58 stw_sesa New Issue ====================================================================== From Simon.Richter at hogyros.de Tue Feb 16 11:29:50 2016 From: Simon.Richter at hogyros.de (Simon Richter) Date: Tue, 16 Feb 2016 17:29:50 +0100 Subject: [cmake-developers] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths In-Reply-To: <56C3450C.5030608@kitware.com> References: <1455479471-17371-1-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-2-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-3-git-send-email-Simon.Richter@hogyros.de> <56C3450C.5030608@kitware.com> Message-ID: <56C34E7E.3020805@hogyros.de> Hi, Am 16.02.2016 um 16:49 schrieb Brad King: > Thanks. Is that utility guaranteed to exist? IIRC the original MSYS > intentionally did not include such a utility. The patched wx-config in MSYS2 invokes cygpath to resolve the Unix path they would otherwise return to a native path with forward slashes, so my expectation would be that it is guaranteed to exist on MSYS2. The patch falls back to doing nothing if the tool does not exist, so older versions that don't patch wx-config should still work. Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From Simon.Richter at hogyros.de Tue Feb 16 11:35:22 2016 From: Simon.Richter at hogyros.de (Simon Richter) Date: Tue, 16 Feb 2016 17:35:22 +0100 Subject: [cmake-developers] [PATCH 1/2] FindwxWidgets.cmake: Fix up wxWidgets_CXXFLAGS In-Reply-To: <56C3452B.4080703@kitware.com> References: <1455479471-17371-1-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-2-git-send-email-Simon.Richter@hogyros.de> <56C3452B.4080703@kitware.com> Message-ID: <56C34FCA.7080304@hogyros.de> Hi, Am 16.02.2016 um 16:50 schrieb Brad King: >> This variable contains a semicolon-separated list, but a string of >> space-separated options is needed. As -I and -D options are separated out, >> this usually does not cause any trouble, unless more than one option is >> needed. > UsewxWidgets: CFLAGS are expected to be a string here, not a list. > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e6fa6e60 > Uses in other projects simply need to be fixed. Can this be taken over into a project with a 3.0 minimum version requirement? Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From brad.king at kitware.com Tue Feb 16 12:40:31 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Feb 2016 12:40:31 -0500 Subject: [cmake-developers] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths In-Reply-To: <56C34E7E.3020805@hogyros.de> References: <1455479471-17371-1-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-2-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-3-git-send-email-Simon.Richter@hogyros.de> <56C3450C.5030608@kitware.com> <56C34E7E.3020805@hogyros.de> Message-ID: <56C35F0F.6060209@kitware.com> On 02/16/2016 11:29 AM, Simon Richter wrote: > The patched wx-config in MSYS2 invokes cygpath to resolve the Unix path > they would otherwise return to a native path with forward slashes, so my > expectation would be that it is guaranteed to exist on MSYS2. How is it that a native-Windows CMake is able to execute the wx-config tool? If it is a CMake that is built with the MSYS2 runtime then it should be able to understand the unix paths. There has been discussion on cmake-developers before about having a MSYS2-native CMake build much like the Cygwin-native build we have already. -Brad From brad.king at kitware.com Tue Feb 16 12:41:38 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Feb 2016 12:41:38 -0500 Subject: [cmake-developers] [PATCH 1/2] FindwxWidgets.cmake: Fix up wxWidgets_CXXFLAGS In-Reply-To: <56C34FCA.7080304@hogyros.de> References: <1455479471-17371-1-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-2-git-send-email-Simon.Richter@hogyros.de> <56C3452B.4080703@kitware.com> <56C34FCA.7080304@hogyros.de> Message-ID: <56C35F52.6010106@kitware.com> On 02/16/2016 11:35 AM, Simon Richter wrote: >> Uses in other projects simply need to be fixed. > > Can this be taken over into a project with a 3.0 minimum version > requirement? What do you mean by "taken over"? Do you mean to copy the fixed UsewxWidgets module into the project? That make work, but one could always copy the version from CMake 3.0 and apply this fix. -Brad From gvjung at gmail.com Tue Feb 16 13:16:33 2016 From: gvjung at gmail.com (Greg Jung) Date: Tue, 16 Feb 2016 10:16:33 -0800 Subject: [cmake-developers] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths In-Reply-To: <56C35F0F.6060209@kitware.com> References: <1455479471-17371-1-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-2-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-3-git-send-email-Simon.Richter@hogyros.de> <56C3450C.5030608@kitware.com> <56C34E7E.3020805@hogyros.de> <56C35F0F.6060209@kitware.com> Message-ID: On Tue, Feb 16, 2016 at 9:40 AM, Brad King wrote: > On 02/16/2016 11:29 AM, Simon Richter wrote: > > The patched wx-config in MSYS2 invokes cygpath to resolve the Unix path > > they would otherwise return to a native path with forward slashes, so my > > expectation would be that it is guaranteed to exist on MSYS2. > > How is it that a native-Windows CMake is able to execute the wx-config > tool? If it is a CMake that is built with the MSYS2 runtime then it > should be able to understand the unix paths. > > There has been discussion on cmake-developers before about having > a MSYS2-native CMake build much like the Cygwin-native build we > have already. > > -Brad > > Simon is working on MSYS2 for a mingw build. The MSYS2-native CMake is a different beast, and wouldn't be producing mingw programs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Feb 16 13:22:43 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Feb 2016 13:22:43 -0500 Subject: [cmake-developers] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths In-Reply-To: References: <1455479471-17371-1-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-2-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-3-git-send-email-Simon.Richter@hogyros.de> <56C3450C.5030608@kitware.com> <56C34E7E.3020805@hogyros.de> <56C35F0F.6060209@kitware.com> Message-ID: <56C368F3.9090205@kitware.com> On 02/16/2016 01:16 PM, Greg Jung wrote: > Simon is working on MSYS2 for a mingw build. The MSYS2-native CMake > is a different beast, and wouldn't be producing mingw programs. Okay, then why do we need to support a MSYS2-native `wx-config` tool? A true MinGW wx-config should report Windows paths. -Brad From gvjung at gmail.com Tue Feb 16 13:42:57 2016 From: gvjung at gmail.com (Greg Jung) Date: Tue, 16 Feb 2016 10:42:57 -0800 Subject: [cmake-developers] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths In-Reply-To: <56C368F3.9090205@kitware.com> References: <1455479471-17371-1-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-2-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-3-git-send-email-Simon.Richter@hogyros.de> <56C3450C.5030608@kitware.com> <56C34E7E.3020805@hogyros.de> <56C35F0F.6060209@kitware.com> <56C368F3.9090205@kitware.com> Message-ID: > > A true MinGW wx-config should report Windows paths. Good point, which is why modifying wx-config is done. MSYS/configure ... will build wx as if it knows nothing about windows' paths and the wx-config output works as it should, it is an MSYS weakness that fails in one aspect downstream (I forget exactly what), the workaround is to make the paths come out of wx-config in DOS format. Since this workaround wasn't implemented until the more recent msys2 package builds (which are compiled with a different compiler - worse possible headaches), Simon worked a cmake fix. For my usage I've been editing wx-config. On Tue, Feb 16, 2016 at 10:22 AM, Brad King wrote: > On 02/16/2016 01:16 PM, Greg Jung wrote: > > Simon is working on MSYS2 for a mingw build. The MSYS2-native CMake > > is a different beast, and wouldn't be producing mingw programs. > > Okay, then why do we need to support a MSYS2-native `wx-config` tool? > A true MinGW wx-config should report Windows paths. > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Feb 16 14:17:46 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 16 Feb 2016 14:17:46 -0500 Subject: [cmake-developers] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths In-Reply-To: References: <1455479471-17371-1-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-2-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-3-git-send-email-Simon.Richter@hogyros.de> <56C3450C.5030608@kitware.com> <56C34E7E.3020805@hogyros.de> <56C35F0F.6060209@kitware.com> <56C368F3.9090205@kitware.com> Message-ID: <56C375DA.6000307@kitware.com> On 02/16/2016 01:42 PM, Greg Jung wrote: > A true MinGW wx-config should report Windows paths. > > Good point, which is why modifying wx-config is done. > MSYS/configure ... will build wx as if it knows nothing about > windows' paths and the wx-config output works as it should, > it is an MSYS weakness that fails in one aspect downstream > (I forget exactly what), the workaround is to make the paths > come out of wx-config in DOS format. Since this workaround > wasn't implemented until the more recent msys2 package builds > (which are compiled with a different compiler - worse possible headaches), > Simon worked a cmake fix. For my usage I've been editing wx-config. Okay, I see that we are already handling this special case in FindwxWidgets.cmake by using "sh wx-config" in execute_process calls. This means the module is already aware that the wx-config it is running is not a Windows tool. The proposed change merely adds support for treating the output accordingly. I've applied the change with minor tweaks and tried to explain this in the commit message: FindwxWidgets: Resolve Cygwin/MSYS paths to Windows paths https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=843213d5 Thanks, -Brad From taylor at braun-jones.org Tue Feb 16 15:10:51 2016 From: taylor at braun-jones.org (Taylor Braun-Jones) Date: Tue, 16 Feb 2016 15:10:51 -0500 Subject: [cmake-developers] CMake Daemon blog In-Reply-To: References: Message-ID: On Sat, Jan 30, 2016 at 2:06 AM, Stephen Kelly wrote: > I've just pushed the daemon code here: > > https://github.com/steveire/cmake/tree/cmake-daemon > > The Kate plugin should soon appear here I think: > > https://quickgit.kde.org/?p=scratch%2Fskelly%2Fcmakekate.git Thanks for sharing, Stephen! Do you plan to also share the standalone Qt-based editor/client as well (cmake-browser)? That would be immediately useful to me and allow me to more easily test drive all this work that you've done. Cheers, Taylor From daniel.wirtz at simtech.uni-stuttgart.de Tue Feb 16 15:46:57 2016 From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz) Date: Wed, 17 Feb 2016 09:46:57 +1300 Subject: [cmake-developers] Bugfix for CPack / CPACK_INSTALL_CMAKE_PROJECTS Message-ID: <56C38AC1.6050807@simtech.uni-stuttgart.de> Dear all, i think i've encountered a bug where the fourth (=SubDirectory) entry of the CPACK_INSTALL_CMAKE_PROJECTS list is simply ignored. I stumbled on this as i was trying to use something other than "/" for that part (Superbuild project with collecting CPack). I've searched the source code and i think the bug is located at \Source\CPack\cmCPackGenerator.cxx:729: (Git Rev 8dfb6f8b372b159c050b6ea5e16b4e44dd9ed095) 726: std::string realInstallDirectory = tempInstallDirectory; 727: if ( !installSubDirectory.empty() && installSubDirectory != "/" ) 728: { 729: realInstallDirectory += installSubDirectory; 730: } The variable "realInstallDirectory" is simply not used anymore within the entire CMake source after line 729. I've changed this to "tempInstallDirectory" and the behaviour is as i expected it - works for me now. The offending lines of code have been committed in 2006 with c09c3c6bfadb41bd0b43082642ce76abbf02df06 - i doubt that no one ever tried to use something other than "/" since then? Or is there something else i'm missing? Best, Daniel -- Dr. Daniel Wirtz Dipl. Math. Dipl. Inf. SRC SimTech Pfaffenwaldring 5a, D-70569 Stuttgart +49 (711) 685-60044 From Simon.Richter at hogyros.de Tue Feb 16 16:15:38 2016 From: Simon.Richter at hogyros.de (Simon Richter) Date: Tue, 16 Feb 2016 22:15:38 +0100 Subject: [cmake-developers] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths In-Reply-To: <56C375DA.6000307@kitware.com> References: <1455479471-17371-1-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-2-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-3-git-send-email-Simon.Richter@hogyros.de> <56C3450C.5030608@kitware.com> <56C34E7E.3020805@hogyros.de> <56C35F0F.6060209@kitware.com> <56C368F3.9090205@kitware.com> <56C375DA.6000307@kitware.com> Message-ID: <56C3917A.6050906@hogyros.de> Hi Brad. On 16.02.2016 20:17, Brad King wrote: > I've applied the change with minor tweaks and tried to explain this > in the commit message: Hm, only problem is patch attribution here -- I've written that these are from Wayne, and should be attributed to him (but submitting these with his name in the From: field obviously would not have worked). Can this still be fixed? Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From daniel.wirtz at simtech.uni-stuttgart.de Tue Feb 16 17:42:39 2016 From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz) Date: Wed, 17 Feb 2016 11:42:39 +1300 Subject: [cmake-developers] Pssible documentation error in install(TARGETS ) signature Message-ID: <56C3A5DF.8070600@simtech.uni-stuttgart.de> The current CMake version has an error in the Documentation (or a Bug in the Code, depending on how this turns out). In https://cmake.org/cmake/help/v3.5/command/install.html#installing-targets, the optional argument order is [...] [INCLUDES DESTINATION [ ...]] [PERMISSIONS permissions...] [CONFIGURATIONS [Debug|Release|...]] [COMPONENT ] [...] if i use that in the order as documented, e.g. install(TARGETS mytarget EXPORT myexport RUNTIME DESTINATION bin COMPONENT Runtime ARCHIVE DESTINATION lib INCLUDES DESTINATION include COMPONENT Runtime ), the resulting cmake_install.cmake file will contain the install type "Unspecified" for my .lib archives (using windows) i have to change the order of the arguments (using COMPONENT before INCLUDES DESTINATION): install(TARGETS mytarget EXPORT myexport RUNTIME DESTINATION bin COMPONENT Runtime ARCHIVE DESTINATION lib COMPONENT Runtime # Note swap here INCLUDES DESTINATION include # Note swap here ) then it correctly puts "Runtime" in the cmake_install.cmake file. if the order of the arguments matters: update documentation? if the order does not matter: could be a bug in the parser (two-element keyword INCLUDES DESTINATION?)? any opinions welcome .. Best, Daniel -- Dr. Daniel Wirtz Dipl. Math. Dipl. Inf. SRC SimTech Pfaffenwaldring 5a, D-70569 Stuttgart +49 (711) 685-60044 From mantis at public.kitware.com Tue Feb 16 20:26:26 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 16 Feb 2016 20:26:26 -0500 Subject: [cmake-developers] [CMake 0015976]: cmSystemTools::RandomSeed() requests excessive entropy per invocation Message-ID: <62a9a41db4f96e3a3d2b7e771e574a38@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15976 ====================================================================== Reported By: Cristian Rodr?guez Assigned To: ====================================================================== Project: CMake Issue ID: 15976 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-16 20:26 EST Last Modified: 2016-02-16 20:26 EST ====================================================================== Summary: cmSystemTools::RandomSeed() requests excessive entropy per invocation Description: cmSystemTools::RandomSeed() opens a *buffered* ifstream, the final result is that each invocation requests _IO_BUFSIZ -1 of entropy to the operating system instead of just sizeof(seed) Steps to Reproduce: mkdir test_cmake echo "PROJECT(foo)" > CMakeLists.txt cd test_cmake strace -f -ocmake.trace cmake . open cmake.trace 10768 26289 open("/dev/urandom", O_RDONLY) = 4 10769 26289 read(4, "h\304j\vx\314\26\0042\250g\275\0014,\256\251\257T&\304\212\310\347q\201\263\324\330\273z8"..., 8191) = 8191 10770 26289 close(4) = 0 10771 26289 write(3, "cmake_minimum_required(VERSION 3"..., 795) = 795 10772 26289 close(3) = 0 10773 26289 stat("/home/crrodriguez/test_cmake/CMakeFiles/CMakeTmp", {st_mode=S_IFDIR|0755, st_size=58, ...}) = 0 10774 26289 getcwd("/home/crrodriguez/test_cmake", 2048) = 29 Additional Information: git diff diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx index 3ba7287..26bec34 100644 --- a/Source/cmSystemTools.cxx +++ b/Source/cmSystemTools.cxx @@ -2184,8 +2184,10 @@ unsigned int cmSystemTools::RandomSeed() } seed; // Try using a real random source. - cmsys::ifstream fin("/dev/urandom"); - if(fin && fin.read(seed.bytes, sizeof(seed)) && + cmsys::ifstream fin; + fin.rdbuf()->pubsetbuf(0, 0); + fin.open("/dev/urandom"); + if(fin.good() && fin.read(seed.bytes, sizeof(seed)) && fin.gcount() == sizeof(seed)) { return seed.integer; ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-16 20:26 Cristian Rodr?guezNew Issue ====================================================================== From mantis at public.kitware.com Tue Feb 16 20:28:46 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 16 Feb 2016 20:28:46 -0500 Subject: [cmake-developers] [CMake 0015977]: include_directories() gags on ".." embedded in directory path Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15977 ====================================================================== Reported By: Richard Lang Assigned To: ====================================================================== Project: CMake Issue ID: 15977 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-16 20:28 EST Last Modified: 2016-02-16 20:28 EST ====================================================================== Summary: include_directories() gags on ".." embedded in directory path Description: Working on port of collection of existing projects from proprietary toolchain to cmake, where some source and include files reside in sibling/common ancestor folders of of the project folders |-- SharedSource | |--SharedSource1.c | |--SharedSource2.c | +--SharedSource1.h +-- Project1 | |--Project1.c | +--MakeLists.txt +-- Project2 |--Project2.c +--MakeLists.txt Using Windows native cmake v3.4.1 I can quite happily specify "SharedSource" as an include directory in my project cmake scripts using a "../' parent directory relative reference as follows: ... include_directories(../SharedSource) ... however when I try and run the same script using cmake within the cygwin & MSYS2 UNIX emulation environments it fails with a "Found relative path while evaluating include directories" message. The problem still occurs when I explicitly prepend CMAKE_CURRENT_SOURCE_DIR on the path, as follows include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../SharedSource) The cygwin cmake version is 3.3.1, while the MSYS2 one is 3.2.3, and probably reflects the current version in these environments, as I've installed them pretty recently. Additional Information: Don't currently have a native UNIX/linux environment to try this on. I'm a UNIX novice, but AFAIK "../SharedSource" should be a valid relative path on UNIX platforms. Can't see anything obvious in the bug tracker that would suggest that this has been fixed between 3.3.1 and 3.4.1, suggesting it's maybe a platform idiosyncrasy. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-16 20:28 Richard Lang New Issue ====================================================================== From roman.wueger at gmx.at Wed Feb 17 01:58:07 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 17 Feb 2016 07:58:07 +0100 Subject: [cmake-developers] Run program/command before test In-Reply-To: <56C344F0.2010703@kitware.com> References: <56C344F0.2010703@kitware.com> Message-ID: <577600E5-6080-43AF-A16D-5132B6BC2D94@gmx.at> Ok thanks Would it be an opinion to have a COMMAND parameter for the add_test function like execute_process where every COMMAND must return the exit code and this would be ored? add_test(MyTest COMMAND myserver --port 80 COMMAND mytest COMMAND myserver --graceful-shutdown) Or add_test(MyTest PRE_COMMAND myserver --port 80 COMMAND mytest POST_COMMAND myserver --graceful-shutdown) Best Regards Roman > Am 16.02.2016 um 16:49 schrieb Brad King : > >> On 02/16/2016 07:17 AM, Roman W?ger wrote: >> Is it possible with CMake >= 3.4.0 to run a program/command before the >> test and another program after the test was run? >> >> The meaning of that would be, that I want to start a small server >> program and run the "client" test. After the test was finished, >> kill the process of the server program or do a graceful shutdown of it. > > There is currently no builtin feature for that. Other than a few > test output matching properties, ctest always expects the process > to be independent and report results via its exit code. > > -Brad > From nilsgladitz at gmail.com Wed Feb 17 03:09:18 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 17 Feb 2016 09:09:18 +0100 Subject: [cmake-developers] Run program/command before test In-Reply-To: <577600E5-6080-43AF-A16D-5132B6BC2D94@gmx.at> References: <56C344F0.2010703@kitware.com> <577600E5-6080-43AF-A16D-5132B6BC2D94@gmx.at> Message-ID: <56C42AAE.2040606@gmail.com> On 17.02.2016 07:58, Roman W?ger wrote: > Ok thanks > > Would it be an opinion to have a COMMAND parameter for the add_test function like execute_process where every COMMAND must return the exit code and this would be ored? > > add_test(MyTest COMMAND myserver --port 80 > COMMAND mytest > COMMAND myserver --graceful-shutdown) > > Or > > add_test(MyTest PRE_COMMAND myserver --port 80 > COMMAND mytest > POST_COMMAND myserver --graceful-shutdown) What you could already do is wrap your test in a cmake script. E.g. add_test(NAME MyTest COMMAND ${CMAKE_COMMAND} -DACTUAL_TEST=$ -P ${CMAKE_CURRENT_SOURCE_DIR}/mywrapper.cmake ) Where mywrapper.cmake could do something like: execute_process(COMMAND mysever --port 80 ...) execute_process(COMMAND ${ACTUAL_TEST} ....) execute_process(COMMAND mysever --graceful-shutdown) To have the test fail you could call message(FATAL_ERROR "...") For this to work myserver would have to daemonize/fork (but I assume that is the case given your example). Nils From roman.wueger at gmx.at Wed Feb 17 04:32:18 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 17 Feb 2016 10:32:18 +0100 Subject: [cmake-developers] Run program/command before test In-Reply-To: <56C42AAE.2040606@gmail.com> References: <56C344F0.2010703@kitware.com> <577600E5-6080-43AF-A16D-5132B6BC2D94@gmx.at> <56C42AAE.2040606@gmail.com> Message-ID: <29A748F9-4F32-4177-A519-F52C47CE9687@gmx.at> Hi Nils, great thanks. Regards Roman > Am 17.02.2016 um 09:09 schrieb Nils Gladitz : > >> On 17.02.2016 07:58, Roman W?ger wrote: >> Ok thanks >> >> Would it be an opinion to have a COMMAND parameter for the add_test function like execute_process where every COMMAND must return the exit code and this would be ored? >> >> add_test(MyTest COMMAND myserver --port 80 >> COMMAND mytest >> COMMAND myserver --graceful-shutdown) >> >> Or >> >> add_test(MyTest PRE_COMMAND myserver --port 80 >> COMMAND mytest >> POST_COMMAND myserver --graceful-shutdown) > > What you could already do is wrap your test in a cmake script. > > E.g. > > add_test(NAME MyTest > COMMAND ${CMAKE_COMMAND} -DACTUAL_TEST=$ -P ${CMAKE_CURRENT_SOURCE_DIR}/mywrapper.cmake > ) > > Where mywrapper.cmake could do something like: > > execute_process(COMMAND mysever --port 80 ...) > > execute_process(COMMAND ${ACTUAL_TEST} ....) > > execute_process(COMMAND mysever --graceful-shutdown) > > To have the test fail you could call message(FATAL_ERROR "...") > > For this to work myserver would have to daemonize/fork (but I assume that is the case given your example). > > Nils From brad.king at kitware.com Wed Feb 17 09:33:42 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 17 Feb 2016 09:33:42 -0500 Subject: [cmake-developers] [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5 In-Reply-To: References: <56BA1B94.5000407@kitware.com> <56BB4D3E.6000408@kitware.com> Message-ID: <56C484C6.7040100@kitware.com> Moving discussion to cmake-developers. On 02/15/2016 12:47 PM, James Crosby wrote: > I'm worried that built-in compiler detection might not be possible across > the variety of cross-compilers used. In some cases, for example, the > existence of a particular compiler, or a modified version of it, might be > a secret outside of the company using it. One could look at adding hooks to the compiler id logic to add alternatives provided by the toolchain file. Or, we could provide a way to set the compiler id but not also skip other checks. In the worst case such a company could modify their CMake for use with such a toolchain. I do not consider this a blocking issue for deprecating CMakeForceCompiler. > Using a dummy link command to check that linking works seems to > undermine the purpose of checking in the first place, which suggests > that perhaps it should still be possible to skip the check? It is not just a check that linking works. CMake actually encodes string literals in the compiled binary and parses it to extract them. This allows us to extract information about the compiler target architecture and compiler capabilities. OTOH we may not actually have to link to achieve this. Perhaps we could have a setting in a toolchain file like set(CMAKE_TRY_COMPILE_NO_LINK 1) that tells CMake to use add_library(STATIC) instead of add_executable() in its generated try_compile projects. That would avoid linking through the toolchain. Meanwhile I've de-deprecated the module for the 3.5 release: CMakeForceCompiler: De-deprecate until more use cases have alternatives https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=beaa4fa5 However, I'd really like to get a solution to the above worked out so that it can be re-deprecated for the 3.6 release. The module is simply not compatible with all the information CMake now wants to detect from toolchains. Thanks, -Brad From brad.king at kitware.com Wed Feb 17 09:33:53 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 17 Feb 2016 09:33:53 -0500 Subject: [cmake-developers] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths In-Reply-To: <56C3917A.6050906@hogyros.de> References: <1455479471-17371-1-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-2-git-send-email-Simon.Richter@hogyros.de> <1455479471-17371-3-git-send-email-Simon.Richter@hogyros.de> <56C3450C.5030608@kitware.com> <56C34E7E.3020805@hogyros.de> <56C35F0F.6060209@kitware.com> <56C368F3.9090205@kitware.com> <56C375DA.6000307@kitware.com> <56C3917A.6050906@hogyros.de> Message-ID: <56C484D1.8080709@kitware.com> On 02/16/2016 04:15 PM, Simon Richter wrote: > Hm, only problem is patch attribution here -- I've written that these > are from Wayne, and should be attributed to him (but submitting these > with his name in the From: field obviously would not have worked). IIRC if you commit with --author='...' then `git format-patch` adds info to the message that records the author even when you send the email. > Can this still be fixed? Yes, the patch had only been merged to 'next' for testing. Here is a revised version which will become the one merged to 'master': FindwxWidgets: Resolve Cygwin/MSYS paths to Windows paths https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf643286 Thanks, -Brad From brad.king at kitware.com Wed Feb 17 10:18:18 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 17 Feb 2016 10:18:18 -0500 Subject: [cmake-developers] Pssible documentation error in install(TARGETS ) signature In-Reply-To: <56C3A5DF.8070600@simtech.uni-stuttgart.de> References: <56C3A5DF.8070600@simtech.uni-stuttgart.de> Message-ID: <56C48F3A.3060400@kitware.com> On 02/16/2016 05:42 PM, Daniel Wirtz wrote: > if the order of the arguments matters: update documentation? Thanks, updated: Help: Clarify install(TARGETS) INCLUDES DESTINATION option https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c978223c -Brad From brad.king at kitware.com Wed Feb 17 10:56:17 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 17 Feb 2016 10:56:17 -0500 Subject: [cmake-developers] Bugfix for CPack / CPACK_INSTALL_CMAKE_PROJECTS In-Reply-To: <56C38AC1.6050807@simtech.uni-stuttgart.de> References: <56C38AC1.6050807@simtech.uni-stuttgart.de> Message-ID: <56C49821.90408@kitware.com> On 02/16/2016 03:46 PM, Daniel Wirtz wrote: > i think i've encountered a bug where the fourth (=SubDirectory) entry of > the CPACK_INSTALL_CMAKE_PROJECTS list is simply ignored. [snip] > The offending lines of code have been committed in 2006 with > c09c3c6bfadb41bd0b43082642ce76abbf02df06 - i doubt that no one ever > tried to use something other than "/" since then? That appears to be the case. There is no test case in our test suite for it either. If you fix this please look at adding one. Also update the documentation to clarify the use case. Thanks, -Brad From mantis at public.kitware.com Wed Feb 17 11:06:52 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 17 Feb 2016 11:06:52 -0500 Subject: [cmake-developers] [CMake 0015978]: Visual Studio 2015 Update 2 CTP support Message-ID: <2983405fd21b86ae4139d7121835fbb0@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15978 ====================================================================== Reported By: Niclas Lars?n Assigned To: ====================================================================== Project: CMake Issue ID: 15978 Category: CMake Reproducibility: always Severity: feature Priority: high Status: new ====================================================================== Date Submitted: 2016-02-17 11:06 EST Last Modified: 2016-02-17 11:06 EST ====================================================================== Summary: Visual Studio 2015 Update 2 CTP support Description: the latest visual studio preview isn't supported by cmake. -- The C compiler identification is unknown -- The CXX compiler identification is unknown CMake Error at CMakeLists.txt:43 (project): No CMAKE_C_COMPILER could be found. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-17 11:06 Niclas Lars?n New Issue ====================================================================== From James.Crosby at arm.com Wed Feb 17 13:46:55 2016 From: James.Crosby at arm.com (James Crosby) Date: Wed, 17 Feb 2016 18:46:55 +0000 Subject: [cmake-developers] [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5 In-Reply-To: <56C484C6.7040100@kitware.com> References: <56BA1B94.5000407@kitware.com> <56BB4D3E.6000408@kitware.com> <56C484C6.7040100@kitware.com> Message-ID: <6AFB6565-459A-4917-B436-E30995CE86A1@arm.com> > On 17 Feb 2016, at 14:33, Brad King wrote: > > One could look at adding hooks to the compiler id logic to add alternatives > provided by the toolchain file. Or, we could provide a way to set the compiler > id but not also skip other checks. In the worst case such a company could modify > their CMake for use with such a toolchain. I do not consider this a blocking > issue for deprecating CMakeForceCompiler. I think allowing the compiler id to be set might be enough ? in the case that the compiler is completely unknown, functionality is anyway going to be limited to what the user implements/supports themselves. > It is not just a check that linking works. CMake actually encodes string > literals in the compiled binary and parses it to extract them. This allows > us to extract information about the compiler target architecture and compiler > capabilities. OTOH we may not actually have to link to achieve this. > > Perhaps we could have a setting in a toolchain file like > > set(CMAKE_TRY_COMPILE_NO_LINK 1) > > that tells CMake to use add_library(STATIC) instead of add_executable() > in its generated try_compile projects. That would avoid linking through > the toolchain. OK this makes a lot more sense to me now (I should have looked at the code first ;). It seems like the option to link a static library would have all the benefits of getting information out of the compiler itself (instead of duplicating it in toolchain files), without having to be able to produce a linkable executable. > Meanwhile I've de-deprecated the module for the 3.5 release: Thanks, this will be useful breathing space! James IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From Stephen.Sorley at jhuapl.edu Wed Feb 17 14:53:53 2016 From: Stephen.Sorley at jhuapl.edu (Sorley, Stephen L.) Date: Wed, 17 Feb 2016 19:53:53 +0000 Subject: [cmake-developers] FindCUDA.cmake regression in 3.5.0-rc2 Message-ID: FindCUDA.cmake from 3.5.0-rc2 is failing for me when creating solution files for Visual Studio on Windows (VS 2013 update 4, to be specific). The ninja generator on Windows is unaffected. When I attempt to build a cuda target, the compile step for each .cu file fails with the following message: Building NVCC (Device) object utils/CMakeFiles/utils_cu.dir/Release/utils_cu_generated_cudaarray.cu.obj 3> cudaarray.cu 3> 3> '$' is not recognized as an internal or external command, 3> 3> operable program or batch file. 3> 3> CMake Error at utils_cu_generated_cudaarray.cu.obj.cmake:207 (message): 3> Error generating 3> C:/Users/sorlesl1/Desktop/testproj/build/utils/CMakeFiles/utils_cu.dir//Release/utils_cu_generated_cudaarray.cu.obj I've traced the problem to this commit, which added VERBATIM to the add_custom_command() call in CUDA_WRAP_SRCS. Adding the VERBATIM flag changes how the escaped double-quotes in the ccbin_flags variable are interpreted: Without verbatim, ${ccbin_flags} expands to the following in the generated VS project: -D "CCBIN:PATH=$(VCInstallDir)bin" With verbatim, the double quotes are escaped in the generated project, causing the error: -D \"CCBIN:PATH=$(VCInstallDir)bin\" If the escaped quotes are omitted entirely when ccbin_flags is set, the custom command still fails, this time due to VCInstallDir expanding at compile time to a path containing spaces. According to bug 15001, there isn't any way in CMake to correctly quote Visual Studio placeholder variables that expand to values containing spaces - you'll always get either no quotes, or escaped quotes. However, I was able to work around this problem by getting the compiler path directly from CMake instead of using the placeholder. Please see the attached patch (it's based on master) - with this patch, compiling CUDA code with Visual Studio works again. Thanks, Stephen Sorley -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fixed-Visual-Studio-CUDA-compile-failure.patch Type: application/octet-stream Size: 1054 bytes Desc: 0001-Fixed-Visual-Studio-CUDA-compile-failure.patch URL: From brad.king at kitware.com Wed Feb 17 15:28:10 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 17 Feb 2016 15:28:10 -0500 Subject: [cmake-developers] FindCUDA.cmake regression in 3.5.0-rc2 In-Reply-To: References: Message-ID: <56C4D7DA.3000804@kitware.com> On 02/17/2016 02:53 PM, Sorley, Stephen L. wrote: > FindCUDA.cmake from 3.5.0-rc2 is failing for me when creating > solution files for Visual Studio on Windows (VS 2013 update 4, > to be specific). The ninja generator on Windows is unaffected. Thanks for trying the release candidate and tracking this down! In the long run I agree that switching away from $(VCInstallDir) is best, but it is mentioned in several other places within the module and is documented as a valid user-provided value. For now I'd like to fix the regression with minimal changes. Please test this fix on top of 3.5.0-rc2: FindCUDA: Fix regression under Visual Studio generators https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1911cda0 Thanks, -Brad From Stephen.Sorley at jhuapl.edu Wed Feb 17 15:38:58 2016 From: Stephen.Sorley at jhuapl.edu (Sorley, Stephen L.) Date: Wed, 17 Feb 2016 20:38:58 +0000 Subject: [cmake-developers] FindCUDA.cmake regression in 3.5.0-rc2 In-Reply-To: <56C4D7DA.3000804@kitware.com> References: <56C4D7DA.3000804@kitware.com> Message-ID: I tested your fix, it's working well for my project. Thanks for the quick response! -Stephen S. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Wednesday, February 17, 2016 3:28 PM To: Sorley, Stephen L. Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] FindCUDA.cmake regression in 3.5.0-rc2 On 02/17/2016 02:53 PM, Sorley, Stephen L. wrote: > FindCUDA.cmake from 3.5.0-rc2 is failing for me when creating solution > files for Visual Studio on Windows (VS 2013 update 4, to be specific). > The ninja generator on Windows is unaffected. Thanks for trying the release candidate and tracking this down! In the long run I agree that switching away from $(VCInstallDir) is best, but it is mentioned in several other places within the module and is documented as a valid user-provided value. For now I'd like to fix the regression with minimal changes. Please test this fix on top of 3.5.0-rc2: FindCUDA: Fix regression under Visual Studio generators https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1911cda0 Thanks, -Brad From neundorf at kde.org Wed Feb 17 15:59:45 2016 From: neundorf at kde.org (Alexander Neundorf) Date: Wed, 17 Feb 2016 21:59:45 +0100 Subject: [cmake-developers] [PATCH]: CodeBlocks: improve support for different compilers In-Reply-To: <56C34504.80107@kitware.com> References: <6CCDA91481A9E4418A996AE30C2278100215FF74@DLREXMBX01.intra.dlr.de> <56C34504.80107@kitware.com> Message-ID: <27998315.JOK3Fa6LVD@tuxedo.neundorf.net> On Tuesday, February 16, 2016 10:49:24 Brad King wrote: > On 02/12/2016 03:24 AM, Melven.Roehrig-Zoellner at dlr.de wrote: > > Just a small patch for the CodeBlocks generator > > Thanks! Applied: > > CodeBlocks: improve support for different compilers > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=184da3f4 Thanks :-) Alex From steveire at gmail.com Wed Feb 17 16:59:36 2016 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 17 Feb 2016 22:59:36 +0100 Subject: [cmake-developers] [Qt-creator] CMake daemon for user tools In-Reply-To: References: <56923C33.6030506@gmail.com> Message-ID: <56C4ED48.2000604@gmail.com> On 02/15/2016 07:24 PM, Tobias Hunger wrote: > > Hi Dominik, > > Am 15.02.2016 19:01 schrieb "Dominik Haumann" >: > > 1. Wouldn't it make sense you have a developer sprint ASAP for this? > > I'd be in, but I do not have the time to organize one. I could > probably get a room in our office though (in Berlin). > I'd be up for a sprint in Berlin too, but given the muted response so far here, it's not clear who would want to join and what we could achieve. Thanks, Steve. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Wed Feb 17 17:04:06 2016 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 17 Feb 2016 23:04:06 +0100 Subject: [cmake-developers] CMake Daemon blog References: Message-ID: Taylor Braun-Jones wrote: > On Sat, Jan 30, 2016 at 2:06 AM, Stephen Kelly > wrote: >> I've just pushed the daemon code here: >> >> https://github.com/steveire/cmake/tree/cmake-daemon >> >> The Kate plugin should soon appear here I think: >> >> https://quickgit.kde.org/?p=scratch%2Fskelly%2Fcmakekate.git > > Thanks for sharing, Stephen! Do you plan to also share the standalone > Qt-based editor/client as well (cmake-browser)? That would be > immediately useful to me and allow me to more easily test drive all > this work that you've done. I've deliberately not pushed that yet because it would put the wrong focus on the conversation: * It doesn't need a test drive because I know it is limited by the daemon * The focus needs to be on the implementation of the daemon first to make that work better. That can be done by anyone determined enough to paste some things into the stdin. For more see http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/15740 http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/15741 Thanks, Steve. From daniel.wirtz at simtech.uni-stuttgart.de Wed Feb 17 17:31:57 2016 From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz) Date: Thu, 18 Feb 2016 11:31:57 +1300 Subject: [cmake-developers] Bugfix for CPack / CPACK_INSTALL_CMAKE_PROJECTS In-Reply-To: <56C49821.90408@kitware.com> References: <56C38AC1.6050807@simtech.uni-stuttgart.de> <56C49821.90408@kitware.com> Message-ID: <56C4F4DD.4010906@simtech.uni-stuttgart.de> hey, unfortunately i wont have the time to go dig in and provide a test for that .. my work on this project literally ends in one week. we've got our own fork of cmake (https://github.com/OpenCMISS-Dependencies/CMake) that contains fix. here's a patch (based on current master ed1b3430fcfc906780b68fe4a073590c6d23ff08) that at least gets this going. i believe if no one yet complained about the missing feature, it may as well stay as "unsupported" as its been before - at least then the current project group would not have to maintain an extra CMake fork and build process just for those two lines :-) ----------------------------------------------------------------------- From 480a359e795d59d9176251f9d98dbadffafd9793 Mon Sep 17 00:00:00 2001 From: Daniel Wirtz Date: Thu, 18 Feb 2016 11:30:05 +1300 Subject: [PATCH] Fixed the ignored SubDirectory directive for CPack using CPACK_INSTALL_CMAKE_PROJECTS --- Source/CPack/cmCPackGenerator.cxx | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Source/CPack/cmCPackGenerator.cxx b/Source/CPack/cmCPackGenerator.cxx index 22d4bf0..3eca280 100644 --- a/Source/CPack/cmCPackGenerator.cxx +++ b/Source/CPack/cmCPackGenerator.cxx @@ -723,10 +723,9 @@ int cmCPackGenerator::InstallProjectViaInstallCMakeProjects( cmGlobalGenerator gg(&cm); cmsys::auto_ptr mf( new cmMakefile(&gg, cm.GetCurrentSnapshot())); - std::string realInstallDirectory = tempInstallDirectory; if ( !installSubDirectory.empty() && installSubDirectory != "/" ) { - realInstallDirectory += installSubDirectory; + tempInstallDirectory += installSubDirectory; } if (componentInstall) { -- 2.7.0.windows.1 On 18.02.2016 04:56, Brad King wrote: > On 02/16/2016 03:46 PM, Daniel Wirtz wrote: >> i think i've encountered a bug where the fourth (=SubDirectory) entry of >> the CPACK_INSTALL_CMAKE_PROJECTS list is simply ignored. > [snip] >> The offending lines of code have been committed in 2006 with >> c09c3c6bfadb41bd0b43082642ce76abbf02df06 - i doubt that no one ever >> tried to use something other than "/" since then? > That appears to be the case. There is no test case in our test suite > for it either. If you fix this please look at adding one. Also update > the documentation to clarify the use case. > > Thanks, > -Brad > -- Dr. Daniel Wirtz Dipl. Math. Dipl. Inf. SRC SimTech Pfaffenwaldring 5a, D-70569 Stuttgart +49 (711) 685-60044 From mail at milianw.de Wed Feb 17 18:37:06 2016 From: mail at milianw.de (Milian Wolff) Date: Thu, 18 Feb 2016 00:37:06 +0100 Subject: [cmake-developers] [Qt-creator] CMake daemon for user tools In-Reply-To: <56C4ED48.2000604@gmail.com> References: <56923C33.6030506@gmail.com> <56C4ED48.2000604@gmail.com> Message-ID: <4425448.meyAWKQr0m@agathebauer> On Mittwoch, 17. Februar 2016 22:59:36 CET Stephen Kelly wrote: > On 02/15/2016 07:24 PM, Tobias Hunger wrote: > > Hi Dominik, > > > > Am 15.02.2016 19:01 schrieb "Dominik Haumann" > > > >: > > > 1. Wouldn't it make sense you have a developer sprint ASAP for this? > > > > I'd be in, but I do not have the time to organize one. I could > > probably get a room in our office though (in Berlin). > > I'd be up for a sprint in Berlin too, but given the muted response so > far here, it's not clear who would want to join and what we could achieve. Considering the three of us (Tobias, you and me) are in Berlin, I'd say we at least meet for a hackday or so. What do you say? That would get me at least to work 8h on this for a full day and see how it integrates with KDevelop and we could discuss things in-person. Still, I'm aware that I'll have to play around with it before already to not waste too much of your time. Bye -- Milian Wolff mail at milianw.de http://milianw.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From Gilles.Khouzam at microsoft.com Thu Feb 18 02:16:34 2016 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Thu, 18 Feb 2016 07:16:34 +0000 Subject: [cmake-developers] C# support ready for review In-Reply-To: <903866b8ac604d15a1bfb1d3c8c7afe1@DE013666.schaeffler.com> References: <903866b8ac604d15a1bfb1d3c8c7afe1@DE013666.schaeffler.com> Message-ID: Hi Michael, Great work, this looks really good. I have a few comments on the changes. 1. You should use the registry to find the install path for MSBuild, it should be in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild with the version that you're looking for. This also bring the question of do you want to be able to specify the version of MSBuild that is used or base it off the generator? 2. In CMakeTestCSharpCompiler, you seem to still have a reference to your specific user path (COPY_FILE "C:/Users/stuermic/git/cmake_build/x64_14/Tests/CSharp")) You seem to have some slight discrepancies between your code and the release as there are changes that seem to be either unnecessary or going backwards. I noticed a tegra comment that seemed out of place as well as a comment change going from 14 to 12 where 14 was accurate. I'll try to play with this next week and get projects running on it. ~Gilles From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Stuermer, Michael SP/HZA-ZSEP Sent: Wednesday, February 10, 2016 06:03 To: CMake Developers Subject: [cmake-developers] C# support ready for review Native C# support is ready for review. I split the patch in two parts: part 1: Some preparational stuff that does not really change or enable anything. Documentation and Test files as well as the required CMake module is added. The changes to existing code are small, only few methods in existing classes are added/changed. Changes to existing code should be easy to review in this part part 2: This contains the main work. Almost everything takes place within cmVisualStudio10TargetGenerator. In addition to C# support three more target properties were introduced: * VS_USER_PROPS_CXX (allows use of custom .user.props MSBuild file in .vcxproj files) * VS_USER_PROPS_CSHARP (allows use of custom .user.props MSBuild file in .csproj files) * VS_DEBUGGER_WORKING_DIRECTORY (allows setting of debugger working directory in .vcxproj files) I tested the features using Visual Studio 2010-2015 in 32/64 bit and everything works on my machine so far. Please review/test/comment and give feedback what is necessary to get native C# support in upstream cmake. best regards, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at sap.com Thu Feb 18 06:28:25 2016 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Thu, 18 Feb 2016 11:28:25 +0000 Subject: [cmake-developers] Support of Scala language Message-ID: <8D24D0A1-686E-4170-BB47-33275BECCBB2@sap.com> Hi, I have just started to work to extend CMake to support Scala language. This language is very similar to Java regarding compilation (scala compiler generates .class (java byte code)) and packaging (binary files can be packaged in jar files) and is running as part of JVM infrastructure. Currently, there is a module UseJava.cmake which mix two aspects: * Jar management: add_jar, install_jar and find_jar * Java specific stuff: doc, etc? Now, regarding jar management, currently only Java language is supported but, with only very few changes, Scala can be supported as well. So it would be very nice to avoid to duplicate jar management for Scala support. So, I submit the following proposal, regarding current Java and Scala support, to the discussion: * Split current module UseJava.cmake into 2 modules: * UseJar.cmake which will be in charge of jar management, including sources compilation (Java and Scala) * UseJava.cmake, keep Java specific stuff and also include, for compatibility, module UseJar.cmake * For Scala support, provide modules: * FindScala.cmake (same functionality as FindJava.cmake) * UseScala.cmake which can include UseJar.cmake and provides specific stuff (like create_scaladoc) Comments are welcome? Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.stuermer at schaeffler.com Thu Feb 18 06:44:08 2016 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Thu, 18 Feb 2016 11:44:08 +0000 Subject: [cmake-developers] C# support ready for review In-Reply-To: References: <903866b8ac604d15a1bfb1d3c8c7afe1@DE013666.schaeffler.com> Message-ID: <8c87213acb6d49ac8a64c5f8e2998114@DE013666.schaeffler.com> Hi Gilles, you are right about the specific user path. I already fixed this in my github "csharp" branch. Sorry for the inconvenience. As for the discrepancies: I just found out that my TortoiseGitMerge tool was not configured correctly: changes in comments where ignored (which is not what I wanted). I'll go over the patch again and remove the changes that are irrelevant to the C# features. Thanks for the hint on using MSBuild detection. I currently use the msbuild version that is provided automatically by visual studio, so I do not need any real detection. I didn't dig too deep into MSBuild versions, .NET framework versions, what can be configured etc. The configuration possibilities and what would make sense especially for other developers as well is something that should be discussed. My main aim was to be able to work with C# and .NET in a similar way as Visual Studio provides it. I only started C# development during the last year, so many things concerning configuration etc. could probably be improved. I'll post a new version of the patch later (or tomorrow) with the mentioned changes. best regards, Michael From: Gilles Khouzam [mailto:Gilles.Khouzam at microsoft.com] Sent: Thursday, February 18, 2016 8:17 AM To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers Subject: RE: C# support ready for review Hi Michael, Great work, this looks really good. I have a few comments on the changes. 1. You should use the registry to find the install path for MSBuild, it should be in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild with the version that you're looking for. This also bring the question of do you want to be able to specify the version of MSBuild that is used or base it off the generator? 2. In CMakeTestCSharpCompiler, you seem to still have a reference to your specific user path (COPY_FILE "C:/Users/stuermic/git/cmake_build/x64_14/Tests/CSharp")) You seem to have some slight discrepancies between your code and the release as there are changes that seem to be either unnecessary or going backwards. I noticed a tegra comment that seemed out of place as well as a comment change going from 14 to 12 where 14 was accurate. I'll try to play with this next week and get projects running on it. ~Gilles From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Stuermer, Michael SP/HZA-ZSEP Sent: Wednesday, February 10, 2016 06:03 To: CMake Developers > Subject: [cmake-developers] C# support ready for review Native C# support is ready for review. I split the patch in two parts: part 1: Some preparational stuff that does not really change or enable anything. Documentation and Test files as well as the required CMake module is added. The changes to existing code are small, only few methods in existing classes are added/changed. Changes to existing code should be easy to review in this part part 2: This contains the main work. Almost everything takes place within cmVisualStudio10TargetGenerator. In addition to C# support three more target properties were introduced: * VS_USER_PROPS_CXX (allows use of custom .user.props MSBuild file in .vcxproj files) * VS_USER_PROPS_CSHARP (allows use of custom .user.props MSBuild file in .csproj files) * VS_DEBUGGER_WORKING_DIRECTORY (allows setting of debugger working directory in .vcxproj files) I tested the features using Visual Studio 2010-2015 in 32/64 bit and everything works on my machine so far. Please review/test/comment and give feedback what is necessary to get native C# support in upstream cmake. best regards, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleixpol at kde.org Thu Feb 18 08:20:43 2016 From: aleixpol at kde.org (Aleix Pol) Date: Thu, 18 Feb 2016 14:20:43 +0100 Subject: [cmake-developers] [Qt-creator] CMake daemon for user tools In-Reply-To: <56C4ED48.2000604@gmail.com> References: <56923C33.6030506@gmail.com> <56C4ED48.2000604@gmail.com> Message-ID: On Wed, Feb 17, 2016 at 10:59 PM, Stephen Kelly wrote: > On 02/15/2016 07:24 PM, Tobias Hunger wrote: > > Hi Dominik, > > Am 15.02.2016 19:01 schrieb "Dominik Haumann" : >> 1. Wouldn't it make sense you have a developer sprint ASAP for this? > > I'd be in, but I do not have the time to organize one. I could probably get > a room in our office though (in Berlin). Eh... sorry for my silence. I'll be happy to join a small sprint. Aleix From michael.stuermer at schaeffler.com Thu Feb 18 08:40:18 2016 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Thu, 18 Feb 2016 13:40:18 +0000 Subject: [cmake-developers] C# support ready for review (update) Message-ID: Hello all, here is an update of the C# support patch. I fixed the errors & discrepancies reported by Gilles. Hope it looks better now. My development branch can be found here: https://github.com/micst/CMake/tree/csharp It is in the same state as the patch, but includes a few changes which I need for local building and usage. best regards, Michael From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Stuermer, Michael SP/HZA-ZSEP Sent: Wednesday, February 10, 2016 3:03 PM To: CMake Developers Subject: [cmake-developers] C# support ready for review Native C# support is ready for review. I split the patch in two parts: part 1: Some preparational stuff that does not really change or enable anything. Documentation and Test files as well as the required CMake module is added. The changes to existing code are small, only few methods in existing classes are added/changed. Changes to existing code should be easy to review in this part part 2: This contains the main work. Almost everything takes place within cmVisualStudio10TargetGenerator. In addition to C# support three more target properties were introduced: * VS_USER_PROPS_CXX (allows use of custom .user.props MSBuild file in .vcxproj files) * VS_USER_PROPS_CSHARP (allows use of custom .user.props MSBuild file in .csproj files) * VS_DEBUGGER_WORKING_DIRECTORY (allows setting of debugger working directory in .vcxproj files) I tested the features using Visual Studio 2010-2015 in 32/64 bit and everything works on my machine so far. Please review/test/comment and give feedback what is necessary to get native C# support in upstream cmake. best regards, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-prepared-CSharp-support.patch Type: application/octet-stream Size: 40252 bytes Desc: 0001-prepared-CSharp-support.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-implemented-CSharp-support.patch Type: application/octet-stream Size: 41823 bytes Desc: 0002-implemented-CSharp-support.patch URL: From brad.king at kitware.com Thu Feb 18 10:06:12 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 18 Feb 2016 10:06:12 -0500 Subject: [cmake-developers] Support of Scala language In-Reply-To: <8D24D0A1-686E-4170-BB47-33275BECCBB2@sap.com> References: <8D24D0A1-686E-4170-BB47-33275BECCBB2@sap.com> Message-ID: <56C5DDE4.5010007@kitware.com> On 02/18/2016 06:28 AM, CHEVRIER, Marc wrote: > Currently, there is a module UseJava.cmake which mix two aspects: This module is not a good example of how to do a language in CMake. It somehow became the way to do Java in CMake because the builtin support for enable_language(Java) was never really made to work right. (It tries to do separate compilation which is not really generally possible in Java due to circular dependencies of nested classes.) If we're starting with support for a new language then we should add it properly as a first-class language. Eric and Michael (in Cc) have been working on this for Swift and C# recently. Likely there is some overlap in design space. -Brad From brad.king at kitware.com Thu Feb 18 10:06:35 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 18 Feb 2016 10:06:35 -0500 Subject: [cmake-developers] Bugfix for CPack / CPACK_INSTALL_CMAKE_PROJECTS In-Reply-To: <56C4F4DD.4010906@simtech.uni-stuttgart.de> References: <56C38AC1.6050807@simtech.uni-stuttgart.de> <56C49821.90408@kitware.com> <56C4F4DD.4010906@simtech.uni-stuttgart.de> Message-ID: <56C5DDFB.8070004@kitware.com> On 02/17/2016 05:31 PM, Daniel Wirtz wrote: > here's a patch (based on current master > ed1b3430fcfc906780b68fe4a073590c6d23ff08) that at least gets this going. > i believe if no one yet complained about the missing feature, it may as > well stay as "unsupported" as its been before - at least then the > current project group would not have to maintain an extra CMake fork and > build process just for those two lines :-) Good enough for now, thanks. Applied: CPack: Fix CPACK_INSTALL_CMAKE_PROJECTS SubDirectory (4th) option https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=26fdd9c3 -Brad From brad.king at kitware.com Thu Feb 18 10:51:13 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 18 Feb 2016 10:51:13 -0500 Subject: [cmake-developers] install(EXPORT) with PRIVATE dependency: possible bug In-Reply-To: <56990FB3.4040905@kitware.com> References: <56990FB3.4040905@kitware.com> Message-ID: <56C5E871.8090707@kitware.com> On 01/15/2016 10:26 AM, Brad King wrote: > Fix export of STATIC library PRIVATE dependencies with CMP0022 NEW > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aea1b036 That turned out to introduce a regression when the private dependency is not a target. Here is a fix to both problems and new test cases: Fix export of STATIC library PRIVATE non-target dependencies https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=87f44b75 -Brad From neundorf at kde.org Thu Feb 18 15:29:02 2016 From: neundorf at kde.org (Alexander Neundorf) Date: Thu, 18 Feb 2016 21:29:02 +0100 Subject: [cmake-developers] [Qt-creator] CMake daemon for user tools In-Reply-To: <56C4ED48.2000604@gmail.com> References: <56923C33.6030506@gmail.com> <56C4ED48.2000604@gmail.com> Message-ID: <29119808.49cmFxlnYG@tuxedo.neundorf.net> On Wednesday, February 17, 2016 22:59:36 Stephen Kelly wrote: > On 02/15/2016 07:24 PM, Tobias Hunger wrote: > > Hi Dominik, > > > > Am 15.02.2016 19:01 schrieb "Dominik Haumann" > > > >: > > > 1. Wouldn't it make sense you have a developer sprint ASAP for this? > > > > I'd be in, but I do not have the time to organize one. I could > > probably get a room in our office though (in Berlin). > > I'd be up for a sprint in Berlin too, but given the muted response so > far here, it's not clear who would want to join and what we could achieve. just out of curiosity, did you get any feedback from anybody from Eclipse/CDT ? Or CodeBlocks maybe ? Alex From robert.maynard at kitware.com Thu Feb 18 16:01:40 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 18 Feb 2016 16:01:40 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake 3.5.0-rc3 is now ready! Message-ID: I am proud to announce the third CMake 3.5 release candidate. Sources and binaries are available at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.5 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.5/release/3.5.html Some of the more significant features of CMake 3.5 are: * The precompiled Windows binary provided on "cmake.org" is now a ".msi" package instead of an installer executable. One may need to manually uninstall CMake versions lower than 3.5 before installing the new package. * The "cmake-gui(1)" learned an option to set the toolset to be used with VS IDE and Xcode generators, much like the existing "-T" option to "cmake(1)". * Find modules for Boost, FLEX, GTest, GTK2, PNG, TIFF, and XercesC now provide imported targets. * The "FindOpenMP" module learned to support Clang. * A new platform file for cross-compiling in the Cray Linux Environment to target compute nodes was added. See Cross Compiling for the Cray Linux Environment for usage details. * The "Compile Features" functionality is now aware of features supported by Clang compilers on Windows (MinGW). * Support was added for the ARM Compiler (arm.com) with compiler id "ARMCC". * When building for embedded Apple platforms like iOS CMake learned to build and install combined targets which contain both a device and a simulator build. This behavior can be enabled by setting the "IOS_INSTALL_COMBINED" target property. * The "CPackDMG" module learned new variable to specify AppleScript file run to customize appearance of "DragNDrop" installer folder, including background image setting using supplied PNG or multi- resolution TIFF file. See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and "CPACK_DMG_BACKGROUND_IMAGE" variables. Deprecated and Removed Features: * The "cmake(1)" "-E time" command now properly passes arguments with spaces or special characters through to the child process. This may break scripts that worked around the bug with their own extra quoting or escaping. * The "Xcode" generator was fixed to escape backslashes in strings consistently with other generators. Projects that previously worked around the inconsistecy with an extra level of backslashes conditioned on the Xcode generator must be updated to remove the workaround for CMake 3.5 and greater. CMake 3.5 Release Notes *********************** Changes made since CMake 3.4 include the following. New Features ============ GUI --- * The "cmake-gui(1)" gained options to control warnings about deprecated functionality. * The "cmake-gui(1)" learned an option to set the toolset to be used with VS IDE and Xcode generators, much like the existing "-T" option to "cmake(1)". * The "cmake-gui(1)" gained a Regular Expression Explorer which may be used to create and evaluate regular expressions in real-time. The explorer window is available via the "Tools" menu. Command-Line ------------ * The "-Wdev" and "-Wno-dev" "cmake(1)" options now also enable and suppress the deprecated warnings output by default. * The suppression of developer warnings as errors can now be controlled with the new "-Werror=dev" and "-Wno-error=dev" "cmake(1)" options. * The "cmake(1)" "-E" command-line tools "copy", "copy_if_different", "copy_directory", and "make_directory" learned to support multiple input files or directories. Commands -------- * The "cmake_parse_arguments()" command is now implemented natively. The "CMakeParseArguments" module remains as an empty placeholder for compatibility. * The "install(DIRECTORY)" command learned to support "generator expressions" in the list of directories. Variables --------- * The "CMAKE_ERROR_DEPRECATED" variable can now be set using the "-Werror=deprecated" and "-Wno-error=deprecated" "cmake(1)" options. * The "CMAKE_WARN_DEPRECATED" variable can now be set using the "-Wdeprecated" and "-Wno-deprecated" "cmake(1)" options. Properties ---------- * The "VS_GLOBAL_" target property is now implemented for VS 2010 and above. Previously it worked only in VS 2008 and below. Modules ------- * The "ExternalProject" module learned a new "GIT_REMOTE_NAME" option to control the "git clone --origin" value. * The "FindBoost" module now provides imported targets such as "Boost::boost" and "Boost::filesystem". * The "FindFLEX" module "FLEX_TARGET" macro learned a new "DEFINES_FILE" option to specify a custom output header to be generated. * The "FindGTest" module now provides imported targets. * The "FindGTK2" module, when "GTK2_USE_IMPORTED_TARGETS" is enabled, now sets "GTK2_LIBRARIES" to contain the list of imported targets instead of the paths to the libraries. Moreover it now sets a new "GTK2_TARGETS" variable containing all the targets imported. * The "FindOpenMP" module learned to support Clang. * The "FindOpenSSL" module gained a new "OPENSSL_MSVC_STATIC_RT" option to search for libraries using the MSVC static runtime. * The "FindPNG" module now provides imported targets. * The "FindTIFF" module now provides imported targets. * A "FindXalanC" module was introduced to find the Apache Xalan-C++ XSL transform processing library. * The "FindXercesC" module now provides imported targets. Platforms --------- * Support was added for the ARM Compiler (arm.com) with compiler id "ARMCC". * A new platform file for cross-compiling in the Cray Linux Environment to target compute nodes was added. See Cross Compiling for the Cray Linux Environment for usage details. * The "Compile Features" functionality is now aware of features supported by Clang compilers on Windows (MinGW). * When building for embedded Apple platforms like iOS CMake learned to build and install combined targets which contain both a device and a simulator build. This behavior can be enabled by setting the "IOS_INSTALL_COMBINED" target property. CPack ----- * The "CPackDMG" module learned new variable to specify AppleScript file run to customize appearance of "DragNDrop" installer folder, including background image setting using supplied PNG or multi- resolution TIFF file. See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and "CPACK_DMG_BACKGROUND_IMAGE" variables. * The "CPackDeb" module learned to set the optional config file "Source" field using a monolithic or per-component variable. See "CPACK_DEBIAN_PACKAGE_SOURCE". * The "CPackDeb" module learned to set Package, Section and Priority control fields per-component. See variables "CPACK_DEBIAN__PACKAGE_SECTION" and "CPACK_DEBIAN__PACKAGE_PRIORITY". * The "CPack DragNDrop generator" learned to add multi-lingual SLAs to a DMG which is presented to the user when they try to mount the DMG. See the "CPACK_DMG_SLA_LANGUAGES" and "CPACK_DMG_SLA_DIR" variables for details. * The "CPackNSIS" module learned new variables to add bitmaps to the installer. See the "CPACK_NSIS_MUI_WELCOMEFINISHPAGE_BITMAP" and "CPACK_NSIS_MUI_UNWELCOMEFINISHPAGE_BITMAP" variables. * The "CPackRPM" module learned to set Name and Group control fields per-component. See "CPACK_RPM__PACKAGE_NAME" and "CPACK_RPM__PACKAGE_GROUP". Other ----- * Warnings about deprecated functionality are now enabled by default. They may be suppressed with "-Wno-deprecated" or by setting the "CMAKE_WARN_DEPRECATED" variable to false. Deprecated and Removed Features =============================== * The "cmake(1)" "-E time" command now properly passes arguments with spaces or special characters through to the child process. This may break scripts that worked around the bug with their own extra quoting or escaping. * The "Xcode" generator was fixed to escape backslashes in strings consistently with other generators. Projects that previously worked around the inconsistecy with an extra level of backslashes conditioned on the Xcode generator must be updated to remove the workaround for CMake 3.5 and greater. Other Changes ============= * The "Visual Studio 14 2015" generator learned to map the "/debug:fastlink" linker flag to the ".vcxproj" file property. * The "FindGTK2" module now configures the "GTK2::sigc++" imported target to enable c++11 on its dependents when using sigc++ 2.5.1 or higher. * The precompiled Windows binary provided on "cmake.org" is now a ".msi" package instead of an installer executable. One may need to manually uninstall CMake versions lower than 3.5 before installing the new package. ---------------------------------------------------------------------------- Changes made since CMake 3.5.0-rc2: Brad King (7): Help: Add release note about Xcode escaping fix (#15969) cmake-gui: Fix cmState initialization when changing generators (#15959) CMakeForceCompiler: De-deprecate until more use cases have alternatives Help: Clarify install(TARGETS) INCLUDES DESTINATION option Fix export of STATIC library PRIVATE non-target dependencies FindCUDA: Fix regression under Visual Studio generators CMake 3.5.0-rc3 Dimitar Yordanov (1): cmake_parse_arguments: Restore ;-list argument flattening From sean at rogue-research.com Thu Feb 18 18:25:10 2016 From: sean at rogue-research.com (Sean McBride) Date: Thu, 18 Feb 2016 18:25:10 -0500 Subject: [cmake-developers] Drop support for older Xcode versions? In-Reply-To: References: <56B5CFA3.5090107@googlemail.com> <20160208152121.1630645796@mail.rogue-research.com> <56B8B4C5.9090806@kitware.com> <20160208154830.1125542189@mail.rogue-research.com> <56B9FC7D.9080705@davyandbeth.com> Message-ID: <20160218232510.1176202249@mail.rogue-research.com> On Wed, 10 Feb 2016 15:25:31 -0800, Eric Wing said: >On 2/9/16, Davy Durham wrote: >> I'll say that in my line of work, we still have to support OS X 10.6 >> (just dropped 10.5 support) .. And we're doing this at Apple's own >> request/demand! It's not fun. I've had to hack tools around to get >> somewhat newer tool chains to continue to work, but it's been /great/ >> that cmake hasn't been an obstacle in this endeavour. > >Supporting 10.6...this is what I'm referring to. In Apple's world, >this means you are on 10.11 using Xcode 7.3 and setting the Deployment >target to 10.6. > >I know for hard cases, it is never that simple, but do you really need >to be on 10.6 to develop for 10.6? As you say, you can develop on newest and set old deployment target. But when you run into a bug that only reproduces on 10.6, what then? The nicest is to build & debug on 10.6 so you can debug it. This means being able to use the (newest) Xcode that supports that OS. Again, I don't care about 10.6 per se, but substitute 10.x for whatever the oldest you care about is, and the above still applies. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From ddurham at davyandbeth.com Thu Feb 18 18:34:02 2016 From: ddurham at davyandbeth.com (Davy Durham) Date: Thu, 18 Feb 2016 17:34:02 -0600 Subject: [cmake-developers] Drop support for older Xcode versions? Message-ID: Actually we have to keep an os x 10.8 box up with the 10.7 sdk using xcode 4.2 targeting 10.6. Apple long ago stopped allowing you to target such old APIs in more recent xcodes. Sent from my personalized C Spire Galaxy S III
-------- Original message --------
From: Sean McBride
Date:02/18/2016 17:25 (GMT-06:00)
To: Eric Wing , cmake-developers at cmake.org
Subject: Re: [cmake-developers] Drop support for older Xcode versions?
On Wed, 10 Feb 2016 15:25:31 -0800, Eric Wing said: >On 2/9/16, Davy Durham wrote: >> I'll say that in my line of work, we still have to support OS X 10.6 >> (just dropped 10.5 support) .. And we're doing this at Apple's own >> request/demand! It's not fun. I've had to hack tools around to get >> somewhat newer tool chains to continue to work, but it's been /great/ >> that cmake hasn't been an obstacle in this endeavour. > >Supporting 10.6...this is what I'm referring to. In Apple's world, >this means you are on 10.11 using Xcode 7.3 and setting the Deployment >target to 10.6. > >I know for hard cases, it is never that simple, but do you really need >to be on 10.6 to develop for 10.6? As you say, you can develop on newest and set old deployment target. But when you run into a bug that only reproduces on 10.6, what then? The nicest is to build & debug on 10.6 so you can debug it. This means being able to use the (newest) Xcode that supports that OS. Again, I don't care about 10.6 per se, but substitute 10.x for whatever the oldest you care about is, and the above still applies. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at sap.com Fri Feb 19 03:35:54 2016 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Fri, 19 Feb 2016 08:35:54 +0000 Subject: [cmake-developers] Support of Scala language In-Reply-To: <56C5DDE4.5010007@kitware.com> References: <8D24D0A1-686E-4170-BB47-33275BECCBB2@sap.com> <56C5DDE4.5010007@kitware.com> Message-ID: <05108AB2-5A5E-49A3-B21E-997116190C55@sap.com> I agree. The right approach is to do an integration of Java in the same way as C or C++. But I don?t have currently enough CMake skills to do this work. Do you have some documentation explaining how language support is done in CMake ? And how specific behaviours of Java/Scala can be supported in CMake: * All sources composing a jar must be compiled all at once * A source file can produce an arbitrary number of binary files (.class) with various (and unpredictable) names. Marc On 18/02/16 16:06, "Brad King" wrote: >On 02/18/2016 06:28 AM, CHEVRIER, Marc wrote: >> Currently, there is a module UseJava.cmake which mix two aspects: > >This module is not a good example of how to do a language in CMake. >It somehow became the way to do Java in CMake because the builtin >support for enable_language(Java) was never really made to work right. >(It tries to do separate compilation which is not really generally >possible in Java due to circular dependencies of nested classes.) > >If we're starting with support for a new language then we should >add it properly as a first-class language. Eric and Michael (in Cc) >have been working on this for Swift and C# recently. Likely there >is some overlap in design space. > >-Brad From ewmailing at gmail.com Fri Feb 19 03:47:58 2016 From: ewmailing at gmail.com (Eric Wing) Date: Fri, 19 Feb 2016 00:47:58 -0800 Subject: [cmake-developers] Support of Scala language In-Reply-To: <05108AB2-5A5E-49A3-B21E-997116190C55@sap.com> References: <8D24D0A1-686E-4170-BB47-33275BECCBB2@sap.com> <56C5DDE4.5010007@kitware.com> <05108AB2-5A5E-49A3-B21E-997116190C55@sap.com> Message-ID: >> >>If we're starting with support for a new language then we should >>add it properly as a first-class language. Eric and Michael (in Cc) >>have been working on this for Swift and C# recently. Likely there >>is some overlap in design space. >> On 2/19/16, CHEVRIER, Marc wrote: > I agree. The right approach is to do an integration of Java in the same way > as C or C++. > But I don?t have currently enough CMake skills to do this work. > > Do you have some documentation explaining how language support is done in > CMake ? And how specific behaviours of Java/Scala can be supported in > CMake: > * All sources composing a jar must be compiled all at once > * A source file can produce an arbitrary number of binary files (.class) > with various (and unpredictable) names. > Yes, for Swift, I think I'm going to need something similar to the all sources at once thing. I'm avoiding this for the moment, but I'm told the mechanism I'm relying on isn't guaranteed to work in the future. From gjasny at googlemail.com Fri Feb 19 04:53:21 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Fri, 19 Feb 2016 10:53:21 +0100 Subject: [cmake-developers] Drop support for older Xcode versions? In-Reply-To: References: Message-ID: <56C6E611.4010208@googlemail.com> Hello, On 19/02/16 00:34, Davy Durham wrote: > Actually we have to keep an os x 10.8 box up with the 10.7 sdk using > xcode 4.2 targeting 10.6. Apple long ago stopped allowing you to target > such old APIs in more recent xcodes. At my company we build 10.6 compatible software using Xcode 6.3. What exactly does not work for you with Xcode 6/7? Thanks, Gregor From steveire at gmail.com Fri Feb 19 05:36:35 2016 From: steveire at gmail.com (Stephen Kelly) Date: Fri, 19 Feb 2016 11:36:35 +0100 Subject: [cmake-developers] [Qt-creator] CMake daemon for user tools References: <56923C33.6030506@gmail.com> <56C4ED48.2000604@gmail.com> <29119808.49cmFxlnYG@tuxedo.neundorf.net> Message-ID: Alexander Neundorf wrote: > On Wednesday, February 17, 2016 22:59:36 Stephen Kelly wrote: >> On 02/15/2016 07:24 PM, Tobias Hunger wrote: >> > Hi Dominik, >> > >> > Am 15.02.2016 19:01 schrieb "Dominik Haumann" >> > > > >> > >: >> > > 1. Wouldn't it make sense you have a developer sprint ASAP for this? >> > >> > I'd be in, but I do not have the time to organize one. I could >> > probably get a room in our office though (in Berlin). >> >> I'd be up for a sprint in Berlin too, but given the muted response so >> far here, it's not clear who would want to join and what we could >> achieve. > > just out of curiosity, did you get any feedback from anybody from > Eclipse/CDT ? Nope. No response from there at all despite reaching out to them. > Or CodeBlocks maybe ? I didn't reach out to them, so no. Thanks, Steve. From mantis at public.kitware.com Fri Feb 19 08:21:28 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 19 Feb 2016 08:21:28 -0500 Subject: [cmake-developers] [CMake 0015982]: CPACK_CREATE_DESKTOP_LINKS not working when CPACK_NSIS_MODIFY_PATH is disabled Message-ID: <84a061337477d8746121c52ad767052c@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15982 ====================================================================== Reported By: Jan R?egg Assigned To: ====================================================================== Project: CMake Issue ID: 15982 Category: CPack Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-19 08:21 EST Last Modified: 2016-02-19 08:21 EST ====================================================================== Summary: CPACK_CREATE_DESKTOP_LINKS not working when CPACK_NSIS_MODIFY_PATH is disabled Description: When setting both CPACK_CREATE_DESKTOP_LINKS and CPACK_NSIS_MODIFY_PATH, the generated NSIS installer asks the user in the same screen if he wants to create a desktop Icon, and if he wants to add the executable to the system path. When only CPACK_CREATE_DESKTOP_LINKS is set, this screen is missing from the installer, and it is not possible for the user to create a desktop link. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-19 08:21 Jan R?egg New Issue ====================================================================== From brad.king at kitware.com Fri Feb 19 13:06:32 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 19 Feb 2016 13:06:32 -0500 Subject: [cmake-developers] [patch] Documentation update for CMake 3.5: Describe exact behaviour of cmake's command tools In-Reply-To: <1455901625511.55673@tomtom.com> References: <1455900953266.71278@tomtom.com> <1455901625511.55673@tomtom.com> Message-ID: <56C759A8.3090708@kitware.com> On 02/19/2016 12:07 PM, Bartosz Kosiorek wrote: > In attachment you could find documentation update patch for command tools commands, > to describe exact behavior of commands. Applied, thanks: Help: Clarify `cmake -E` command behavior with respect to file existence https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b3475030 I've queued this for merge to 'release' since documentation updates are still open for 3.5. Thanks, -Brad From ddurham at davyandbeth.com Fri Feb 19 14:22:09 2016 From: ddurham at davyandbeth.com (Davy Durham) Date: Fri, 19 Feb 2016 13:22:09 -0600 Subject: [cmake-developers] Drop support for older Xcode versions? Message-ID: Carbon :-/ Sent from my personalized C Spire Galaxy S III
-------- Original message --------
From: Gregor Jasny
Date:02/19/2016 03:53 (GMT-06:00)
To: Davy Durham , Sean McBride , Eric Wing , cmake-developers at cmake.org
Subject: Re: [cmake-developers] Drop support for older Xcode versions?
Hello, On 19/02/16 00:34, Davy Durham wrote: > Actually we have to keep an os x 10.8 box up with the 10.7 sdk using > xcode 4.2 targeting 10.6. Apple long ago stopped allowing you to target > such old APIs in more recent xcodes. At my company we build 10.6 compatible software using Xcode 6.3. What exactly does not work for you with Xcode 6/7? Thanks, Gregor -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Goulet at autodesk.com Fri Feb 19 14:12:06 2016 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Fri, 19 Feb 2016 19:12:06 +0000 Subject: [cmake-developers] Patch: refactor XCode blocks writing function Message-ID: <627be2f9e0124d07ba240d0f9634d57c@BN1PR79MB007.MGDADSK.autodesk.com> Hi all, I did this refactoring of the function that writes the XCode blocks in the project files, that adds support for any number of nested blocks. And it also makes the code easier to expand in the future. One of the areas that required this for us was adding support for XCode UI Testing (as opposed to non-UI testing), which required us to add the target ID in a nested way that wasn't supported with the previous code. I will send the XCode UI Testing patch separately. Cheers! -Robert Goulet -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Refactor-XCode-block-writes-to-allow-any-number-of-n.patch Type: application/octet-stream Size: 6368 bytes Desc: 0001-Refactor-XCode-block-writes-to-allow-any-number-of-n.patch URL: From neundorf at kde.org Fri Feb 19 17:10:15 2016 From: neundorf at kde.org (Alexander Neundorf) Date: Fri, 19 Feb 2016 23:10:15 +0100 Subject: [cmake-developers] [Qt-creator] CMake daemon for user tools In-Reply-To: References: <56923C33.6030506@gmail.com> <29119808.49cmFxlnYG@tuxedo.neundorf.net> Message-ID: <2513468.nSsZb7l3y1@tuxedo.neundorf.net> On Friday, February 19, 2016 11:36:35 Stephen Kelly wrote: > Alexander Neundorf wrote: > > On Wednesday, February 17, 2016 22:59:36 Stephen Kelly wrote: > >> On 02/15/2016 07:24 PM, Tobias Hunger wrote: > >> > Hi Dominik, > >> > > >> > Am 15.02.2016 19:01 schrieb "Dominik Haumann" > >> > >> > > >> > >: > >> > > 1. Wouldn't it make sense you have a developer sprint ASAP for this? > >> > > >> > I'd be in, but I do not have the time to organize one. I could > >> > probably get a room in our office though (in Berlin). > >> > >> I'd be up for a sprint in Berlin too, but given the muted response so > >> far here, it's not clear who would want to join and what we could > >> achieve. > > > > just out of curiosity, did you get any feedback from anybody from > > Eclipse/CDT ? > > Nope. No response from there at all despite reaching out to them. now that's a pity :-( Alex From eeppeliteloop at gmail.com Fri Feb 19 20:09:25 2016 From: eeppeliteloop at gmail.com (Philippe Proulx) Date: Fri, 19 Feb 2016 20:09:25 -0500 Subject: [cmake-developers] [PATCH] Add FindLTTngUST module to find LTTng-UST library Message-ID: <1455930565-10273-1-git-send-email-eeppeliteloop@gmail.com> Signed-off-by: Philippe Proulx --- Modules/FindLTTngUST.cmake | 88 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+) create mode 100644 Modules/FindLTTngUST.cmake diff --git a/Modules/FindLTTngUST.cmake b/Modules/FindLTTngUST.cmake new file mode 100644 index 0000000..af2c9cd --- /dev/null +++ b/Modules/FindLTTngUST.cmake @@ -0,0 +1,88 @@ +#.rst: +# FindLTTngUST +# ------------ +# +# Try to find the `LTTng-UST `_ library. +# +# Once done, this will define: +# +# ``LTTNGUST_FOUND`` +# ``TRUE`` if system has LTTng-UST +# ``LTTNGUST_INCLUDE_DIR`` +# The LTTng-UST include directory +# ``LTTNGUST_LIBRARIES`` +# The libraries needed to use LTTng-UST +# ``LTTNGUST_VERSION_STRING`` +# The LTTng-UST version +# ``LTTNGUST_HAS_TRACEF`` +# ``TRUE`` if the ``tracef()`` API is available in the system's LTTng-UST +# ``LTTNGUST_HAS_TRACELOG`` +# ``TRUE`` if the ``tracelog()`` API is available in the system's LTTng-UST +# +#============================================================================= +# Copyright 2016 Kitware, Inc. +# Copyright 2016 Philippe Proulx +# +# Distributed under the OSI-approved BSD License (the "License"); +# see accompanying file Copyright.txt for details. +# +# This software is distributed WITHOUT ANY WARRANTY; without even the +# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +# See the License for more information. +#============================================================================= +# (To distribute this file outside of CMake, substitute the full +# License text for the above reference.) + +find_path(LTTNGUST_INCLUDE_DIR NAMES lttng/tracepoint.h) +find_library(LTTNGUST_LIBRARIES NAMES lttng-ust) + +if(LTTNGUST_INCLUDE_DIR) + # find tracef() and tracelog() support + set(LTTNGUST_HAS_TRACEF 0) + set(LTTNGUST_HAS_TRACELOG 0) + + if(EXISTS "${LTTNGUST_INCLUDE_DIR}/lttng/tracef.h") + set(LTTNGUST_HAS_TRACEF TRUE) + endif() + + if(EXISTS "${LTTNGUST_INCLUDE_DIR}/lttng/tracelog.h") + set(LTTNGUST_HAS_TRACELOG TRUE) + endif() + + # get version + set(lttngust_version_file "${LTTNGUST_INCLUDE_DIR}/lttng/ust-version.h") + + if(EXISTS "${lttngust_version_file}") + file(STRINGS "${lttngust_version_file}" lttngust_version_major_string + REGEX "^[\t ]*#define[\t ]+LTTNG_UST_MAJOR_VERSION[\t ]+[0-9]+[\t ]*$") + file(STRINGS "${lttngust_version_file}" lttngust_version_minor_string + REGEX "^[\t ]*#define[\t ]+LTTNG_UST_MINOR_VERSION[\t ]+[0-9]+[\t ]*$") + file(STRINGS "${lttngust_version_file}" lttngust_version_patch_string + REGEX "^[\t ]*#define[\t ]+LTTNG_UST_PATCHLEVEL_VERSION[\t ]+[0-9]+[\t ]*$") + string(REGEX REPLACE ".*([0-9]+).*" "\\1" + lttngust_v_major "${lttngust_version_major_string}") + string(REGEX REPLACE ".*([0-9]+).*" "\\1" + lttngust_v_minor "${lttngust_version_minor_string}") + string(REGEX REPLACE ".*([0-9]+).*" "\\1" + lttngust_v_patch "${lttngust_version_patch_string}") + set(LTTNGUST_VERSION_STRING + "${lttngust_v_major}.${lttngust_v_minor}.${lttngust_v_patch}") + unset(lttngust_version_major_string) + unset(lttngust_version_minor_string) + unset(lttngust_version_patch_string) + unset(lttngust_v_major) + unset(lttngust_v_minor) + unset(lttngust_v_patch) + endif() + + unset(lttngust_version_file) +endif() + +# handle the QUIETLY and REQUIRED arguments and set LTTNGUST_FOUND to +# TRUE if all listed variables are TRUE +include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) +FIND_PACKAGE_HANDLE_STANDARD_ARGS(LTTngUST FOUND_VAR LTTNGUST_FOUND + REQUIRED_VARS LTTNGUST_LIBRARIES + LTTNGUST_INCLUDE_DIR + VERSION_VAR LTTNGUST_VERSION_STRING) +mark_as_advanced(LTTNGUST_LIBRARIES LTTNGUST_INCLUDE_DIR) -- 2.7.1 From ashley at awhetter.co.uk Sun Feb 21 10:16:00 2016 From: ashley at awhetter.co.uk (Ashley Whetter) Date: Sun, 21 Feb 2016 15:16:00 +0000 Subject: [cmake-developers] [PATCH v2] Now prints warning when --build is not honored In-Reply-To: <1453068570-14837-1-git-send-email-ashley@awhetter.co.uk> References: <1453068570-14837-1-git-send-email-ashley@awhetter.co.uk> Message-ID: <1456067760-15989-1-git-send-email-ashley@awhetter.co.uk> --- In this version of the patch I've changed the message printed to give more information on how '--build' should be used. Source/cmake.cxx | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Source/cmake.cxx b/Source/cmake.cxx index 8f6b952..95948d5 100644 --- a/Source/cmake.cxx +++ b/Source/cmake.cxx @@ -798,6 +798,12 @@ void cmake::SetArgs(const std::vector& args, this->SetGlobalGenerator(gen); } } + else if (arg.find("--build", 0) == 0) + { + cmSystemTools::Message("Ignoring option '--build' " + "because it is meant to be used only " + "to drive an already-generated project build system." , "Warning"); + } // no option assume it is the path to the source else { -- 2.7.1 From ashley at awhetter.co.uk Sun Feb 21 10:17:07 2016 From: ashley at awhetter.co.uk (Ashley Whetter) Date: Sun, 21 Feb 2016 15:17:07 +0000 Subject: [cmake-developers] [PATCH] Fixed some documentation typos Message-ID: <1456067827-16076-1-git-send-email-ashley@awhetter.co.uk> --- Help/manual/cmake-packages.7.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Help/manual/cmake-packages.7.rst b/Help/manual/cmake-packages.7.rst index b9073a5..aebc5d9 100644 --- a/Help/manual/cmake-packages.7.rst +++ b/Help/manual/cmake-packages.7.rst @@ -89,7 +89,7 @@ a package is to set the ``CMAKE_PREFIX_PATH`` cache variable. Config-file packages are provided by upstream vendors as part of development packages, that is, they belong with the header files and any other files -provided to assist downsteams in using the package. +provided to assist downstreams in using the package. A set of variables which provide package status information are also set automatically when using a config-file package. The ``_FOUND`` @@ -352,7 +352,7 @@ version-specific variables ``_VERSION``, ``_VERSION_MAJOR``, used to export the targets in the ``ClimbingStatsTargets`` export-set, defined previously by the :command:`install(TARGETS)` command. This command generates the ``ClimbingStatsTargets.cmake`` file to contain :prop_tgt:`IMPORTED` -targets, suitable for use by downsteams and arranges to install it to +targets, suitable for use by downstreams and arranges to install it to ``lib/cmake/ClimbingStats``. The generated ``ClimbingStatsConfigVersion.cmake`` and a ``cmake/ClimbingStatsConfig.cmake`` are installed to the same location, completing the package. @@ -383,7 +383,7 @@ In this case, when using :command:`install(TARGETS)` the ``INCLUDES DESTINATION` was specified. This causes the ``IMPORTED`` targets to have their :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES` populated with the ``include`` directory in the :variable:`CMAKE_INSTALL_PREFIX`. When the ``IMPORTED`` -target is used by downsteam, it automatically consumes the entries from +target is used by downstream, it automatically consumes the entries from that property. Creating a Package Configuration File @@ -412,7 +412,7 @@ This can also be extended to cover dependencies: target_link_libraries(ClimbingStats PUBLIC Stats::Types) As the ``Stats::Types`` target is a ``PUBLIC`` dependency of ``ClimbingStats``, -downsteams must also find the ``Stats`` package and link to the ``Stats::Types`` +downstreams must also find the ``Stats`` package and link to the ``Stats::Types`` library. The ``Stats`` package should be found in the ``ClimbingStatsConfig.cmake`` file to ensure this. The ``find_dependency`` macro from the :module:`CMakeFindDependencyMacro` helps with this by propagating @@ -464,7 +464,7 @@ Creating a Package Configuration File for the Build Tree The :command:`export(EXPORT)` command creates an :prop_tgt:`IMPORTED` targets definition file which is specific to the build-tree, and is not relocatable. -This can similiarly be used with a suitable package configuration file and +This can similarly be used with a suitable package configuration file and package version file to define a package for the build tree which may be used without installation. Consumers of the build tree can simply ensure that the :variable:`CMAKE_PREFIX_PATH` contains the build directory, or set the -- 2.7.1 From gjasny at googlemail.com Sun Feb 21 10:39:55 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Sun, 21 Feb 2016 16:39:55 +0100 Subject: [cmake-developers] Patch: refactor XCode blocks writing function In-Reply-To: <627be2f9e0124d07ba240d0f9634d57c@BN1PR79MB007.MGDADSK.autodesk.com> References: <627be2f9e0124d07ba240d0f9634d57c@BN1PR79MB007.MGDADSK.autodesk.com> Message-ID: <56C9DA4B.6060700@googlemail.com> Hello Robert, On 19/02/16 20:12, Robert Goulet wrote: > I did this refactoring of the function that writes the XCode blocks in the project files, that adds support for any number of nested blocks. And it also makes the code easier to expand in the future. > > One of the areas that required this for us was adding support for XCode UI Testing (as opposed to non-UI testing), which required us to add the target ID in a nested way that wasn't supported with the previous code. I will send the XCode UI Testing patch separately. I will review this patch and push it into -next. One kind request: Could you please install the developer hooks locally so that you will get the same warnings and pre-commit errors like the cmake developers? As far as I remember you can set it up by calling Utilities/GitSetup/setup-hooks Thanks, Gregor From mantis at public.kitware.com Sun Feb 21 12:40:06 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 21 Feb 2016 12:40:06 -0500 Subject: [cmake-developers] [CMake 0015983]: Qt4Targets test fails to run twice in a row Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15983 ====================================================================== Reported By: Gregor Jasny Assigned To: ====================================================================== Project: CMake Issue ID: 15983 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-21 12:40 EST Last Modified: 2016-02-21 12:40 EST ====================================================================== Summary: Qt4Targets test fails to run twice in a row Description: When building CMake with the Xcode generator the Qt4Targets target test fails to run twice in a row. Once I purge the build directory and re-create it the first run succeeds again. Steps to Reproduce: 1. create separate cmake build directory and select the Xcode generator. 2. run "ctest -C Debug -R Qt4Targets --verbose" twice. Additional Information: 
ctest -C Debug -R Qt4Targets --verbose
UpdateCTestConfiguration  from
:/Users/jasny/src/cmake/_build_xcode/DartConfiguration.tcl
Parse Config file:/Users/jasny/src/cmake/_build_xcode/DartConfiguration.tcl
 Add coverage exclude regular expressions.
 Add coverage exclude: Kdevelop
 Add coverage exclude: /Source/(cm|kw)sys/
 Add coverage exclude: /CMakeFiles/CMakeTmp/
 Add coverage exclude: [A-Za-z]./[Qq]t/qt-.+-opensource-src
SetCTestConfiguration:CMakeCommand:/usr/local/Cellar/cmake/3.4.1/bin/cmake
UpdateCTestConfiguration  from
:/Users/jasny/src/cmake/_build_xcode/DartConfiguration.tcl
Parse Config file:/Users/jasny/src/cmake/_build_xcode/DartConfiguration.tcl
Test project /Users/jasny/src/cmake/_build_xcode
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
Checking test dependency graph end
test 140
    Start 140: Qt4Targets

140: Test command: /Users/jasny/src/cmake/_build_xcode/bin/Debug/ctest
"--build-and-test" "/Users/jasny/src/cmake/Tests/Qt4Targets"
"/Users/jasny/src/cmake/_build_xcode/Tests/Qt4Targets" "--build-generator"
"Xcode" "--build-project" "Qt4Targets" "--build-exe-dir"
"/Users/jasny/src/cmake/_build_xcode/Tests/Qt4Targets"
"--force-new-ctest-process" "--build-options"
"-DQT_QMAKE_EXECUTABLE:FILEPATH=/usr/local/bin/qmake" "--test-command"
"/Users/jasny/src/cmake/_build_xcode/bin/ctest" "-V"
140: Test timeout computed to be: 1500
140: Internal cmake changing into directory:
/Users/jasny/src/cmake/_build_xcode/Tests/Qt4Targets
140: Error: cmake execution failed
140: CMake Error at CMakeLists.txt:75 (message):
140:   Rebuild did not re-create moc file with -DADD_TARGET_DEF.  Before:
140:   2016038200331.  After: 2016038200331
140: Call Stack (most recent call first):
140:   CMakeLists.txt:79 (test_incremental)
140: 
140: 
140: Configuring
140: Configuring incomplete, errors occurred!
140: See also
"/Users/jasny/src/cmake/_build_xcode/Tests/Qt4Targets/CMakeFiles/CMakeOutput.log".
140: See also
"/Users/jasny/src/cmake/_build_xcode/Tests/Qt4Targets/CMakeFiles/CMakeError.log".
140: 
1/1 Test https://cmake.org/Bug/view.php?id=140: Qt4Targets
.......................***Failed    9.91 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   9.97 sec

The following tests FAILED:
	140 - Qt4Targets (Failed)
Errors while running CTest
====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-21 12:40 Gregor Jasny New Issue ====================================================================== From dimitar.yordanov at sap.com Mon Feb 22 05:16:58 2016 From: dimitar.yordanov at sap.com (Yordanov, Dimitar) Date: Mon, 22 Feb 2016 10:16:58 +0000 Subject: [cmake-developers] [PATCH] Additional regression tests for cmake_parse_arguments Message-ID: <5AA074723FDBE144A86F4BFBE1BD03FF999ECD@DEWDFEMB11B.global.corp.sap> Hi Brad, as requested please find attached some additional regression tests for the cmake_parse_arguments implementation. Best wishes Dimitar >From 6ccb1a19cb9bae38f98833402fb3d7c613d0501f Mon Sep 17 00:00:00 2001 From: Dimitar Yordanov Date: Mon, 22 Feb 2016 10:58:38 +0100 Subject: [PATCH] Additional regression tests for cmake_parse_arguments Dimitar Yordanov (1): cmake_parse_arguments: Additional regression tests .../RunCMake/cmake_parse_arguments/CornerCases.cmake | 20 ++++++++++++++++++++ .../cmake_parse_arguments/Initialization.cmake | 9 +++++++++ 2 files changed, 29 insertions(+) -- 2.3.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-cmake_parse_arguments-Additional-regression-tests.patch Type: application/octet-stream Size: 3093 bytes Desc: 0001-cmake_parse_arguments-Additional-regression-tests.patch URL: From jeanmichael.celerier at gmail.com Mon Feb 22 09:25:21 2016 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Mon, 22 Feb 2016 15:25:21 +0100 Subject: [cmake-developers] [Qt-creator] CMake daemon for user tools In-Reply-To: References: <56923C33.6030506@gmail.com> <56C4ED48.2000604@gmail.com> <29119808.49cmFxlnYG@tuxedo.neundorf.net> Message-ID: There is also https://www.cevelop.com/ which is an Eclipse derivative, they may be interested ? Best, Jean-Micha?l www.i-score.org On Fri, Feb 19, 2016 at 11:36 AM, Stephen Kelly wrote: > Alexander Neundorf wrote: > > > On Wednesday, February 17, 2016 22:59:36 Stephen Kelly wrote: > >> On 02/15/2016 07:24 PM, Tobias Hunger wrote: > >> > Hi Dominik, > >> > > >> > Am 15.02.2016 19:01 schrieb "Dominik Haumann" > >> > >> > > >> > >: > >> > > 1. Wouldn't it make sense you have a developer sprint ASAP for this? > >> > > >> > I'd be in, but I do not have the time to organize one. I could > >> > probably get a room in our office though (in Berlin). > >> > >> I'd be up for a sprint in Berlin too, but given the muted response so > >> far here, it's not clear who would want to join and what we could > >> achieve. > > > > just out of curiosity, did you get any feedback from anybody from > > Eclipse/CDT ? > > Nope. No response from there at all despite reaching out to them. > > > Or CodeBlocks maybe ? > > I didn't reach out to them, so no. > > Thanks, > > Steve. > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Goulet at autodesk.com Mon Feb 22 10:06:50 2016 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Mon, 22 Feb 2016 15:06:50 +0000 Subject: [cmake-developers] Patch: refactor XCode blocks writing function In-Reply-To: <56C9DA4B.6060700@googlemail.com> References: <627be2f9e0124d07ba240d0f9634d57c@BN1PR79MB007.MGDADSK.autodesk.com> <56C9DA4B.6060700@googlemail.com> Message-ID: Yes sure no problem I will install these hooks. Thanks! -----Original Message----- From: Gregor Jasny [mailto:gjasny at googlemail.com] Sent: Sunday, February 21, 2016 10:40 AM To: Robert Goulet ; cmake-developers at cmake.org Subject: Re: [cmake-developers] Patch: refactor XCode blocks writing function Hello Robert, On 19/02/16 20:12, Robert Goulet wrote: > I did this refactoring of the function that writes the XCode blocks in the project files, that adds support for any number of nested blocks. And it also makes the code easier to expand in the future. > > One of the areas that required this for us was adding support for XCode UI Testing (as opposed to non-UI testing), which required us to add the target ID in a nested way that wasn't supported with the previous code. I will send the XCode UI Testing patch separately. I will review this patch and push it into -next. One kind request: Could you please install the developer hooks locally so that you will get the same warnings and pre-commit errors like the cmake developers? As far as I remember you can set it up by calling Utilities/GitSetup/setup-hooks Thanks, Gregor From Fabian.Otto at rohde-schwarz.com Mon Feb 22 11:35:52 2016 From: Fabian.Otto at rohde-schwarz.com (Fabian.Otto at rohde-schwarz.com) Date: Mon, 22 Feb 2016 17:35:52 +0100 Subject: [cmake-developers] [PATCH] Add target property VS_CONFIGURATION_TYPE to Visual Studio 10 target generator Message-ID: Hi all, I implemented a small extension to the Visual Studio 10 target generator that I would like to share. The patch adds the target property VS_CONFIGURATION_TYPE. It allows to set an arbitrary value to the "ConfigurationType" property in the generated Visual Studio project file. By default, the generator fills in "DynamicLibrary", "StaticLibrary", "Application" or "Utility", depending on the target type. This is useful if you want to build a Windows Kernel Mode Driver. The Visual Studio property sheets that are part of the Windows Driver Kit 8/8.1/10 expect the value "Driver" in the "ConfigurationType" property. So by setting VS_CONFIGURATION_TYPE to "Driver", the generator fills that in instead of e.g. "DynamicLibrary". Please let me know if this change is acceptable. Best regards Fabian --- Help/manual/cmake-properties.7.rst | 1 + Help/prop_tgt/VS_CONFIGURATION_TYPE.rst | 10 ++++ Source/cmVisualStudio10TargetGenerator.cxx | 79 +++++++++++++++++------------- 3 files changed, 55 insertions(+), 35 deletions(-) create mode 100644 Help/prop_tgt/VS_CONFIGURATION_TYPE.rst diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst index a41d484..d6618fe 100644 --- a/Help/manual/cmake-properties.7.rst +++ b/Help/manual/cmake-properties.7.rst @@ -255,6 +255,7 @@ Properties on Targets /prop_tgt/TYPE /prop_tgt/VERSION /prop_tgt/VISIBILITY_INLINES_HIDDEN + /prop_tgt/VS_CONFIGURATION_TYPE /prop_tgt/VS_DESKTOP_EXTENSIONS_VERSION /prop_tgt/VS_DOTNET_REFERENCES /prop_tgt/VS_DOTNET_TARGET_FRAMEWORK_VERSION diff --git a/Help/prop_tgt/VS_CONFIGURATION_TYPE.rst b/Help/prop_tgt/VS_CONFIGURATION_TYPE.rst new file mode 100644 index 0000000..3aa87f1 --- /dev/null +++ b/Help/prop_tgt/VS_CONFIGURATION_TYPE.rst @@ -0,0 +1,10 @@ +VS_CONFIGURATION_TYPE +--------------------- + +Visual Studio project configuration type. + +Sets the "ConfigurationType" attribute for a generated Visual Studio project. +If this property is set, it overrides the default setting that is based on +the target type (e.g. "StaticLibrary", "Application", ...). + +Supported on Visual Studio 2010 and higher. diff --git a/Source/cmVisualStudio10TargetGenerator.cxx b/Source/cmVisualStudio10TargetGenerator.cxx index 09d4a90..796ad19 100644 --- a/Source/cmVisualStudio10TargetGenerator.cxx +++ b/Source/cmVisualStudio10TargetGenerator.cxx @@ -696,43 +696,52 @@ void cmVisualStudio10TargetGenerator::WriteProjectConfigurationValues() i->c_str(), 1, " Label=\"Configuration\"", "\n"); std::string configType = ""; - switch(this->GeneratorTarget->GetType()) - { - case cmState::SHARED_LIBRARY: - case cmState::MODULE_LIBRARY: - configType += "DynamicLibrary"; - break; - case cmState::OBJECT_LIBRARY: - case cmState::STATIC_LIBRARY: - configType += "StaticLibrary"; - break; - case cmState::EXECUTABLE: - if(this->NsightTegra && - !this->GeneratorTarget->GetPropertyAsBool("ANDROID_GUI")) - { - // Android executables are .so too. + const char* vsConfigurationType = + this->GeneratorTarget->GetProperty("VS_CONFIGURATION_TYPE"); + if(vsConfigurationType) + { + configType += cmVS10EscapeXML(vsConfigurationType); + } + else + { + switch(this->GeneratorTarget->GetType()) + { + case cmState::SHARED_LIBRARY: + case cmState::MODULE_LIBRARY: configType += "DynamicLibrary"; - } - else - { - configType += "Application"; - } - break; - case cmState::UTILITY: - case cmState::GLOBAL_TARGET: - if(this->NsightTegra) - { - // Tegra-Android platform does not understand "Utility". + break; + case cmState::OBJECT_LIBRARY: + case cmState::STATIC_LIBRARY: configType += "StaticLibrary"; - } - else - { - configType += "Utility"; - } - break; - case cmState::UNKNOWN_LIBRARY: - case cmState::INTERFACE_LIBRARY: - break; + break; + case cmState::EXECUTABLE: + if(this->NsightTegra && + !this->GeneratorTarget->GetPropertyAsBool("ANDROID_GUI")) + { + // Android executables are .so too. + configType += "DynamicLibrary"; + } + else + { + configType += "Application"; + } + break; + case cmState::UTILITY: + case cmState::GLOBAL_TARGET: + if(this->NsightTegra) + { + // Tegra-Android platform does not understand "Utility". + configType += "StaticLibrary"; + } + else + { + configType += "Utility"; + } + break; + case cmState::UNKNOWN_LIBRARY: + case cmState::INTERFACE_LIBRARY: + break; + } } configType += "\n"; this->WriteString(configType.c_str(), 2); -- 2.7.1.windows.2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Mon Feb 22 16:30:42 2016 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 22 Feb 2016 22:30:42 +0100 Subject: [cmake-developers] [Qt-creator] CMake daemon for user tools References: <56923C33.6030506@gmail.com> <56C4ED48.2000604@gmail.com> <29119808.49cmFxlnYG@tuxedo.neundorf.net> Message-ID: Jean-Micha?l Celerier wrote: > There is also https://www.cevelop.com/ which is an Eclipse derivative, > they may be interested ? I went all hipster reach-out.io and tweeted at them. :) From neundorf at kde.org Mon Feb 22 17:08:45 2016 From: neundorf at kde.org (Alexander Neundorf) Date: Mon, 22 Feb 2016 23:08:45 +0100 Subject: [cmake-developers] [Qt-creator] CMake daemon for user tools In-Reply-To: References: <56923C33.6030506@gmail.com> Message-ID: <1803235.hU278A2RS6@tuxedo.neundorf.net> On Monday, February 22, 2016 22:30:42 Stephen Kelly wrote: > Jean-Micha?l Celerier wrote: > > There is also https://www.cevelop.com/ which is an Eclipse derivative, > > they may be interested ? > > I went all hipster reach-out.io and tweeted at them. :) looks like that's an FP7-project, so I wouldn't be too sure about its future once the project funding ends... Alex From steveire at gmail.com Mon Feb 22 17:14:38 2016 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 22 Feb 2016 23:14:38 +0100 Subject: [cmake-developers] [Qt-creator] CMake daemon for user tools References: <56923C33.6030506@gmail.com> <1803235.hU278A2RS6@tuxedo.neundorf.net> Message-ID: Alexander Neundorf wrote: > On Monday, February 22, 2016 22:30:42 Stephen Kelly wrote: >> Jean-Micha?l Celerier wrote: >> > There is also https://www.cevelop.com/ which is an Eclipse derivative, >> > they may be interested ? >> >> I went all hipster reach-out.io and tweeted at them. :) > > looks like that's an FP7-project, so I wouldn't be too sure about its > future once the project funding ends... If anyone can get me a working java environment and a way to asynchronously write stdin/stdout on long-running processes, I can write a plugin for eclipse which would be independent of cevelop afaict. Do you know enough java to help get started on that? Thanks, Steve From tobias.hunger at gmail.com Mon Feb 22 17:51:08 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Mon, 22 Feb 2016 23:51:08 +0100 Subject: [cmake-developers] [Qt-creator] CMake daemon for user tools In-Reply-To: References: <56923C33.6030506@gmail.com> <1803235.hU278A2RS6@tuxedo.neundorf.net> Message-ID: Am 22.02.2016 23:14 schrieb "Stephen Kelly" : > If anyone can get me a working java environment and a way to asynchronously > write stdin/stdout on long-running processes, I can write a plugin for > eclipse which would be independent of cevelop afaict. > > Do you know enough java to help get started on that? Can we please focus on getting this ready for inclusion into CMake first? And fill in the missing pieces while doing that (e.g. find compile flags)? It has so much potential, but right now it can not provide all the information needed to feed a serious C++ code model! IMHO that needs to be fixed first, before running of and plastering the world with more demos. The ones you have are impressive enough already, now we need something that is actually useful for real use. Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh.collins242 at gmail.com Tue Feb 23 01:46:04 2016 From: josh.collins242 at gmail.com (Joshua Collins) Date: Tue, 23 Feb 2016 06:46:04 +0000 Subject: [cmake-developers] Qt4 external binary resources Message-ID: Hi, I have an issue with using Qt 4 compiled resources on MSVC 2015 due to the "compiler running out of heap space". I have decided to instead use external binary resources on Windows builds as this seems to be the simplest fix. I am able to generate a binary resource with the following commands: QT4_ADD_RESOURCES(RCC "main.qrc" OPTIONS "-binary") ADD_EXECUTABLE(target source ${RCC}) The problem is that the QT4_ADD_RESOURCES will *always* create a cxx file. This means that the add_executable command will attempt to compile the binary source file. The behaviour I would like to see would be to name the file "qrc_main.rcc" if we are producing binary resources. As this is not a C++ file extension, add_executable will not try to compile this generated file. I am making the assumption that it is required to add RCC to the executable to force it to be generated automatically. If there is a simple solution to my setup that I have overlooked, please let me know. I have thought of 2 ways to fix the issue and wanted to post this to the mailing list for feedback before submitting a patch: 1. We can allow the user to pass a TARGET parameter to the macro. Currently the rcc_target parameter of the macro is unused. This would be used to generate a user specified filename, which in this case could be "myfile.rcc". The issue with this approach is that "-name ${outfilename} " is passed to rcc and I am unsure of the implications of this parameter. A generic target name may not fit the inherent naming convention in the current implementation. 2. We can scan for the "-binary" option and automatically change the file extension to rcc in this case. My concern here is that it is a bit "magic". I would appreciate feedback on these approaches, or suggestions for easier ways to solve the problem. Best Regards, Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From aklitzing at gmail.com Tue Feb 23 04:03:45 2016 From: aklitzing at gmail.com (A. Klitzing) Date: Tue, 23 Feb 2016 10:03:45 +0100 Subject: [cmake-developers] Qt4 external binary resources In-Reply-To: References: Message-ID: Hi there, I already fixed that problem with "qt5_add_binary_resources" in Qt 5.5. Maybe you want to port that code to Qt4. :-) http://code.qt.io/cgit/qt/qtbase.git/commit/?id=2af127763194c13c3f7ccce507c94eb2de6dbefe http://code.qt.io/cgit/qt/qtbase.git/commit/?id=cacae82a7000041b5347e4cfa3a7b46e064260b7 http://code.qt.io/cgit/qt/qtdoc.git/commit/?id=e2e70692911f32cfea38269bd18603079277e2c9 Best regards Andr? Klitzing From mantis at public.kitware.com Tue Feb 23 09:00:18 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 23 Feb 2016 11:00:18 -0300 Subject: [cmake-developers] [CMake 0015984]: "Eclipse CDT4 - Unix Makefiles" does not include subprojects source dir in the Eclipse projects Message-ID: <77b38d5fca07cb9b3b12845e4dc4d945@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15984 ====================================================================== Reported By: Thiago Assigned To: ====================================================================== Project: CMake Issue ID: 15984 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-23 11:00 BRT Last Modified: 2016-02-23 11:00 BRT ====================================================================== Summary: "Eclipse CDT4 - Unix Makefiles" does not include subprojects source dir in the Eclipse projects Description: Assuming there is a project called "app1" that adds another sibling project "lib1" on its CMakeLists.txt. When calling cmake -G "Eclipse CDT4 - Unix Makefiles" to generate Eclipse projects, not only app1 project is created as the main project, but both projects are added as virtual [Subprojects], as expected. That is great, however, only the source code of app1 is indexed by Eclipse. In order to indexing work for lib1 too, we need to manually right click the project and go to the "C/C++ Project paths" and add "[Subprojects]" or "[Subprojects]/lib1" in the Source list. That action would result in a tag being added to the .cproject: is added to It would be great if cmake added CMAKE_SOURCE_DIR of all subprojects to the parent project's .cproject during eclipse project generation Steps to Reproduce: ---------------------------------------------------------------------- App1's CMakeLists.txt ---------------------------------------------------------------------- cmake_minimum_required(VERSION 3.0) project(MyApp1) set(CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT TRUE) add_subdirectory("../lib1" "${CMAKE_CURRENT_BINARY_DIR}/lib1") add_executable(app1 src/main.cpp) target_link_libraries(app1 L1) ---------------------------------------------------------------------- Lib1's CMakeLists.txt ---------------------------------------------------------------------- cmake_minimum_required(VERSION 3.0) project(MyLib1) set(CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT TRUE) add_library(L1 SHARED src/main.cpp) target_include_directories(L1 PUBLIC $ $ ) Go to an out-of-source dir and run: cmake -G"Eclipse CDT4 - Unix Makefiles" -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE ../../app3/ Import the project on eclipse Try to see a lib1's function definition from app1 source code. Only the lib1's header will be found by eclipse. lib1's function definition is not in the indexing databse and will not be found Additional Information: It is a great addition to https://cmake.org/Bug/view.php?id=12579 as well ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-23 11:00 Thiago New Issue ====================================================================== From roman.wueger at gmx.at Wed Feb 24 06:51:24 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 24 Feb 2016 12:51:24 +0100 Subject: [cmake-developers] Unit Test App (Universal Windows) Message-ID: Hello, does anyone successfully created a unit test for Windows 10 Universal? My current situation is that the unit tests are running if building for desktop. But if I try to build for winrt/universal/Windows 10 store then the tests aren't executed. When I create a unit test for Windows universal under visual studio then the tests are working. Thanks in advance Best regards Roman From brad.king at kitware.com Wed Feb 24 11:08:15 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Feb 2016 11:08:15 -0500 Subject: [cmake-developers] [PATCH] Additional regression tests for cmake_parse_arguments In-Reply-To: <5AA074723FDBE144A86F4BFBE1BD03FF999ECD@DEWDFEMB11B.global.corp.sap> References: <5AA074723FDBE144A86F4BFBE1BD03FF999ECD@DEWDFEMB11B.global.corp.sap> Message-ID: <56CDD56F.1010906@kitware.com> On 02/22/2016 05:16 AM, Yordanov, Dimitar wrote: > as requested please find attached some additional regression tests for > the cmake_parse_arguments implementation. Great, thanks! Applied: cmake_parse_arguments: Additional regression tests https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=43025124 -Brad From brad.king at kitware.com Wed Feb 24 11:08:24 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Feb 2016 11:08:24 -0500 Subject: [cmake-developers] [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5 In-Reply-To: <6AFB6565-459A-4917-B436-E30995CE86A1@arm.com> References: <56BA1B94.5000407@kitware.com> <56BB4D3E.6000408@kitware.com> <56C484C6.7040100@kitware.com> <6AFB6565-459A-4917-B436-E30995CE86A1@arm.com> Message-ID: <56CDD578.9060709@kitware.com> On 02/17/2016 01:46 PM, James Crosby wrote: >> Perhaps we could have a setting in a toolchain file like [snip] >> that tells CMake to use add_library(STATIC) instead of add_executable() >> in its generated try_compile projects. That would avoid linking through >> the toolchain. > > OK this makes a lot more sense to me now (I should have looked at the code > first ;). It seems like the option to link a static library would have all the > benefits of getting information out of the compiler itself (instead of > duplicating it in toolchain files), without having to be able to produce a > linkable executable. Here is a change implementing this approach: try_compile: Add option to control type of target https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7f1bd9fe One should be able to simply add set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) to the toolchain file. Then CMakeForceCompiler should not be needed anymore. Please try it out. Thanks, -Brad From brad.king at kitware.com Wed Feb 24 11:08:46 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Feb 2016 11:08:46 -0500 Subject: [cmake-developers] [PATCH] Fixed some documentation typos In-Reply-To: <1456067827-16076-1-git-send-email-ashley@awhetter.co.uk> References: <1456067827-16076-1-git-send-email-ashley@awhetter.co.uk> Message-ID: <56CDD58E.2080005@kitware.com> On 02/21/2016 10:17 AM, Ashley Whetter wrote: > --- > Help/manual/cmake-packages.7.rst | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) Thanks, applied: Help: Fix typos in cmake-packages.7 manual https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=33507e2a -Brad From brad.king at kitware.com Wed Feb 24 11:08:53 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Feb 2016 11:08:53 -0500 Subject: [cmake-developers] [PATCH v2] Now prints warning when --build is not honored In-Reply-To: <1456067760-15989-1-git-send-email-ashley@awhetter.co.uk> References: <1453068570-14837-1-git-send-email-ashley@awhetter.co.uk> <1456067760-15989-1-git-send-email-ashley@awhetter.co.uk> Message-ID: <56CDD595.9050503@kitware.com> On 02/21/2016 10:16 AM, Ashley Whetter wrote: > In this version of the patch I've changed the message printed to give more > information on how '--build' should be used. What command line are you using to test this locally? Please also add a case to Tests/RunCMake/CommandLine for this. Thanks, -Brad From brad.king at kitware.com Wed Feb 24 11:09:20 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 24 Feb 2016 11:09:20 -0500 Subject: [cmake-developers] [PATCH] Add target property VS_CONFIGURATION_TYPE to Visual Studio 10 target generator In-Reply-To: References: Message-ID: <56CDD5B0.8020704@kitware.com> On 02/22/2016 11:35 AM, Fabian.Otto at rohde-schwarz.com wrote: > The patch adds the target property VS_CONFIGURATION_TYPE. It allows to > set an arbitrary value to the "ConfigurationType" property > > This is useful if you want to build a Windows Kernel Mode Driver. This looks okay to me. Please extend the test suite to cover this feature. So far all VS features that we test have effects on the generation that we can test explicitly. In this case it looks like we might not be able to test actually building such a project. For that, take a look at these test directories: Tests/RunCMake/SolutionGlobalSections Tests/RunCMake/XcodeProject It tests running CMake and then parses the actual project file content to check that it is as expected. A similar test could be added for VS .vcxproj content testing and used to cover this feature. Thanks, -Brad From mantis at public.kitware.com Wed Feb 24 11:24:10 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 24 Feb 2016 11:24:10 -0500 Subject: [cmake-developers] [CMake 0015986]: Visual Studio 2015 does not work with v120 toolset Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15986 ====================================================================== Reported By: Gregor Jasny Assigned To: ====================================================================== Project: CMake Issue ID: 15986 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2016-02-24 11:24 EST Last Modified: 2016-02-24 11:24 EST ====================================================================== Summary: Visual Studio 2015 does not work with v120 toolset Description: Hello, today I tried to use Visual Studio 2015 to build with the VS2013 (v120) toolset. Unfortunately I get the following error: -- The C compiler identification is MSVC 18.0.40629.0 -- The CXX compiler identification is MSVC 18.0.40629.0 -- Check for working C compiler using: Visual Studio 14 2015 -- Check for working C compiler using: Visual Studio 14 2015 -- broken CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.5/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/cl.exe" is not able to compile a simple test program. It properly works in the "same" toolchain pairing: -G "Visual Studio 12 2013" -T v120 -G "Visual Studio 14 2015" -T v140 Thanks, Gregor Steps to Reproduce: CMakeLists.txt containing just: project(VS2015Test C CXX) Configure: "c:\Program Files (x86)\CMake\bin\cmake.exe" -G "Visual Studio 14 2015" -T v120 .. Additional Information: C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(639,9): error MSB4030: "Debug" is an invalid value for the "GenerateDebugInformation" parameter of the "Link" task. The "GenerateDebugInformation" parameter is of type "System.Boolean". [C:\Users\gregorj\devtrees\vs2015test\_build\CMakeFiles\CMakeTmp\cmTC_05d1a.vcxproj] ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-24 11:24 Gregor Jasny New Issue 2016-02-24 11:24 Gregor Jasny File Added: CMakeError.log ====================================================================== From rleigh at codelibre.net Wed Feb 24 17:49:57 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Wed, 24 Feb 2016 22:49:57 +0000 Subject: [cmake-developers] CMakeFindDependencyMacro limitations In-Reply-To: References: <566DB6CA.1060801@codelibre.net> <5679B19A.80106@codelibre.net> Message-ID: <56CE3395.2000004@codelibre.net> On 24/12/2015 12:07, Stephen Kelly wrote: > Roger Leigh wrote: > >> On 21/12/2015 15:07, Stephen Kelly wrote: >>> Roger Leigh wrote: >>>> I can understand why REQUIRED and related >>>> arguments are omitted--that is why find_dependency exists--but I'd quite >>>> like to be able to specify COMPONENTS where needed e.g. with FindBoost, >>>> and this is not currently possible. >>> >>> I don't remember whether this was discussed when designing >>> find_dependency. Perhaps COMPONENTS could be added to the macro now. >> >> Currently, for my own needs, COMPONENTS is the single missing piece. If >> it would be possible to add this, it would certainly be very useful. >> >> I'd be happy to provide a patch for COMPONENTS if you like. > > I think the reason that the macro does not support COMPONENTS is that I > don't understand how COMPONENTS is supposed to work. For example: > > find_package(Qt5 COMPONENTS Widgets) > # Is Qt5_FOUND set to true or false? > find_package(Qt5 COMPONENTS Quick) > # ... what about now? > > What does _FOUND ever mean if the find_package is called multiple > times with different components? Does it mean anything? I would think that it would mean whether the last call succeeded or failed for the requested components at that time. It wouldn't have any greater or more permanent meaning. To the best of my knowledge, that's what the status quo is for find_package. > Should CMake disallow multiple use of find_package with the same package and > with different components? > If user code has > > find_package(Qt5 COMPONENTS Widgets) > find_package(FooBar REQUIRED) > > and FooBarConfig.cmake has > > find_dependency(Qt5 COMPONENTS Quick) > > then the if(Qt5_FOUND) in the macro will mean it will not try to find the > Quick component. > > So, there may be a need to establish a convention such as > > __FOUND > > and check that for each component in the macro. Right now, it's certainly possible for this to happen. I'm seeing this myself with multiple packages (or individual components' config scripts) requiring different sets of Boost components. Each invokes find_dependency with its own needed set of components. > You would also need to think through everything and find out whether that is > really a full solution. I haven't thought more deeply about it than the > above. > > Note that the above example with Qt 5 can not currently happen in practice > because the find_dependency macro does not support COMPONENTS, so config > files must instead use > > find_dependency(Qt5Quick) > > if they want to use the macro currently. This is a good thing. > > So, I would like to know if > > * adding COMPONENTS support to the find_dependency macro is the right thing > to do > * or if the right thing to do is to move away from support for COMPONENTS > generally because of its messy semantics > * or if find_package should change to not support multiple calls for the > same package. > > I really don't know the answer - I think someone needs to do deep thinking > about it. > > I would prefer the macro not be changed before that deep thinking about > COMPONENTS generally is done. I've attached a patch for a very simple modification to find_dependency. I'm not proposing that it be merged, it's just a suggestion for further discussion. I've tested it with my own packages with multiple find_dependency(Boost COMPONENTS ...) calls. Some rationale and thoughts follow: Regarding the messy semantics of find_package, I agree it's not ideal. However, I find the differing behaviour of find_dependency and find_package even less so. Ideally I should be able to call both multiple times, or neither. While as you mentioned for Qt5, it's possible to work around this by calling find_dependency for each component by hand, but that's not possible for all packages. Boost for example does not work this way, making this a major blocker to using find_dependency with Boost. I'm basically blocked by this right now, and the patch here removes the single call restriction and passes through COMPONENTS, making it work. That would at the very least make things consistent and functional. I don't think it's in general going to be possible to avoid multiple calls. Complex projects including or depending upon other projects are going to do this inevitably, and they may have differing version requirements as well as different sets of components. And it's already in established use. I don't think for find_dependency that returning immediately if ${dep}_FOUND is true is correct behaviour--it skips the version check, and I think it should be calling find_package to do this check under all circumstances. I think it's trading correctness for speed, but I really would prefer to have the version check performed correctly every time. Regarding having __FOUND, I think this would be useful irrespective of any find_dependency changes. And coupled with the above patch, find_dependency could be extended to return immediately if the version check is satisfied *and* all the requested components are found (if specified). Kind regards, Roger -------------- next part -------------- >From c329228dca2b44d480d6fa889bff7ec24c77ecc8 Mon Sep 17 00:00:00 2001 From: Roger Leigh Date: Wed, 24 Feb 2016 22:11:14 +0000 Subject: [PATCH] find_dependency: Allow use of the find_package COMPONENTS option - Parse the COMPONENTS option with cmake_parse_arguments after the optional and EXACT arguments are parsed. This was done so that additional options could be added in the future. - Pass through the COMPONENTS to find_package - Drop the "if (NOT ${dep}_FOUND)" check. This prevented find_dependency from being invoked multiple times. For example, different Config.cmake scripts may call find_dependency(Boost) with different sets of required components. - Update documentation. EXACT is not a forwarded parameter. COMPONENTS is allowed. Minor markup enhancements. --- Modules/CMakeFindDependencyMacro.cmake | 142 +++++++++++++++++++++------------ 1 file changed, 90 insertions(+), 52 deletions(-) diff --git a/Modules/CMakeFindDependencyMacro.cmake b/Modules/CMakeFindDependencyMacro.cmake index 73efaae..898755b 100644 --- a/Modules/CMakeFindDependencyMacro.cmake +++ b/Modules/CMakeFindDependencyMacro.cmake @@ -4,18 +4,26 @@ # # :: # -# find_dependency( [ [EXACT]]) +# find_dependency( [ [EXACT]] [COMPONENTS components...]) # # -# ``find_dependency()`` wraps a :command:`find_package` call for a package -# dependency. It is designed to be used in a Config.cmake file, and it -# forwards the correct parameters for EXACT, QUIET and REQUIRED which were -# passed to the original :command:`find_package` call. It also sets an -# informative diagnostic message if the dependency could not be found. +# ``find_dependency()`` wraps a :command:`find_package` call for a +# package dependency. It is designed to be used in a +# :file:`Config.cmake` file, and it forwards the correct +# parameters for QUIET and REQUIRED which were passed to the original +# :command:`find_package` call. It also sets an informative +# diagnostic message if the dependency could not be found. +# +# The allowed arguments are a subset of the :command:`find_package` +# arguments. ```` is the name of the dependency (package) to +# find. The package version ```` (and its ``EXACT`` option), +# and the ``COMPONENTS`` component list are forwarded to +# :command:`find_package` unmodified. # #============================================================================= # Copyright 2013 Stephen Kelly +# Copyright 2016 Roger Leigh # # Distributed under the OSI-approved BSD License (the "License"); # see accompanying file Copyright.txt for details. @@ -27,59 +35,89 @@ # (To distribute this file outside of CMake, substitute the full # License text for the above reference.) +include(CMakeParseArguments) + macro(find_dependency dep) - if (NOT ${dep}_FOUND) - set(cmake_fd_version) - if (${ARGC} GREATER 1) - if ("${ARGV1}" STREQUAL "") - message(FATAL_ERROR "Invalid arguments to find_dependency. VERSION is empty") - endif() - if ("${ARGV1}" STREQUAL EXACT) - message(FATAL_ERROR "Invalid arguments to find_dependency. EXACT may only be specified if a VERSION is specified") - endif() - set(cmake_fd_version ${ARGV1}) - endif() - set(cmake_fd_exact_arg) - if(${ARGC} GREATER 2) - if (NOT "${ARGV2}" STREQUAL EXACT) - message(FATAL_ERROR "Invalid arguments to find_dependency") - endif() - set(cmake_fd_exact_arg EXACT) - endif() - if(${ARGC} GREATER 3) - message(FATAL_ERROR "Invalid arguments to find_dependency") + set(options) + set(oneValueArgs) + set(multiValueArgs COMPONENTS) + set(cmake_fd_option_names ${options} ${oneValueArgs} ${multiValueArgs}) + set(cmake_fd_args ${ARGN}) + + set(cmake_fd_version) + if (${ARGC} GREATER 1) + if ("${ARGV1}" STREQUAL "") + message(FATAL_ERROR "Invalid arguments to find_dependency. VERSION is empty") endif() - set(cmake_fd_quiet_arg) - if(${CMAKE_FIND_PACKAGE_NAME}_FIND_QUIETLY) - set(cmake_fd_quiet_arg QUIET) + if ("${ARGV1}" STREQUAL EXACT) + message(FATAL_ERROR "Invalid arguments to find_dependency. EXACT may only be specified if a VERSION is specified") endif() - set(cmake_fd_required_arg) - if(${CMAKE_FIND_PACKAGE_NAME}_FIND_REQUIRED) - set(cmake_fd_required_arg REQUIRED) + list(FIND cmake_fd_option_names ${ARGV1} cmake_fd_option_found) + if (cmake_fd_option_found EQUAL -1) + set(cmake_fd_version ${ARGV1}) + # Pop version + list(REMOVE_AT cmake_fd_args 0) + if (${ARGC} GREATER 2) + if("${ARGV2}" STREQUAL "EXACT") + # Pop EXACT + set(cmake_fd_exact_arg "EXACT") + list(REMOVE_AT CMAKE_FD_ARGS 0) + else() + set(cmake_fd_exact_arg) + endif() + endif() endif() + set(cmake_fd_option_found) + endif() - get_property(cmake_fd_alreadyTransitive GLOBAL PROPERTY - _CMAKE_${dep}_TRANSITIVE_DEPENDENCY - ) + # Parse remaining args (if any) + cmake_parse_arguments(cmake_fd "${options}" "${oneValueArgs}" "${multiValueArgs}" ${cmake_fd_args}) - find_package(${dep} ${cmake_fd_version} - ${cmake_fd_exact_arg} - ${cmake_fd_quiet_arg} - ${cmake_fd_required_arg} - ) + if(cmake_fd_UNPARSED_ARGUMENTS) + message(FATAL_ERROR "Unknown keywords given to FIND_DEPENDENCY(): \"${cmake_fd_UNPARSED_ARGUMENTS}\"") + endif() - if(NOT DEFINED cmake_fd_alreadyTransitive OR cmake_fd_alreadyTransitive) - set_property(GLOBAL PROPERTY _CMAKE_${dep}_TRANSITIVE_DEPENDENCY TRUE) - endif() + set(cmake_fd_quiet_arg) + if(${CMAKE_FIND_PACKAGE_NAME}_FIND_QUIETLY) + set(cmake_fd_quiet_arg QUIET) + endif() + set(cmake_fd_required_arg) + if(${CMAKE_FIND_PACKAGE_NAME}_FIND_REQUIRED) + set(cmake_fd_required_arg REQUIRED) + endif() + if(cmake_fd_COMPONENTS) + list(INSERT cmake_fd_COMPONENTS 0 COMPONENTS) + endif() - if (NOT ${dep}_FOUND) - set(${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE "${CMAKE_FIND_PACKAGE_NAME} could not be found because dependency ${dep} could not be found.") - set(${CMAKE_FIND_PACKAGE_NAME}_FOUND False) - return() - endif() - set(cmake_fd_version) - set(cmake_fd_required_arg) - set(cmake_fd_quiet_arg) - set(cmake_fd_exact_arg) + get_property(cmake_fd_alreadyTransitive GLOBAL PROPERTY + _CMAKE_${dep}_TRANSITIVE_DEPENDENCY + ) + + find_package(${dep} ${cmake_fd_version} + ${cmake_fd_exact_arg} + ${cmake_fd_quiet_arg} + ${cmake_fd_required_arg} + ${cmake_fd_COMPONENTS} + ) + + if(NOT DEFINED cmake_fd_alreadyTransitive OR cmake_fd_alreadyTransitive) + set_property(GLOBAL PROPERTY _CMAKE_${dep}_TRANSITIVE_DEPENDENCY TRUE) + endif() + + if (NOT ${dep}_FOUND) + set(${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE "${CMAKE_FIND_PACKAGE_NAME} could not be found because dependency ${dep} could not be found.") + set(${CMAKE_FIND_PACKAGE_NAME}_FOUND False) + return() endif() + + set(cmake_fd_version) + set(cmake_fd_required_arg) + set(cmake_fd_quiet_arg) + set(cmake_fd_exact_arg) + set(cmake_fd_COMPONENTS) + set(options) + set(oneValueArgs) + set(multiValueArgs) + set(cmake_fd_option_names) + set(cmake_fd_args) endmacro() -- 2.7.2 From Gilles.Khouzam at microsoft.com Wed Feb 24 17:47:13 2016 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Wed, 24 Feb 2016 22:47:13 +0000 Subject: [cmake-developers] C# support ready for review In-Reply-To: <8c87213acb6d49ac8a64c5f8e2998114@DE013666.schaeffler.com> References: <903866b8ac604d15a1bfb1d3c8c7afe1@DE013666.schaeffler.com> <8c87213acb6d49ac8a64c5f8e2998114@DE013666.schaeffler.com> Message-ID: Hi Michael, I've had more time to try this, what is the reasoning to hardcode the default LangVersion to 3 in Modules\CMakeCSharpInformation.cmake? Can we remove it? I'm trying this on some projects of mine. From: Stuermer, Michael SP/HZA-ZSEP [mailto:michael.stuermer at schaeffler.com] Sent: Thursday, February 18, 2016 03:44 To: Gilles Khouzam ; CMake Developers Subject: RE: C# support ready for review Hi Gilles, you are right about the specific user path. I already fixed this in my github "csharp" branch. Sorry for the inconvenience. As for the discrepancies: I just found out that my TortoiseGitMerge tool was not configured correctly: changes in comments where ignored (which is not what I wanted). I'll go over the patch again and remove the changes that are irrelevant to the C# features. Thanks for the hint on using MSBuild detection. I currently use the msbuild version that is provided automatically by visual studio, so I do not need any real detection. I didn't dig too deep into MSBuild versions, .NET framework versions, what can be configured etc. The configuration possibilities and what would make sense especially for other developers as well is something that should be discussed. My main aim was to be able to work with C# and .NET in a similar way as Visual Studio provides it. I only started C# development during the last year, so many things concerning configuration etc. could probably be improved. I'll post a new version of the patch later (or tomorrow) with the mentioned changes. best regards, Michael From: Gilles Khouzam [mailto:Gilles.Khouzam at microsoft.com] Sent: Thursday, February 18, 2016 8:17 AM To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers Subject: RE: C# support ready for review Hi Michael, Great work, this looks really good. I have a few comments on the changes. 1. You should use the registry to find the install path for MSBuild, it should be in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild with the version that you're looking for. This also bring the question of do you want to be able to specify the version of MSBuild that is used or base it off the generator? 2. In CMakeTestCSharpCompiler, you seem to still have a reference to your specific user path (COPY_FILE "C:/Users/stuermic/git/cmake_build/x64_14/Tests/CSharp")) You seem to have some slight discrepancies between your code and the release as there are changes that seem to be either unnecessary or going backwards. I noticed a tegra comment that seemed out of place as well as a comment change going from 14 to 12 where 14 was accurate. I'll try to play with this next week and get projects running on it. ~Gilles From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Stuermer, Michael SP/HZA-ZSEP Sent: Wednesday, February 10, 2016 06:03 To: CMake Developers > Subject: [cmake-developers] C# support ready for review Native C# support is ready for review. I split the patch in two parts: part 1: Some preparational stuff that does not really change or enable anything. Documentation and Test files as well as the required CMake module is added. The changes to existing code are small, only few methods in existing classes are added/changed. Changes to existing code should be easy to review in this part part 2: This contains the main work. Almost everything takes place within cmVisualStudio10TargetGenerator. In addition to C# support three more target properties were introduced: * VS_USER_PROPS_CXX (allows use of custom .user.props MSBuild file in .vcxproj files) * VS_USER_PROPS_CSHARP (allows use of custom .user.props MSBuild file in .csproj files) * VS_DEBUGGER_WORKING_DIRECTORY (allows setting of debugger working directory in .vcxproj files) I tested the features using Visual Studio 2010-2015 in 32/64 bit and everything works on my machine so far. Please review/test/comment and give feedback what is necessary to get native C# support in upstream cmake. best regards, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gilles.Khouzam at microsoft.com Thu Feb 25 02:43:40 2016 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Thu, 25 Feb 2016 07:43:40 +0000 Subject: [cmake-developers] C# support ready for review In-Reply-To: References: <903866b8ac604d15a1bfb1d3c8c7afe1@DE013666.schaeffler.com> <8c87213acb6d49ac8a64c5f8e2998114@DE013666.schaeffler.com> Message-ID: Hi Michael, Things are looking really good, I've just converted one of my personal projects to using CMake in very little time. I've included a small patch for your CSharp implementation. The first change is to add support to specify C# 6.0 in the flag table. The second removes the exception handling tag and the precompiled header tags since they don't make sense for C#, as well as adding a space between the platform comparisons. The space is not necessary for the project, but is you make any change in the property page inside of VS, a new property group is created instead of modifying the existing one. While this would not be a typical CMake scenario, it might be better to stay consistent with how VS and MSBuild process the file. The next thing that I want to start looking at, is to make this work for Windows Phone and Windows Store apps, so that it can match the support that we have with C++ in this regards. From: Gilles Khouzam Sent: Wednesday, February 24, 2016 14:47 To: 'Stuermer, Michael SP/HZA-ZSEP' ; CMake Developers Subject: RE: C# support ready for review Hi Michael, I've had more time to try this, what is the reasoning to hardcode the default LangVersion to 3 in Modules\CMakeCSharpInformation.cmake? Can we remove it? I'm trying this on some projects of mine. From: Stuermer, Michael SP/HZA-ZSEP [mailto:michael.stuermer at schaeffler.com] Sent: Thursday, February 18, 2016 03:44 To: Gilles Khouzam >; CMake Developers > Subject: RE: C# support ready for review Hi Gilles, you are right about the specific user path. I already fixed this in my github "csharp" branch. Sorry for the inconvenience. As for the discrepancies: I just found out that my TortoiseGitMerge tool was not configured correctly: changes in comments where ignored (which is not what I wanted). I'll go over the patch again and remove the changes that are irrelevant to the C# features. Thanks for the hint on using MSBuild detection. I currently use the msbuild version that is provided automatically by visual studio, so I do not need any real detection. I didn't dig too deep into MSBuild versions, .NET framework versions, what can be configured etc. The configuration possibilities and what would make sense especially for other developers as well is something that should be discussed. My main aim was to be able to work with C# and .NET in a similar way as Visual Studio provides it. I only started C# development during the last year, so many things concerning configuration etc. could probably be improved. I'll post a new version of the patch later (or tomorrow) with the mentioned changes. best regards, Michael From: Gilles Khouzam [mailto:Gilles.Khouzam at microsoft.com] Sent: Thursday, February 18, 2016 8:17 AM To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers Subject: RE: C# support ready for review Hi Michael, Great work, this looks really good. I have a few comments on the changes. 1. You should use the registry to find the install path for MSBuild, it should be in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild with the version that you're looking for. This also bring the question of do you want to be able to specify the version of MSBuild that is used or base it off the generator? 2. In CMakeTestCSharpCompiler, you seem to still have a reference to your specific user path (COPY_FILE "C:/Users/stuermic/git/cmake_build/x64_14/Tests/CSharp")) You seem to have some slight discrepancies between your code and the release as there are changes that seem to be either unnecessary or going backwards. I noticed a tegra comment that seemed out of place as well as a comment change going from 14 to 12 where 14 was accurate. I'll try to play with this next week and get projects running on it. ~Gilles From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Stuermer, Michael SP/HZA-ZSEP Sent: Wednesday, February 10, 2016 06:03 To: CMake Developers > Subject: [cmake-developers] C# support ready for review Native C# support is ready for review. I split the patch in two parts: part 1: Some preparational stuff that does not really change or enable anything. Documentation and Test files as well as the required CMake module is added. The changes to existing code are small, only few methods in existing classes are added/changed. Changes to existing code should be easy to review in this part part 2: This contains the main work. Almost everything takes place within cmVisualStudio10TargetGenerator. In addition to C# support three more target properties were introduced: * VS_USER_PROPS_CXX (allows use of custom .user.props MSBuild file in .vcxproj files) * VS_USER_PROPS_CSHARP (allows use of custom .user.props MSBuild file in .csproj files) * VS_DEBUGGER_WORKING_DIRECTORY (allows setting of debugger working directory in .vcxproj files) I tested the features using Visual Studio 2010-2015 in 32/64 bit and everything works on my machine so far. Please review/test/comment and give feedback what is necessary to get native C# support in upstream cmake. best regards, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CSharp-Patch-Lang60-Formatting.patch Type: application/octet-stream Size: 3019 bytes Desc: 0001-CSharp-Patch-Lang60-Formatting.patch URL: From michael.stuermer at schaeffler.com Thu Feb 25 05:51:34 2016 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Thu, 25 Feb 2016 10:51:34 +0000 Subject: [cmake-developers] C# support ready for review In-Reply-To: References: <903866b8ac604d15a1bfb1d3c8c7afe1@DE013666.schaeffler.com> <8c87213acb6d49ac8a64c5f8e2998114@DE013666.schaeffler.com> Message-ID: <0d23d51ac03d47bc9eaea8ce6d50818b@DE013666.schaeffler.com> Hi Gilles, good to hear C# support is working not only for me and some people are actually interested in it :-). Thanks for the patch, I already added to my github. All the changes make perfectly sense for me. Let me explain a bit more about things like hardcoding LangVersion in the module scripts etc. (in short, there is no reason for hardcoding langversion 3): The current C# support was developed by plain trial-and-error. I started out copying the CXX compiler module scripts, finding out the relevant/necessary variables, trying to find reasonable values etc. By starting with a copy of the CXX scripts I am quite sure there are some leftovers that do not make sense there. To adapt everything for C# I started by looking at a existing .csproj file and changing the target generator until everything went as expected. Initial values like the flags in CMakeCSharpInformation.cmake where copied as is from my first simple reference .csproj files. Also the special handling of .xaml, .xaml.cs and .Designer.cs files with the tags was just introduced when I realized I need it somewhere in our new project. Putting it all together I just want to say that the current state of development leaves room for a lot of improvement and if something seems like it could be done better, this is most probably the case. I really only pushed it to a level where I feel it's working well enough for me and I can focus on my actual job. The part that probably needs most additional work is all the C# detection and configuration part in the module scripts. I got it all up and running so we can develop our C/C++/C# cross-platform software here, but it's still some steps away from a perfectly configurable solution where everyone could be happy. best regards, Michael From: Gilles Khouzam [mailto:Gilles.Khouzam at microsoft.com] Sent: Thursday, February 25, 2016 8:44 AM To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers Subject: RE: C# support ready for review Hi Michael, Things are looking really good, I've just converted one of my personal projects to using CMake in very little time. I've included a small patch for your CSharp implementation. The first change is to add support to specify C# 6.0 in the flag table. The second removes the exception handling tag and the precompiled header tags since they don't make sense for C#, as well as adding a space between the platform comparisons. The space is not necessary for the project, but is you make any change in the property page inside of VS, a new property group is created instead of modifying the existing one. While this would not be a typical CMake scenario, it might be better to stay consistent with how VS and MSBuild process the file. The next thing that I want to start looking at, is to make this work for Windows Phone and Windows Store apps, so that it can match the support that we have with C++ in this regards. From: Gilles Khouzam Sent: Wednesday, February 24, 2016 14:47 To: 'Stuermer, Michael SP/HZA-ZSEP' ; CMake Developers Subject: RE: C# support ready for review Hi Michael, I've had more time to try this, what is the reasoning to hardcode the default LangVersion to 3 in Modules\CMakeCSharpInformation.cmake? Can we remove it? I'm trying this on some projects of mine. From: Stuermer, Michael SP/HZA-ZSEP [mailto:michael.stuermer at schaeffler.com] Sent: Thursday, February 18, 2016 03:44 To: Gilles Khouzam ; CMake Developers Subject: RE: C# support ready for review Hi Gilles, you are right about the specific user path. I already fixed this in my github "csharp" branch. Sorry for the inconvenience. As for the discrepancies: I just found out that my TortoiseGitMerge tool was not configured correctly: changes in comments where ignored (which is not what I wanted). I'll go over the patch again and remove the changes that are irrelevant to the C# features. Thanks for the hint on using MSBuild detection. I currently use the msbuild version that is provided automatically by visual studio, so I do not need any real detection. I didn't dig too deep into MSBuild versions, .NET framework versions, what can be configured etc. The configuration possibilities and what would make sense especially for other developers as well is something that should be discussed. My main aim was to be able to work with C# and .NET in a similar way as Visual Studio provides it. I only started C# development during the last year, so many things concerning configuration etc. could probably be improved. I'll post a new version of the patch later (or tomorrow) with the mentioned changes. best regards, Michael From: Gilles Khouzam [mailto:Gilles.Khouzam at microsoft.com] Sent: Thursday, February 18, 2016 8:17 AM To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers Subject: RE: C# support ready for review Hi Michael, Great work, this looks really good. I have a few comments on the changes. 1. You should use the registry to find the install path for MSBuild, it should be in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild with the version that you're looking for. This also bring the question of do you want to be able to specify the version of MSBuild that is used or base it off the generator? 2. In CMakeTestCSharpCompiler, you seem to still have a reference to your specific user path (COPY_FILE "C:/Users/stuermic/git/cmake_build/x64_14/Tests/CSharp")) You seem to have some slight discrepancies between your code and the release as there are changes that seem to be either unnecessary or going backwards. I noticed a tegra comment that seemed out of place as well as a comment change going from 14 to 12 where 14 was accurate. I'll try to play with this next week and get projects running on it. ~Gilles From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Stuermer, Michael SP/HZA-ZSEP Sent: Wednesday, February 10, 2016 06:03 To: CMake Developers Subject: [cmake-developers] C# support ready for review Native C# support is ready for review. I split the patch in two parts: ? part 1: ? Some preparational stuff that does not really change or enable anything. Documentation and Test files as well as the required CMake module is added. The changes to existing code are small, only few methods in existing classes are added/changed. Changes to existing code should be easy to review in this part ? part 2: ? This contains the main work. Almost everything takes place within cmVisualStudio10TargetGenerator. ? ? In addition to C# support three more target properties were introduced: ? . VS_USER_PROPS_CXX (allows use of custom .user.props MSBuild file in .vcxproj files) . VS_USER_PROPS_CSHARP (allows use of custom .user.props MSBuild file in .csproj files) . VS_DEBUGGER_WORKING_DIRECTORY (allows setting of debugger working directory in .vcxproj files) ? I tested the features using Visual Studio 2010-2015 in 32/64 bit and everything works on my machine so far. ? Please review/test/comment and give feedback what is necessary to get native C# support in upstream cmake. ? best regards, Michael ? ? From mantis at public.kitware.com Thu Feb 25 09:06:10 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 25 Feb 2016 09:06:10 -0500 Subject: [cmake-developers] [CMake 0015987]: STATUS variable to FILE(DOWNLOAD) does not consider HASH mismatch failures Message-ID: <9ad2164bc36b323a8b60af43c5f20186@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15987 ====================================================================== Reported By: Tobias Hieta Assigned To: ====================================================================== Project: CMake Issue ID: 15987 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-25 09:06 EST Last Modified: 2016-02-25 09:06 EST ====================================================================== Summary: STATUS variable to FILE(DOWNLOAD) does not consider HASH mismatch failures Description: This threw me for a bit of a loop when working with our cmake lists that download dependencies. It seems like the STATUS variable to file(download) only records errors if they happen when downloading the file. If the has mismatches the STATUS variable will still be set to 0 and "No error" as the error string. The only thing that does happen is that it prints a error message. This makes it very hard to handle errors where the HASH is not correct since you can't use the status variable to abort the the processing like: file(DOWNLOAD STATUS DL_STATUS) if(NOT DL_STATUS EQUAL 0) message(FATAL_ERROR "Failed") endif() I would expect the STATUS variable to be set to "1;HASH MISMATCH" or something when the has mismatches. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-25 09:06 Tobias Hieta New Issue ====================================================================== From Fabian.Otto at rohde-schwarz.com Thu Feb 25 10:36:59 2016 From: Fabian.Otto at rohde-schwarz.com (Fabian.Otto at rohde-schwarz.com) Date: Thu, 25 Feb 2016 16:36:59 +0100 Subject: [cmake-developers] [PATCH] Add target property VS_CONFIGURATION_TYPE to Visual Studio 10 target generator In-Reply-To: <56CDD5B0.8020704@kitware.com> References: <56CDD5B0.8020704@kitware.com> Message-ID: Hi Brad, thanks for your feedback. I added a test for the feature. Best regards, Fabian --- Tests/RunCMake/CMakeLists.txt | 5 +++++ Tests/RunCMake/VS10Project/CMakeLists.txt | 3 +++ Tests/RunCMake/VS10Project/RunCMakeTest.cmake | 2 ++ .../VS10Project/VsConfigurationType-check.cmake | 24 ++++++++++++++++++++++ .../RunCMake/VS10Project/VsConfigurationType.cmake | 3 +++ Tests/RunCMake/VS10Project/foo.cpp | 1 + 6 files changed, 38 insertions(+) create mode 100644 Tests/RunCMake/VS10Project/CMakeLists.txt create mode 100644 Tests/RunCMake/VS10Project/RunCMakeTest.cmake create mode 100644 Tests/RunCMake/VS10Project/VsConfigurationType-check.cmake create mode 100644 Tests/RunCMake/VS10Project/VsConfigurationType.cmake create mode 100644 Tests/RunCMake/VS10Project/foo.cpp diff --git a/Tests/RunCMake/CMakeLists.txt b/Tests/RunCMake/CMakeLists.txt index 0a388c5..81df69f 100644 --- a/Tests/RunCMake/CMakeLists.txt +++ b/Tests/RunCMake/CMakeLists.txt @@ -236,6 +236,11 @@ if("${CMAKE_GENERATOR}" MATCHES "Visual Studio [^6]") add_RunCMake_test(SolutionGlobalSections) endif() +if(MSVC AND MSVC_VERSION GREATER 1500) + # Visual Studio 2010 or newer + add_RunCMake_test(VS10Project) +endif() + if(XCODE_VERSION AND NOT "${XCODE_VERSION}" VERSION_LESS 3) add_RunCMake_test(XcodeProject -DXCODE_VERSION=${XCODE_VERSION}) endif() diff --git a/Tests/RunCMake/VS10Project/CMakeLists.txt b/Tests/RunCMake/VS10Project/CMakeLists.txt new file mode 100644 index 0000000..91baae7 --- /dev/null +++ b/Tests/RunCMake/VS10Project/CMakeLists.txt @@ -0,0 +1,3 @@ +cmake_minimum_required(VERSION 3.5.0) +project(${RunCMake_TEST} NONE) +include(${RunCMake_TEST}.cmake) diff --git a/Tests/RunCMake/VS10Project/RunCMakeTest.cmake b/Tests/RunCMake/VS10Project/RunCMakeTest.cmake new file mode 100644 index 0000000..cc2cc2e --- /dev/null +++ b/Tests/RunCMake/VS10Project/RunCMakeTest.cmake @@ -0,0 +1,2 @@ +include(RunCMake) +run_cmake(VsConfigurationType) diff --git a/Tests/RunCMake/VS10Project/VsConfigurationType-check.cmake b/Tests/RunCMake/VS10Project/VsConfigurationType-check.cmake new file mode 100644 index 0000000..69df345 --- /dev/null +++ b/Tests/RunCMake/VS10Project/VsConfigurationType-check.cmake @@ -0,0 +1,24 @@ +set(vcProjectFile "${RunCMake_TEST_BINARY_DIR}/foo.vcxproj") +if(NOT EXISTS "${vcProjectFile}") + set(RunCMake_TEST_FAILED "Project file ${vcProjectFile} does not exist.") + return() +endif() + +set(propertyFound FALSE) +file(STRINGS "${vcProjectFile}" lines) +foreach(line IN LISTS lines) + if(line MATCHES "^ *([^<]*)$") + set(propertyFound TRUE) + set(expectedValue "MyValue") + set(actualValue ${CMAKE_MATCH_1}) + if(NOT (${actualValue} STREQUAL ${expectedValue})) + set(RunCMake_TEST_FAILED "ConfigurationType \"${actualValue}\" differs from expected value \"${expectedValue}\".") + return() + endif() + endif() +endforeach() + +if(NOT propertyFound) + set(RunCMake_TEST_FAILED "Property ConfigurationType not found in project file.") + return() +endif() diff --git a/Tests/RunCMake/VS10Project/VsConfigurationType.cmake b/Tests/RunCMake/VS10Project/VsConfigurationType.cmake new file mode 100644 index 0000000..a73dfe8 --- /dev/null +++ b/Tests/RunCMake/VS10Project/VsConfigurationType.cmake @@ -0,0 +1,3 @@ +enable_language(CXX) +add_library(foo foo.cpp) +set_target_properties(foo PROPERTIES VS_CONFIGURATION_TYPE "MyValue") diff --git a/Tests/RunCMake/VS10Project/foo.cpp b/Tests/RunCMake/VS10Project/foo.cpp new file mode 100644 index 0000000..2fb55ee --- /dev/null +++ b/Tests/RunCMake/VS10Project/foo.cpp @@ -0,0 +1 @@ +void foo() { } -- 2.7.1.windows.2 Von: Brad King An: Fabian.Otto at rohde-schwarz.com, Kopie: cmake-developers at cmake.org Datum: 24.02.2016 17:09 Betreff: Re: [cmake-developers] [PATCH] Add target property VS_CONFIGURATION_TYPE to Visual Studio 10 target generator On 02/22/2016 11:35 AM, Fabian.Otto at rohde-schwarz.com wrote: > The patch adds the target property VS_CONFIGURATION_TYPE. It allows to > set an arbitrary value to the "ConfigurationType" property > > This is useful if you want to build a Windows Kernel Mode Driver. This looks okay to me. Please extend the test suite to cover this feature. So far all VS features that we test have effects on the generation that we can test explicitly. In this case it looks like we might not be able to test actually building such a project. For that, take a look at these test directories: Tests/RunCMake/SolutionGlobalSections Tests/RunCMake/XcodeProject It tests running CMake and then parses the actual project file content to check that it is as expected. A similar test could be added for VS .vcxproj content testing and used to cover this feature. Thanks, -Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Goulet at autodesk.com Thu Feb 25 10:47:52 2016 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Thu, 25 Feb 2016 15:47:52 +0000 Subject: [cmake-developers] Windows 10 Store App - deploy content Message-ID: <9445e44c3d7c486f9877e9a9c2cdcecf@BN1PR79MB007.MGDADSK.autodesk.com> Hi everyone, When creating a Windows 10 Store App using CMake, how do we add DLL files that we do not build (provided by external packages) to the list of content files for deployment if they get copied to the output directory by the INSTALL step? We currently use install commands to copy dependencies to binaries output directory, and it looks like this won't work for Windows 10 Store App because they need to be part of the content deployment? i.e. set_source_files_properties(${FILES} PROPERTIES VS_DEPLOYMENT_CONTENT 1) Any idea how I can solve that? Thanks! -Robert Goulet -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Thu Feb 25 12:16:12 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 25 Feb 2016 12:16:12 -0500 Subject: [cmake-developers] [CMake 0015988]: No parse error message on double 'else' contruction Message-ID: <04734185da601575f5f1a50a660f28f5@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15988 ====================================================================== Reported By: Ruslan Baratov Assigned To: ====================================================================== Project: CMake Issue ID: 15988 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-25 12:16 EST Last Modified: 2016-02-25 12:16 EST ====================================================================== Summary: No parse error message on double 'else' contruction Description: This invalid construction doesn't produce any error/warning message: if(A EQUAL B) message("1") else() # error, should be elseif with some condition message("2") else() message("3") # never will be printed endif() ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-25 12:16 Ruslan Baratov New Issue ====================================================================== From brad.king at kitware.com Thu Feb 25 14:22:19 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 25 Feb 2016 14:22:19 -0500 Subject: [cmake-developers] [PATCH] Add target property VS_CONFIGURATION_TYPE to Visual Studio 10 target generator In-Reply-To: References: <56CDD5B0.8020704@kitware.com> Message-ID: <56CF546B.6000900@kitware.com> On 02/25/2016 10:36 AM, Fabian.Otto at rohde-schwarz.com wrote: > thanks for your feedback. I added a test for the feature. Thanks. It looks like your mailer mangled the original patch. Please re-send both patches as attachments. Thanks, -Brad From fabian at fabianotto.de Thu Feb 25 16:19:43 2016 From: fabian at fabianotto.de (Fabian Otto) Date: Thu, 25 Feb 2016 22:19:43 +0100 Subject: [cmake-developers] [PATCH] Add target property VS_CONFIGURATION_TYPE to Visual Studio 10 target generator In-Reply-To: <56CF546B.6000900@kitware.com> References: <56CF546B.6000900@kitware.com> Message-ID: <56CF6FEF.5060304@fabianotto.de> Hi Brad, I'm sorry. I recreated a single patch that contains all changes. Hopefully it works this time. If not, please let me know. Best regards, Fabian -------------- next part -------------- From 25c58561d2ddbf061705ef6a3a09e2c66436c3eb Mon Sep 17 00:00:00 2001 From: Fabian Otto Date: Thu, 25 Feb 2016 22:04:05 +0100 Subject: [PATCH] Add VS_CONFIGURATION_TYPE target property --- Help/manual/cmake-properties.7.rst | 1 + Help/prop_tgt/VS_CONFIGURATION_TYPE.rst | 10 +++ Source/cmVisualStudio10TargetGenerator.cxx | 79 ++++++++++++---------- Tests/RunCMake/CMakeLists.txt | 5 ++ Tests/RunCMake/VS10Project/CMakeLists.txt | 3 + Tests/RunCMake/VS10Project/RunCMakeTest.cmake | 2 + .../VS10Project/VsConfigurationType-check.cmake | 24 +++++++ .../RunCMake/VS10Project/VsConfigurationType.cmake | 3 + Tests/RunCMake/VS10Project/foo.cpp | 1 + 9 files changed, 93 insertions(+), 35 deletions(-) create mode 100644 Help/prop_tgt/VS_CONFIGURATION_TYPE.rst create mode 100644 Tests/RunCMake/VS10Project/CMakeLists.txt create mode 100644 Tests/RunCMake/VS10Project/RunCMakeTest.cmake create mode 100644 Tests/RunCMake/VS10Project/VsConfigurationType-check.cmake create mode 100644 Tests/RunCMake/VS10Project/VsConfigurationType.cmake create mode 100644 Tests/RunCMake/VS10Project/foo.cpp diff --git a/Help/manual/cmake-properties.7.rst b/Help/manual/cmake-properties.7.rst index a41d484..d6618fe 100644 --- a/Help/manual/cmake-properties.7.rst +++ b/Help/manual/cmake-properties.7.rst @@ -255,6 +255,7 @@ Properties on Targets /prop_tgt/TYPE /prop_tgt/VERSION /prop_tgt/VISIBILITY_INLINES_HIDDEN + /prop_tgt/VS_CONFIGURATION_TYPE /prop_tgt/VS_DESKTOP_EXTENSIONS_VERSION /prop_tgt/VS_DOTNET_REFERENCES /prop_tgt/VS_DOTNET_TARGET_FRAMEWORK_VERSION diff --git a/Help/prop_tgt/VS_CONFIGURATION_TYPE.rst b/Help/prop_tgt/VS_CONFIGURATION_TYPE.rst new file mode 100644 index 0000000..78feb20 --- /dev/null +++ b/Help/prop_tgt/VS_CONFIGURATION_TYPE.rst @@ -0,0 +1,10 @@ +VS_CONFIGURATION_TYPE +--------------------- + +Visual Studio project configuration type. + +Sets the "ConfigurationType" attribute for a generated Visual Studio project. +If this property is set, it overrides the default setting that is based on +the target type (e.g. "StaticLibrary", "Application", ...). + +Supported on Visual Studio 2010 and higher. diff --git a/Source/cmVisualStudio10TargetGenerator.cxx b/Source/cmVisualStudio10TargetGenerator.cxx index a664442..69b4029 100644 --- a/Source/cmVisualStudio10TargetGenerator.cxx +++ b/Source/cmVisualStudio10TargetGenerator.cxx @@ -696,43 +696,52 @@ void cmVisualStudio10TargetGenerator::WriteProjectConfigurationValues() i->c_str(), 1, " Label=\"Configuration\"", "\n"); std::string configType = ""; - switch(this->GeneratorTarget->GetType()) - { - case cmState::SHARED_LIBRARY: - case cmState::MODULE_LIBRARY: - configType += "DynamicLibrary"; - break; - case cmState::OBJECT_LIBRARY: - case cmState::STATIC_LIBRARY: - configType += "StaticLibrary"; - break; - case cmState::EXECUTABLE: - if(this->NsightTegra && - !this->GeneratorTarget->GetPropertyAsBool("ANDROID_GUI")) - { - // Android executables are .so too. + const char* vsConfigurationType = + this->GeneratorTarget->GetProperty("VS_CONFIGURATION_TYPE"); + if(vsConfigurationType) + { + configType += cmVS10EscapeXML(vsConfigurationType); + } + else + { + switch(this->GeneratorTarget->GetType()) + { + case cmState::SHARED_LIBRARY: + case cmState::MODULE_LIBRARY: configType += "DynamicLibrary"; - } - else - { - configType += "Application"; - } - break; - case cmState::UTILITY: - case cmState::GLOBAL_TARGET: - if(this->NsightTegra) - { - // Tegra-Android platform does not understand "Utility". + break; + case cmState::OBJECT_LIBRARY: + case cmState::STATIC_LIBRARY: configType += "StaticLibrary"; - } - else - { - configType += "Utility"; - } - break; - case cmState::UNKNOWN_LIBRARY: - case cmState::INTERFACE_LIBRARY: - break; + break; + case cmState::EXECUTABLE: + if(this->NsightTegra && + !this->GeneratorTarget->GetPropertyAsBool("ANDROID_GUI")) + { + // Android executables are .so too. + configType += "DynamicLibrary"; + } + else + { + configType += "Application"; + } + break; + case cmState::UTILITY: + case cmState::GLOBAL_TARGET: + if(this->NsightTegra) + { + // Tegra-Android platform does not understand "Utility". + configType += "StaticLibrary"; + } + else + { + configType += "Utility"; + } + break; + case cmState::UNKNOWN_LIBRARY: + case cmState::INTERFACE_LIBRARY: + break; + } } configType += "\n"; this->WriteString(configType.c_str(), 2); diff --git a/Tests/RunCMake/CMakeLists.txt b/Tests/RunCMake/CMakeLists.txt index 0a388c5..81df69f 100644 --- a/Tests/RunCMake/CMakeLists.txt +++ b/Tests/RunCMake/CMakeLists.txt @@ -236,6 +236,11 @@ if("${CMAKE_GENERATOR}" MATCHES "Visual Studio [^6]") add_RunCMake_test(SolutionGlobalSections) endif() +if(MSVC AND MSVC_VERSION GREATER 1500) + # Visual Studio 2010 or newer + add_RunCMake_test(VS10Project) +endif() + if(XCODE_VERSION AND NOT "${XCODE_VERSION}" VERSION_LESS 3) add_RunCMake_test(XcodeProject -DXCODE_VERSION=${XCODE_VERSION}) endif() diff --git a/Tests/RunCMake/VS10Project/CMakeLists.txt b/Tests/RunCMake/VS10Project/CMakeLists.txt new file mode 100644 index 0000000..91baae7 --- /dev/null +++ b/Tests/RunCMake/VS10Project/CMakeLists.txt @@ -0,0 +1,3 @@ +cmake_minimum_required(VERSION 3.5.0) +project(${RunCMake_TEST} NONE) +include(${RunCMake_TEST}.cmake) diff --git a/Tests/RunCMake/VS10Project/RunCMakeTest.cmake b/Tests/RunCMake/VS10Project/RunCMakeTest.cmake new file mode 100644 index 0000000..cc2cc2e --- /dev/null +++ b/Tests/RunCMake/VS10Project/RunCMakeTest.cmake @@ -0,0 +1,2 @@ +include(RunCMake) +run_cmake(VsConfigurationType) diff --git a/Tests/RunCMake/VS10Project/VsConfigurationType-check.cmake b/Tests/RunCMake/VS10Project/VsConfigurationType-check.cmake new file mode 100644 index 0000000..4690970 --- /dev/null +++ b/Tests/RunCMake/VS10Project/VsConfigurationType-check.cmake @@ -0,0 +1,24 @@ +set(vcProjectFile "${RunCMake_TEST_BINARY_DIR}/foo.vcxproj") +if(NOT EXISTS "${vcProjectFile}") + set(RunCMake_TEST_FAILED "Project file ${vcProjectFile} does not exist.") + return() +endif() + +set(propertyFound FALSE) +file(STRINGS "${vcProjectFile}" lines) +foreach(line IN LISTS lines) + if(line MATCHES "^ *(.*)$") + set(propertyFound TRUE) + set(expectedValue "MyValue") + set(actualValue ${CMAKE_MATCH_1}) + if(NOT (${actualValue} STREQUAL ${expectedValue})) + set(RunCMake_TEST_FAILED "ConfigurationType \"${actualValue}\" differs from expected value \"${expectedValue}\".") + return() + endif() + endif() +endforeach() + +if(NOT propertyFound) + set(RunCMake_TEST_FAILED "Property ConfigurationType not found in project file.") + return() +endif() diff --git a/Tests/RunCMake/VS10Project/VsConfigurationType.cmake b/Tests/RunCMake/VS10Project/VsConfigurationType.cmake new file mode 100644 index 0000000..a73dfe8 --- /dev/null +++ b/Tests/RunCMake/VS10Project/VsConfigurationType.cmake @@ -0,0 +1,3 @@ +enable_language(CXX) +add_library(foo foo.cpp) +set_target_properties(foo PROPERTIES VS_CONFIGURATION_TYPE "MyValue") diff --git a/Tests/RunCMake/VS10Project/foo.cpp b/Tests/RunCMake/VS10Project/foo.cpp new file mode 100644 index 0000000..2fb55ee --- /dev/null +++ b/Tests/RunCMake/VS10Project/foo.cpp @@ -0,0 +1 @@ +void foo() { } -- 2.7.2.windows.1 From Gilles.Khouzam at microsoft.com Thu Feb 25 19:44:14 2016 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Fri, 26 Feb 2016 00:44:14 +0000 Subject: [cmake-developers] Windows 10 Store App - deploy content In-Reply-To: <9445e44c3d7c486f9877e9a9c2cdcecf@BN1PR79MB007.MGDADSK.autodesk.com> References: <9445e44c3d7c486f9877e9a9c2cdcecf@BN1PR79MB007.MGDADSK.autodesk.com> Message-ID: We have a pull request on our branch that might be helpful by make them extensions. https://github.com/Microsoft/CMake/pull/15 From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] Sent: Thursday, February 25, 2016 07:48 To: cmake-developers at cmake.org; Gilles Khouzam Subject: Windows 10 Store App - deploy content Hi everyone, When creating a Windows 10 Store App using CMake, how do we add DLL files that we do not build (provided by external packages) to the list of content files for deployment if they get copied to the output directory by the INSTALL step? We currently use install commands to copy dependencies to binaries output directory, and it looks like this won't work for Windows 10 Store App because they need to be part of the content deployment? i.e. set_source_files_properties(${FILES} PROPERTIES VS_DEPLOYMENT_CONTENT 1) Any idea how I can solve that? Thanks! -Robert Goulet -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Fri Feb 26 05:13:42 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 26 Feb 2016 05:13:42 -0500 Subject: [cmake-developers] [CMake 0015989]: target_compile_features not working properly for XCode Message-ID: <2d4e2a3729aa831fe760e8fa1fcd0b48@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15989 ====================================================================== Reported By: LCID Fire Assigned To: ====================================================================== Project: CMake Issue ID: 15989 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-26 05:13 EST Last Modified: 2016-02-26 05:13 EST ====================================================================== Summary: target_compile_features not working properly for XCode Description: target_compile_features does not change "C++ Language Dialect" to C++14 when using `cxx_variable_templates`. Steps to Reproduce: target_compile_features( yourtarget PRIVATE cxx_variable_templates ) C++ Language Dialect of yourtarget still is C++11 in XCode. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-26 05:13 LCID Fire New Issue ====================================================================== From James.Crosby at arm.com Fri Feb 26 07:18:53 2016 From: James.Crosby at arm.com (James Crosby) Date: Fri, 26 Feb 2016 12:18:53 +0000 Subject: [cmake-developers] [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5 In-Reply-To: <56CDD578.9060709@kitware.com> References: <56BA1B94.5000407@kitware.com> <56BB4D3E.6000408@kitware.com> <56C484C6.7040100@kitware.com> <6AFB6565-459A-4917-B436-E30995CE86A1@arm.com> <56CDD578.9060709@kitware.com> Message-ID: <23AB241D-487A-44A1-BC9F-2C3D65535AA3@arm.com> > On 24 Feb 2016, at 16:08, Brad King wrote: > > try_compile: Add option to control type of target > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7f1bd9fe > > One should be able to simply add > > set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) > > to the toolchain file. Then CMakeForceCompiler should not be needed anymore. > > Please try it out. Can confirm it works for armcc - thanks! James IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From brad.king at kitware.com Fri Feb 26 10:37:35 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 26 Feb 2016 10:37:35 -0500 Subject: [cmake-developers] [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5 In-Reply-To: <23AB241D-487A-44A1-BC9F-2C3D65535AA3@arm.com> References: <56BA1B94.5000407@kitware.com> <56BB4D3E.6000408@kitware.com> <56C484C6.7040100@kitware.com> <6AFB6565-459A-4917-B436-E30995CE86A1@arm.com> <56CDD578.9060709@kitware.com> <23AB241D-487A-44A1-BC9F-2C3D65535AA3@arm.com> Message-ID: <56D0713F.8010300@kitware.com> On 02/26/2016 07:18 AM, James Crosby wrote: > Can confirm it works for armcc - thanks! Great, thanks for testing! I've merged the feature to 'master' for inclusion in CMake 3.6. With this we can re-consider deprecating CMakeForceCompiler for that release too. Thanks, -Brad From brad.king at kitware.com Fri Feb 26 10:42:25 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 26 Feb 2016 10:42:25 -0500 Subject: [cmake-developers] [PATCH] Add FindLTTngUST module to find LTTng-UST library In-Reply-To: <1455930565-10273-1-git-send-email-eeppeliteloop@gmail.com> References: <1455930565-10273-1-git-send-email-eeppeliteloop@gmail.com> Message-ID: <56D07261.6020903@kitware.com> On 02/19/2016 08:09 PM, Philippe Proulx wrote: > Signed-off-by: Philippe Proulx > --- > Modules/FindLTTngUST.cmake | 88 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 88 insertions(+) > create mode 100644 Modules/FindLTTngUST.cmake Thanks for working on this. Please look at adding imported targets as described here: https://cmake.org/cmake/help/v3.5/manual/cmake-developer.7.html#find-modules See the FindPNG module for an example. Also please add a test case. Grep in the Tests directory for "FindPNG" for an example. Also please udpate Tests/CMakeOnly/AllFindModules/CMakeLists.txt at the bottom to check that the version string is available for this package. Thanks, -Brad From Robert.Goulet at autodesk.com Fri Feb 26 10:44:54 2016 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Fri, 26 Feb 2016 15:44:54 +0000 Subject: [cmake-developers] Windows 10 Store App - deploy content In-Reply-To: References: <9445e44c3d7c486f9877e9a9c2cdcecf@BN1PR79MB007.MGDADSK.autodesk.com> Message-ID: How does it work? Will this install files into the "AppX" directory at deployment step? From: Gilles Khouzam [mailto:Gilles.Khouzam at microsoft.com] Sent: Thursday, February 25, 2016 7:44 PM To: Robert Goulet ; cmake-developers at cmake.org Subject: RE: Windows 10 Store App - deploy content We have a pull request on our branch that might be helpful by make them extensions. https://github.com/Microsoft/CMake/pull/15 From: Robert Goulet [mailto:Robert.Goulet at autodesk.com] Sent: Thursday, February 25, 2016 07:48 To: cmake-developers at cmake.org; Gilles Khouzam > Subject: Windows 10 Store App - deploy content Hi everyone, When creating a Windows 10 Store App using CMake, how do we add DLL files that we do not build (provided by external packages) to the list of content files for deployment if they get copied to the output directory by the INSTALL step? We currently use install commands to copy dependencies to binaries output directory, and it looks like this won't work for Windows 10 Store App because they need to be part of the content deployment? i.e. set_source_files_properties(${FILES} PROPERTIES VS_DEPLOYMENT_CONTENT 1) Any idea how I can solve that? Thanks! -Robert Goulet -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Feb 26 11:06:25 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 26 Feb 2016 11:06:25 -0500 Subject: [cmake-developers] [PATCH] Add target property VS_CONFIGURATION_TYPE to Visual Studio 10 target generator In-Reply-To: <56CF6FEF.5060304@fabianotto.de> References: <56CF546B.6000900@kitware.com> <56CF6FEF.5060304@fabianotto.de> Message-ID: <56D07801.4080404@kitware.com> On 02/25/2016 04:19 PM, Fabian Otto wrote: > I recreated a single patch that contains all changes. Thanks! Applied with minor tweaks: VS: Add option to set `ConfigurationType` of a .vcxproj file https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6122909c -Brad From mantis at public.kitware.com Fri Feb 26 14:40:37 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 26 Feb 2016 14:40:37 -0500 Subject: [cmake-developers] [CMake 0015990]: CMake multi-processor compilation for Fortran projects Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15990 ====================================================================== Reported By: abductor Assigned To: ====================================================================== Project: CMake Issue ID: 15990 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2016-02-26 14:40 EST Last Modified: 2016-02-26 14:40 EST ====================================================================== Summary: CMake multi-processor compilation for Fortran projects Description: For Fortran project Visual Studio support /MP flags for multi-processor compile. How set this flag in CMakeLists.txt for Fortran projects? For example, I set definition /MP for c++ projects. and it is work. But don't work for Fortran language. I try set in CMAKE_Fortran_FLAGS /MP flag, but unsuccessfully. http://stackoverflow.com/questions/35636166/cmake-multi-processor-compile-for-fortran-projects ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-26 14:40 abductor New Issue ====================================================================== From mantis at public.kitware.com Fri Feb 26 15:26:09 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 26 Feb 2016 15:26:09 -0500 Subject: [cmake-developers] [CMake 0015991]: Can't create Visual Studio 2015 project with CMake Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15991 ====================================================================== Reported By: hokushin Assigned To: ====================================================================== Project: CMake Issue ID: 15991 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-26 15:26 EST Last Modified: 2016-02-26 15:26 EST ====================================================================== Summary: Can't create Visual Studio 2015 project with CMake Description: The C compiler identification is MSVC 19.0.23506.0 The CXX compiler identification is MSVC 19.0.23506.0 Check for working C compiler using: Visual Studio 14 2015 Check for working C compiler using: Visual Studio 14 2015 -- works Detecting C compiler ABI info Detecting C compiler ABI info - done Check for working CXX compiler using: Visual Studio 14 2015 Check for working CXX compiler using: Visual Studio 14 2015 -- works Detecting CXX compiler ABI info Detecting CXX compiler ABI info - done Detecting CXX compile features Detecting CXX compile features - done CMake Error at CMakeLists.txt:53 (message): Unknown processor:AMD64 Configuring incomplete, errors occurred! See also "C:/1/CMakeFiles/CMakeOutput.log". Steps to Reproduce: 1. project https://github.com/devsisters/libquic 2. CMakeLists cmake_minimum_required (VERSION 2.8.10) project (libquic) if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES) message(STATUS "Setting build type to 'Debug' as none was specified.") set(CMAKE_BUILD_TYPE Debug CACHE STRING "Choose the type of build." FORCE) # Set the possible values of build type for cmake-gui #set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS "Debug" "Release" # "MinSizeRel" "RelWithDebInfo") endif() set(COMMON_C_FLAGS "${COMMON_C_FLAGS} -Wall") set(COMMON_DEBUG_FLAGS "-gdwarf-4") set(COMMON_RELEASE_FLAGS "") set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${COMMON_C_FLAGS}") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${COMMON_C_FLAGS} -std=gnu++11") if (CMAKE_BUILD_TYPE STREQUAL Debug) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${COMMON_DEBUG_FLAGS}") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${COMMON_DEBUG_FLAGS}") elseif (CMAKE_BUILD_TYPE STREQUAL Release) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${COMMON_RELEASE_FLAGS}") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${COMMON_RELEASE_FLAGS}") endif() add_definitions(-DUSE_OPENSSL) if (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "x86_64") set(ARCH "amd64") elseif (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "amd64") set(ARCH "amd64") #elseif (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "AMD64") # # cmake reports AMD64 on Windows, but we might be building for 32-bit. # if (CMAKE_CL_64) # set(ARCH "amd64") # else() # set(ARCH "386") # endif() elseif (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "x86") set(ARCH "386") elseif (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "i386") set(ARCH "386") elseif (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "i686") set(ARCH "386") elseif (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "arm") set(ARCH "arm") #elseif (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "aarch64") # set(ARCH "aarch64") else() message(FATAL_ERROR "Unknown processor:" ${CMAKE_SYSTEM_PROCESSOR}) endif() if (${ARCH} STREQUAL "386" AND APPLE) # With CMake 2.8.x, ${CMAKE_SYSTEM_PROCESSOR} evalutes to i386 on OS X, # but clang defaults to 64-bit builds on OS X unless otherwise told. # Set ARCH to x86_64 so clang and CMake agree. This is fixed in CMake 3. set(ARCH "amd64") endif() #add_subdirectory(crypto) include_directories(src src/third_party/modp_b64 boringssl/include src/third_party/protobuf/src) set( NET_SOURCES src/net/quic/quic_protocol.cc src/net/quic/quic_packet_generator.cc src/net/quic/quic_flow_controller.cc src/net/quic/quic_connection_stats.cc src/net/quic/quic_fec_group.cc src/net/quic/quic_fec_group_interface.cc src/net/quic/quic_data_writer.cc src/net/quic/quic_data_reader.cc src/net/quic/quic_session.cc src/net/quic/quic_spdy_session.cc src/net/quic/quic_spdy_stream.cc src/net/quic/iovector.cc src/net/quic/quic_stream_sequencer.cc src/net/quic/quic_framer.cc src/net/quic/quic_sent_packet_manager.cc src/net/quic/quic_time.cc src/net/quic/quic_headers_stream.cc src/net/quic/quic_connection.cc src/net/quic/quic_types.cc src/net/quic/quic_received_packet_manager.cc src/net/quic/quic_write_blocked_list.cc src/net/quic/quic_crypto_stream.cc src/net/quic/quic_socket_address_coder.cc src/net/quic/quic_utils.cc src/net/quic/quic_frame_list.cc src/net/quic/crypto/quic_crypto_server_config.cc src/net/quic/crypto/crypto_handshake_message.cc src/net/quic/crypto/p256_key_exchange_openssl.cc src/net/quic/crypto/cert_compressor.cc src/net/quic/crypto/crypto_secret_boxer.cc src/net/quic/crypto/aes_128_gcm_12_encrypter_openssl.cc src/net/quic/crypto/curve25519_key_exchange.cc src/net/quic/crypto/chacha20_poly1305_encrypter_openssl.cc src/net/quic/crypto/chacha20_poly1305_decrypter_openssl.cc src/net/quic/crypto/chacha20_poly1305_rfc7539_encrypter_openssl.cc src/net/quic/crypto/chacha20_poly1305_rfc7539_decrypter_openssl.cc src/net/quic/crypto/quic_decrypter.cc src/net/quic/crypto/channel_id_openssl.cc src/net/quic/crypto/null_decrypter.cc src/net/quic/crypto/crypto_server_config_protobuf.cc src/net/quic/crypto/aead_base_decrypter_openssl.cc src/net/quic/crypto/scoped_evp_aead_ctx.cc src/net/quic/crypto/quic_random.cc src/net/quic/crypto/common_cert_set.cc src/net/quic/crypto/null_encrypter.cc src/net/quic/crypto/crypto_framer.cc src/net/quic/crypto/crypto_handshake.cc src/net/quic/crypto/channel_id.cc src/net/quic/crypto/strike_register.cc src/net/quic/crypto/aead_base_encrypter_openssl.cc src/net/quic/crypto/crypto_utils.cc src/net/quic/crypto/local_strike_register_client.cc src/net/quic/crypto/aes_128_gcm_12_decrypter_openssl.cc src/net/quic/crypto/quic_encrypter.cc src/net/quic/crypto/quic_crypto_client_config.cc src/net/quic/quic_clock.cc src/net/quic/quic_alarm.cc src/net/quic/quic_sent_entropy_manager.cc src/net/quic/congestion_control/pacing_sender.cc src/net/quic/congestion_control/time_loss_algorithm.cc src/net/quic/congestion_control/loss_detection_interface.cc src/net/quic/congestion_control/general_loss_algorithm.cc src/net/quic/congestion_control/send_algorithm_interface.cc src/net/quic/congestion_control/cubic.cc src/net/quic/congestion_control/cubic_bytes.cc src/net/quic/congestion_control/tcp_loss_algorithm.cc src/net/quic/congestion_control/prr_sender.cc src/net/quic/congestion_control/tcp_cubic_sender.cc src/net/quic/congestion_control/hybrid_slow_start.cc src/net/quic/congestion_control/rtt_stats.cc src/net/quic/congestion_control/tcp_cubic_bytes_sender.cc src/net/quic/quic_config.cc src/net/quic/quic_crypto_server_stream.cc src/net/quic/quic_flags.cc src/net/quic/reliable_quic_stream.cc src/net/quic/quic_bandwidth.cc src/net/quic/quic_unacked_packet_map.cc src/net/quic/quic_packet_creator.cc src/net/quic/quic_sustained_bandwidth_recorder.cc src/net/quic/quic_client_session_base.cc src/net/quic/quic_crypto_client_stream.cc src/net/quic/quic_server_id.cc src/net/quic/quic_simple_buffer_allocator.cc src/net/quic/proto/cached_network_parameters.pb.cc src/net/quic/proto/source_address_token.pb.cc src/net/quic/stream_sequencer_buffer.cc src/net/base/int128.cc src/net/base/io_buffer.cc src/net/base/net_util.cc src/net/base/net_errors.cc src/net/base/ip_endpoint.cc src/net/base/host_port_pair.cc src/net/base/port_util.cc src/net/base/address_family.cc src/net/spdy/spdy_frame_reader.cc src/net/spdy/spdy_frame_builder.cc src/net/spdy/spdy_framer.cc src/net/spdy/spdy_header_block.cc src/net/spdy/spdy_protocol.cc src/net/spdy/spdy_alt_svc_wire_format.cc src/net/spdy/hpack/hpack_constants.cc src/net/spdy/hpack/hpack_decoder.cc src/net/spdy/hpack/hpack_encoder.cc src/net/spdy/hpack/hpack_entry.cc src/net/spdy/hpack/hpack_header_table.cc src/net/spdy/hpack/hpack_huffman_table.cc src/net/spdy/hpack/hpack_input_stream.cc src/net/spdy/hpack/hpack_output_stream.cc src/net/spdy/hpack/hpack_static_table.cc ) if (${CMAKE_SYSTEM_NAME} MATCHES "Linux") set( BASE_ARCH_LIBRARIES ) set( BASE_ARCH_SOURCES src/base/threading/platform_thread_linux.cc ) elseif (${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD") set( BASE_ARCH_LIBRARIES ) set( BASE_ARCH_SOURCES src/base/threading/platform_thread_freebsd.cc ) elseif (${CMAKE_SYSTEM_NAME} MATCHES "Darwin") FIND_LIBRARY(COREFOUNDATION_LIBRARY CoreFoundation) FIND_LIBRARY(COCOA_LIBRARY Cocoa) FIND_LIBRARY(SECURITY_LIBRARY Security) set( BASE_ARCH_LIBRARIES ${COREFOUNDATION_LIBRARY} ${COCOA_LIBRARY} ) set( BASE_ARCH_SOURCES src/base/threading/platform_thread_mac.mm src/base/strings/sys_string_conversions_mac.mm src/base/mac/foundation_util.mm src/base/mac/bundle_locations.mm src/base/mac/mach_logging.cc src/base/mac/scoped_mach_port.cc src/base/time/time_mac.cc ) endif() set( BASE_SOURCES ${BASE_ARCH_SOURCES} src/base/logging.cc src/base/posix/safe_strerror.cc src/base/memory/weak_ptr.cc src/base/memory/singleton.cc src/base/memory/ref_counted.cc src/base/memory/aligned_memory.cc src/base/rand_util_posix.cc src/base/threading/thread_id_name_manager.cc src/base/threading/platform_thread_posix.cc src/base/threading/platform_thread_internal_posix.cc src/base/threading/thread_restrictions.cc src/base/threading/thread_local_storage_posix.cc src/base/threading/thread_local_storage.cc src/base/threading/thread_collision_warner.cc src/base/threading/thread_local_posix.cc src/base/time/time_posix.cc src/base/time/time.cc src/base/synchronization/lock.cc src/base/synchronization/lock_impl_posix.cc src/base/synchronization/condition_variable_posix.cc src/base/strings/sys_string_conversions_posix.cc src/base/strings/string_piece.cc src/base/strings/string_util.cc src/base/strings/string_number_conversions.cc src/base/strings/string_util_constants.cc src/base/strings/stringprintf.cc src/base/strings/string_split.cc src/base/strings/string16.cc src/base/strings/utf_string_conversion_utils.cc src/base/strings/utf_string_conversions.cc src/base/pickle.cc src/base/debug/alias.cc src/base/debug/stack_trace.cc src/base/debug/debugger.cc src/base/callback_helpers.cc src/base/json/json_string_value_serializer.cc src/base/json/json_parser.cc src/base/json/string_escape.cc src/base/json/json_writer.cc src/base/json/json_reader.cc src/base/lazy_instance.cc src/base/callback_internal.cc src/base/base_switches.cc src/base/os_compat_nacl.cc src/base/values.cc src/base/at_exit.cc src/base/process/process_handle_posix.cc src/base/bind_helpers.cc src/base/vlog.cc src/base/location.cc src/base/base64.cc src/base/md5.cc src/base/metrics/statistics_recorder.cc src/base/metrics/histogram_base.cc src/base/metrics/sample_map.cc src/base/metrics/histogram.cc src/base/metrics/sample_vector.cc src/base/metrics/histogram_samples.cc src/base/metrics/bucket_ranges.cc src/base/metrics/sparse_histogram.cc src/base/metrics/metrics_hashes.cc src/base/rand_util.cc src/base/files/file_path_constants.cc src/base/files/file_path.cc src/base/third_party/nspr/prtime.cc src/base/third_party/dmg_fp/dtoa.cc src/base/third_party/dmg_fp/g_fmt.cc src/base/third_party/icu/icu_utf.cc src/base/command_line.cc src/base/third_party/superfasthash/superfasthash.c ) set( CRYPTO_SOURCES src/crypto/curve25519-donna.c src/crypto/curve25519_openssl.cc src/crypto/hkdf.cc src/crypto/hmac.cc src/crypto/openssl_util.cc src/crypto/hmac_openssl.cc src/crypto/symmetric_key_openssl.cc src/crypto/secure_hash_openssl.cc src/crypto/random.cc src/crypto/secure_util.cc ) set( URL_SOURCES src/url/url_constants.cc ) add_library( quic STATIC ${NET_SOURCES} ${BASE_SOURCES} ${CRYPTO_SOURCES} ${URL_SOURCES} src/stubs.cc src/third_party/modp_b64/modp_b64.cc src/third_party/zlib/gzwrite.c src/third_party/zlib/crc32.c src/third_party/zlib/zutil.c src/third_party/zlib/deflate.c src/third_party/zlib/simd_stub.c src/third_party/zlib/infback.c src/third_party/zlib/inffast.c src/third_party/zlib/inflate.c src/third_party/zlib/inftrees.c src/third_party/zlib/compress.c src/third_party/zlib/gzclose.c src/third_party/zlib/adler32.c src/third_party/zlib/gzlib.c src/third_party/zlib/trees.c src/third_party/zlib/gzread.c src/third_party/zlib/uncompr.c ) #add_executable( # test_quic_server # # custom/main.cc #) # XXX(serialx): Not sure if this is safe, since our CFLAGS contaminate boringssl build add_subdirectory(boringssl) add_subdirectory(protobuf) #target_link_libraries(test_quic_server quic ssl crypto -pthread ${BASE_ARCH_LIBRARIES}) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-26 15:26 hokushin New Issue 2016-02-26 15:26 hokushin File Added: 1.png ====================================================================== From eeppeliteloop at gmail.com Fri Feb 26 20:15:44 2016 From: eeppeliteloop at gmail.com (Philippe Proulx) Date: Fri, 26 Feb 2016 20:15:44 -0500 Subject: [cmake-developers] [PATCH v2] Add FindLTTngUST module to find LTTng-UST library Message-ID: <1456535744-30757-1-git-send-email-eeppeliteloop@gmail.com> This patch adds the FindLTTngUST module which can be used to find the LTTng-UST library. It sets result variables and creates an imported target, LTTng::UST. Since the module is able to find the LTTng-UST version string, this is tested in Tests/CMakeOnly/AllFindModules. The module is tested individually in Tests/FindLTTngUST, enabled by setting CMake_TEST_FindLTTngUST. Signed-off-by: Philippe Proulx --- Modules/FindLTTngUST.cmake | 111 ++++++++++++++++++++++++++ Tests/CMakeLists.txt | 4 + Tests/CMakeOnly/AllFindModules/CMakeLists.txt | 2 +- Tests/FindLTTngUST/CMakeLists.txt | 10 +++ Tests/FindLTTngUST/Test/CMakeLists.txt | 18 +++++ Tests/FindLTTngUST/Test/main.c | 31 +++++++ 6 files changed, 175 insertions(+), 1 deletion(-) create mode 100644 Modules/FindLTTngUST.cmake create mode 100644 Tests/FindLTTngUST/CMakeLists.txt create mode 100644 Tests/FindLTTngUST/Test/CMakeLists.txt create mode 100644 Tests/FindLTTngUST/Test/main.c diff --git a/Modules/FindLTTngUST.cmake b/Modules/FindLTTngUST.cmake new file mode 100644 index 0000000..07a50ca --- /dev/null +++ b/Modules/FindLTTngUST.cmake @@ -0,0 +1,111 @@ +#.rst: +# FindLTTngUST +# ------------ +# +# This module finds the `LTTng-UST `_ library. +# +# Imported target +# ^^^^^^^^^^^^^^^ +# +# This module defines the following :prop_tgt:`IMPORTED` target: +# +# ``LTTng::UST`` +# The LTTng-UST library, if found +# +# Result variables +# ^^^^^^^^^^^^^^^^ +# +# This module sets the following +# +# ``LTTNGUST_FOUND`` +# ``TRUE`` if system has LTTng-UST +# ``LTTNGUST_INCLUDE_DIRS`` +# The LTTng-UST include directories +# ``LTTNGUST_LIBRARIES`` +# The libraries needed to use LTTng-UST +# ``LTTNGUST_VERSION_STRING`` +# The LTTng-UST version +# ``LTTNGUST_HAS_TRACEF`` +# ``TRUE`` if the ``tracef()`` API is available in the system's LTTng-UST +# ``LTTNGUST_HAS_TRACELOG`` +# ``TRUE`` if the ``tracelog()`` API is available in the system's LTTng-UST +# +#============================================================================= +# Copyright 2016 Kitware, Inc. +# Copyright 2016 Philippe Proulx +# +# Distributed under the OSI-approved BSD License (the "License"); +# see accompanying file Copyright.txt for details. +# +# This software is distributed WITHOUT ANY WARRANTY; without even the +# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +# See the License for more information. +#============================================================================= +# (To distribute this file outside of CMake, substitute the full +# License text for the above reference.) + +find_path(LTTNGUST_INCLUDE_DIRS NAMES lttng/tracepoint.h) +find_library(LTTNGUST_LIBRARIES NAMES lttng-ust) + +if(LTTNGUST_INCLUDE_DIRS AND LTTNGUST_LIBRARIES) + # find tracef() and tracelog() support + set(LTTNGUST_HAS_TRACEF 0) + set(LTTNGUST_HAS_TRACELOG 0) + + if(EXISTS "${LTTNGUST_INCLUDE_DIRS}/lttng/tracef.h") + set(LTTNGUST_HAS_TRACEF TRUE) + endif() + + if(EXISTS "${LTTNGUST_INCLUDE_DIRS}/lttng/tracelog.h") + set(LTTNGUST_HAS_TRACELOG TRUE) + endif() + + # get version + set(lttngust_version_file "${LTTNGUST_INCLUDE_DIRS}/lttng/ust-version.h") + + if(EXISTS "${lttngust_version_file}") + file(STRINGS "${lttngust_version_file}" lttngust_version_major_string + REGEX "^[\t ]*#define[\t ]+LTTNG_UST_MAJOR_VERSION[\t ]+[0-9]+[\t ]*$") + file(STRINGS "${lttngust_version_file}" lttngust_version_minor_string + REGEX "^[\t ]*#define[\t ]+LTTNG_UST_MINOR_VERSION[\t ]+[0-9]+[\t ]*$") + file(STRINGS "${lttngust_version_file}" lttngust_version_patch_string + REGEX "^[\t ]*#define[\t ]+LTTNG_UST_PATCHLEVEL_VERSION[\t ]+[0-9]+[\t ]*$") + string(REGEX REPLACE ".*([0-9]+).*" "\\1" + lttngust_v_major "${lttngust_version_major_string}") + string(REGEX REPLACE ".*([0-9]+).*" "\\1" + lttngust_v_minor "${lttngust_version_minor_string}") + string(REGEX REPLACE ".*([0-9]+).*" "\\1" + lttngust_v_patch "${lttngust_version_patch_string}") + set(LTTNGUST_VERSION_STRING + "${lttngust_v_major}.${lttngust_v_minor}.${lttngust_v_patch}") + unset(lttngust_version_major_string) + unset(lttngust_version_minor_string) + unset(lttngust_version_patch_string) + unset(lttngust_v_major) + unset(lttngust_v_minor) + unset(lttngust_v_patch) + endif() + + unset(lttngust_version_file) + + if(NOT TARGET LTTng::UST) + add_library(LTTng::UST UNKNOWN IMPORTED) + set_target_properties(LTTng::UST PROPERTIES + INTERFACE_INCLUDE_DIRECTORIES "${LTTNGUST_INCLUDE_DIRS}" + INTERFACE_LINK_LIBRARIES ${CMAKE_DL_LIBS} + IMPORTED_LINK_INTERFACE_LANGUAGES "C" + IMPORTED_LOCATION "${LTTNGUST_LIBRARIES}") + endif() + + # add libdl to required libraries + set(LTTNGUST_LIBRARIES ${LTTNGUST_LIBRARIES} ${CMAKE_DL_LIBS}) +endif() + +# handle the QUIETLY and REQUIRED arguments and set LTTNGUST_FOUND to +# TRUE if all listed variables are TRUE +include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) +find_package_handle_standard_args(LTTngUST FOUND_VAR LTTNGUST_FOUND + REQUIRED_VARS LTTNGUST_LIBRARIES + LTTNGUST_INCLUDE_DIRS + VERSION_VAR LTTNGUST_VERSION_STRING) +mark_as_advanced(LTTNGUST_LIBRARIES LTTNGUST_INCLUDE_DIRS) diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt index b43275a..1e9d6f8 100644 --- a/Tests/CMakeLists.txt +++ b/Tests/CMakeLists.txt @@ -1371,6 +1371,10 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release add_subdirectory(FindJsonCpp) endif() + if(CMake_TEST_FindLTTngUST) + add_subdirectory(FindLTTngUST) + endif() + if(CMake_TEST_FindOpenSSL) add_subdirectory(FindOpenSSL) endif() diff --git a/Tests/CMakeOnly/AllFindModules/CMakeLists.txt b/Tests/CMakeOnly/AllFindModules/CMakeLists.txt index 0aad161..1f39052 100644 --- a/Tests/CMakeOnly/AllFindModules/CMakeLists.txt +++ b/Tests/CMakeOnly/AllFindModules/CMakeLists.txt @@ -81,7 +81,7 @@ endmacro() # reported. foreach(VTEST ALSA ARMADILLO BZIP2 CUPS CURL EXPAT FREETYPE GETTEXT GIT HG - HSPELL ICOTOOL JASPER LIBLZMA LIBXML2 LIBXSLT PERL PKG_CONFIG + HSPELL ICOTOOL JASPER LIBLZMA LIBXML2 LIBXSLT LTTNGUST PERL PKG_CONFIG PostgreSQL TIFF ZLIB) check_version_string(${VTEST} ${VTEST}_VERSION_STRING) endforeach() diff --git a/Tests/FindLTTngUST/CMakeLists.txt b/Tests/FindLTTngUST/CMakeLists.txt new file mode 100644 index 0000000..c9c471d --- /dev/null +++ b/Tests/FindLTTngUST/CMakeLists.txt @@ -0,0 +1,10 @@ +add_test(NAME FindLTTngUST.Test COMMAND + ${CMAKE_CTEST_COMMAND} -C $ + --build-and-test + "${CMake_SOURCE_DIR}/Tests/FindLTTngUST/Test" + "${CMake_BINARY_DIR}/Tests/FindLTTngUST/Test" + ${build_generator_args} + --build-project TestFindLTTngUST + --build-options ${build_options} + --test-command ${CMAKE_CTEST_COMMAND} -V -C $ + ) diff --git a/Tests/FindLTTngUST/Test/CMakeLists.txt b/Tests/FindLTTngUST/Test/CMakeLists.txt new file mode 100644 index 0000000..e5bd9f3 --- /dev/null +++ b/Tests/FindLTTngUST/Test/CMakeLists.txt @@ -0,0 +1,18 @@ +cmake_minimum_required(VERSION 3.5) +project(TestFindLTTngUST C) +include(CTest) + +find_package(LTTngUST REQUIRED) + +add_definitions(-DCMAKE_EXPECTED_LTTNGUST_VERSION="${LTTNGUST_VERSION_STRING}") +add_definitions(-DCMAKE_LTTNGUST_HAS_TRACEF="${LTTNGUST_HAS_TRACEF}") +add_definitions(-DCMAKE_LTTNGUST_HAS_TRACELOG="${LTTNGUST_HAS_TRACELOG}") + +add_executable(test_tgt main.c) +target_link_libraries(test_tgt LTTng::UST) +add_test(NAME test_tgt COMMAND test_tgt) + +add_executable(test_var main.c) +target_include_directories(test_var PRIVATE ${LTTNGUST_INCLUDE_DIRS}) +target_link_libraries(test_var PRIVATE ${LTTNGUST_LIBRARIES}) +add_test(NAME test_var COMMAND test_var) diff --git a/Tests/FindLTTngUST/Test/main.c b/Tests/FindLTTngUST/Test/main.c new file mode 100644 index 0000000..ac775a0 --- /dev/null +++ b/Tests/FindLTTngUST/Test/main.c @@ -0,0 +1,31 @@ +#include +#include +#include +#include + +#ifdef CMAKE_LTTNGUST_HAS_TRACEF +#include +#endif + +#ifdef CMAKE_LTTNGUST_HAS_TRACELOG +#include +#endif + +int main(void) +{ + char lttng_version_string[16]; + + snprintf(lttng_version_string, 16, "%u.%u.%u", LTTNG_UST_MAJOR_VERSION, + LTTNG_UST_MINOR_VERSION, LTTNG_UST_PATCHLEVEL_VERSION); + assert(!strcmp(lttng_version_string, CMAKE_EXPECTED_LTTNGUST_VERSION)); + +#ifdef CMAKE_LTTNGUST_HAS_TRACEF + tracef("calling tracef()! %d %s", -23, CMAKE_EXPECTED_LTTNGUST_VERSION); +#endif + +#ifdef CMAKE_LTTNGUST_HAS_TRACELOG + tracelog(TRACE_WARNING, "calling tracelog()! %d", 17); +#endif + + return 0; +} -- 2.7.1 From eeppeliteloop at gmail.com Fri Feb 26 20:18:22 2016 From: eeppeliteloop at gmail.com (Philippe Proulx) Date: Fri, 26 Feb 2016 20:18:22 -0500 Subject: [cmake-developers] [PATCH] Add FindLTTngUST module to find LTTng-UST library In-Reply-To: <56D07261.6020903@kitware.com> References: <1455930565-10273-1-git-send-email-eeppeliteloop@gmail.com> <56D07261.6020903@kitware.com> Message-ID: Thanks. I submitted a v2, but I'm still wondering: do I need to extract the documentation somehow, to put it in Help/module, or is it automatically extracted once it's merged? Philippe Proulx On Fri, Feb 26, 2016 at 10:42 AM, Brad King wrote: > On 02/19/2016 08:09 PM, Philippe Proulx wrote: >> Signed-off-by: Philippe Proulx >> --- >> Modules/FindLTTngUST.cmake | 88 ++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 88 insertions(+) >> create mode 100644 Modules/FindLTTngUST.cmake > > Thanks for working on this. > > Please look at adding imported targets as described here: > > https://cmake.org/cmake/help/v3.5/manual/cmake-developer.7.html#find-modules > > See the FindPNG module for an example. Also please add a test > case. Grep in the Tests directory for "FindPNG" for an example. > > Also please udpate Tests/CMakeOnly/AllFindModules/CMakeLists.txt > at the bottom to check that the version string is available for > this package. > > Thanks, > -Brad > From mantis at public.kitware.com Sat Feb 27 00:11:45 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 27 Feb 2016 00:11:45 -0500 Subject: [cmake-developers] [CMake 0015992]: Xcode generator's ReRunCMake.make fails if dependencies have been deleted Message-ID: <34262953990ed2f82cc5ec81c53f48d7@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15992 ====================================================================== Reported By: Rodger Combs Assigned To: ====================================================================== Project: CMake Issue ID: 15992 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-27 00:11 EST Last Modified: 2016-02-27 00:11 EST ====================================================================== Summary: Xcode generator's ReRunCMake.make fails if dependencies have been deleted Description: Currently, if a file that a CMake script previously had a dependency on is deleted, the Xcode generator's ReRunCMake.make Makefile will fail with a "no rule to make target " error. This happens pretty frequently if you have a CMake script that reads the ref file for your current git branch and you delete branches regularly, and can also happen if you make other build system changes. This can be solved by wrapping each item in the list with `$(wildcard )`, which effectively makes the dependencies optional. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-27 00:11 Rodger Combs New Issue ====================================================================== From plucinski.mariusz at gmail.com Sat Feb 27 09:38:16 2016 From: plucinski.mariusz at gmail.com (=?UTF-8?Q?Mariusz_Pluci=C5=84ski?=) Date: Sat, 27 Feb 2016 15:38:16 +0100 Subject: [cmake-developers] [PATCH SET] Support of Clang/C2 compiler Message-ID: Hello, About three months ago, Microsoft has released Visual Studio 2015 Update 1 with an interesting feature - the preview version of "Clang with Microsoft CodeGen" (a.k.a. Clang/C2). It is a separate compiler, built from frontend of Clang and backend of Microsoft's C++ compiler (known as C2). One of advantages of this compiler over cl.exe is full support of C++14 and GNU extensions. I thought, it would be interesting to make it usable with CMake. Basically, to switch the compiler one needs to select appropriate toolset - "c140_clang_3_7". CMake already has support of toolsets, so it's already possible to generate VS project with the following command: > cmake.exe -G "Visual Studio 14 2015" -T "v140_clang_3_7" Unfortunately, as this toolset is a bit different, it requires some different settings in the project file than these used with cl.exe compiler. This is what I am trying to fix with my patches. Following is the list of patches with descriptions: 1. kwsys: fix build on VS Clang/C2 toolset Makes it possible to build CMake itself with Clang/C2. This compiler does not support inline assembly in the cl.exe format. 2. CMakeDetermineCompilerId: allow to detect clang.exe bundled with Visual Studio CMAKE_C(XX)?_COMPILER variables should point to clang.exe instead of cl.exe 3. Visual Studio: in Clang/C2 toolset, setup correct compiler settings clang.exe takes most of options in clang/gcc-compatible format instead of cl.exe format. 4. Clang testable features: don't enable cxx_decltype_incomplete_return_type in MSVC simluation mode This feature does not work. Honestly, I am not sure about the reason - may be the bug in the compiler. 5. Visual Studio 14: support of tag in project files Projects using Clang/C2 use this tag to control language standard version. 6. Tests: fix AliasTarget building on Clang/C2 Clang in C++98 mode is unable to parse some of headers bundled with MSVC, so using C++11 is necessary. 7. Tests: fix Module.GenerateExportHeader building on Clang/C2 Clang/C2 uses gcc attributes syntax for deprecations, but uses cl.exe syntax for dllimports/exports. Also, includes same fix as in patch 6. 8. Tests: fix Module.WriteCompilerDetectionHeader building on Clang/C2 Visual Studio does not handle this test very well. Not sure why. 9. Tests: fix Complex building on Clang/C2 Same as in patch 6. 10. Tests: fix complexOneConfig building on Clang/C2 Same as in patch 6. 11. Tests: do not build ExternalProjectLocal/TutorialStep5 when path is too long This toolset uses a bit longer names of some files, which may cause full path size to exceed 256 characters. 12. Tests: fix Plugin building on Clang/C2 Same as in patch 6. 13. Tests: fix PDBDirectoryAndName on Clang/C2 Clang/C2 does not generate pdb files for static libraries. Note that debugging information is not lost - they're put into the .lib itself, and when the binary is created, they seem to be extracted and placed into binary's own pdb file. 14. Tests: do not build PrecompiledHeader on Clang/C2 Precompiled headers are not (yet?) supported in this compiler. 15. Tests: disable VSMidl on Clang/C2 I don't know why this test fails. As you can see, most of the changes are tests adjustments. In case of patches 8 and 15 I cannot provide good explanations on why these tests are failing - all suggestions are welcome! What can be guessed from the list of patches, I have successfully compiled CMake itself, and got all tests passing. Checked with aforementioned VS version, on Windows Server 2012. Patches are attached, they apply on top of "next" branch (d7b1a40b0f039ed46522d5c9f3c7c421833ba32c). I would highly appreciate any feedback or review! Best Regards Mariusz Plucinski PS For anybody who would like to run it: the precondition is to install Visual Studio 2015 Update 1 with "Clang with Microsoft CodeGen". Information about this process and more information about the feature itself are available in Visual C++ Team Blog on MSDN: https://blogs.msdn.microsoft.com/vcblog/2015/12/04/clang-with-microsoft-codegen-in-vs-2015-update-1/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-kwsys-fix-build-on-VS-Clang-C2-toolset.patch Type: application/octet-stream Size: 1026 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-CMakeDetermineCompilerId-allow-to-detect-clang.exe-b.patch Type: application/octet-stream Size: 1033 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Visual-Studio-in-Clang-C2-toolset-setup-correct-comp.patch Type: application/octet-stream Size: 4972 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Clang-testable-features-don-t-enable-cxx_decltype_in.patch Type: application/octet-stream Size: 1427 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Visual-Studio-14-support-of-CppLanguageStandard-tag-.patch Type: application/octet-stream Size: 1440 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Tests-fix-AliasTarget-building-on-Clang-C2.patch Type: application/octet-stream Size: 1092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-Tests-fix-Module.GenerateExportHeader-building-on-Cl.patch Type: application/octet-stream Size: 4597 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-Tests-fix-Module.WriteCompilerDetectionHeader-buildi.patch Type: application/octet-stream Size: 1086 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0009-Tests-fix-Complex-building-on-Clang-C2.patch Type: application/octet-stream Size: 1071 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0010-Tests-fix-complexOneConfig-building-on-Clang-C2.patch Type: application/octet-stream Size: 1112 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0011-Tests-do-not-build-ExternalProjectLocal-TutorialStep.patch Type: application/octet-stream Size: 1275 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0012-Tests-fix-Plugin-building-on-Clang-C2.patch Type: application/octet-stream Size: 1124 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0013-Tests-fix-PDBDirectoryAndName-on-Clang-C2.patch Type: application/octet-stream Size: 1167 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0014-Tests-do-not-build-PrecompiledHeader-on-Clang-C2.patch Type: application/octet-stream Size: 914 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0015-Tests-disable-VSMidl-on-Clang-C2.patch Type: application/octet-stream Size: 1607 bytes Desc: not available URL: From gjasny at googlemail.com Sun Feb 28 11:39:54 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Sun, 28 Feb 2016 17:39:54 +0100 Subject: [cmake-developers] [CMake 0015992]: Xcode generator's ReRunCMake.make fails if dependencies have been deleted In-Reply-To: <34262953990ed2f82cc5ec81c53f48d7@public.kitware.com> References: <34262953990ed2f82cc5ec81c53f48d7@public.kitware.com> Message-ID: <56D322DA.7000203@googlemail.com> On 27/02/16 06:11, Mantis Bug Tracker wrote: > Summary: Xcode generator's ReRunCMake.make fails if > dependencies have been deleted > Description: > Currently, if a file that a CMake script previously had a dependency on is > deleted, the Xcode generator's ReRunCMake.make Makefile will fail with a "no > rule to make target " error. This happens pretty frequently if you have a > CMake script that reads the ref file for your current git branch and you delete > branches regularly, and can also happen if you make other build system changes. > > This can be solved by wrapping each item in the list with `$(wildcard )`, > which effectively makes the dependencies optional. Brad: I pushed and merged the xcode-regenerate-on-deleted-files topic but I'm unsure about the test location itself and if this is a feature all generators should provide. I tested it with Xcode, Make, and Ninja. Thanks, Gregor From mantis at public.kitware.com Sun Feb 28 18:16:36 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 28 Feb 2016 18:16:36 -0500 Subject: [cmake-developers] [CMake 0015993]: "NMake Makefiles" generator doesn't escape special characters (such as '#') in build directory name correctly Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15993 ====================================================================== Reported By: Roy Ivy III Assigned To: ====================================================================== Project: CMake Issue ID: 15993 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-28 18:16 EST Last Modified: 2016-02-28 18:16 EST ====================================================================== Summary: "NMake Makefiles" generator doesn't escape special characters (such as '#') in build directory name correctly Description: When using `cmake -G "NMake Makefiles"` from a directory containing nmake-special characters, such as '#', the special characters are not escaped causing incorrect macro definitions and build executions. The special characters should be escaped with '^'. Steps to Reproduce: cd REPO mkdir #build cd #build cmake -G "NMake Makefiles" REPO_SRC nmake ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-28 18:16 Roy Ivy III New Issue ====================================================================== From ewmailing at gmail.com Mon Feb 29 06:59:40 2016 From: ewmailing at gmail.com (Eric Wing) Date: Mon, 29 Feb 2016 03:59:40 -0800 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: References: <568FE434.1020501@kitware.com> <569556D8.80308@kitware.com> <5696683B.2050703@kitware.com> <5697EF44.60001@kitware.com> <5699597B.80108@kitware.com> <569E644B.2020404@kitware.com> <569FA49B.2070005@kitware.com> <56B39386.1000709@kitware.com> Message-ID: I'm finding that I'm going to need to completely separate the C FLAGS from the Swift FLAGS. I hit some complicated situations where the C FLAGS (both compile and linker) are confusing the process and shouldn't be passed to Swift. I see in the CMakeSwiftInformation.cmake, there is a . However, I do not see a , just . Additionally, in regular CMake script, I was trying to set/use ${CMAKE_Swift_FLAGS} hoping it would just work, but it doesn't seem to have any effect. Is this something I'm going to have to implement in the C++ core? Thanks, Eric From Robert.Goulet at autodesk.com Mon Feb 29 09:15:34 2016 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Mon, 29 Feb 2016 14:15:34 +0000 Subject: [cmake-developers] C# support ready for review In-Reply-To: <0d23d51ac03d47bc9eaea8ce6d50818b@DE013666.schaeffler.com> References: <903866b8ac604d15a1bfb1d3c8c7afe1@DE013666.schaeffler.com> <8c87213acb6d49ac8a64c5f8e2998114@DE013666.schaeffler.com> <0d23d51ac03d47bc9eaea8ce6d50818b@DE013666.schaeffler.com> Message-ID: As soon as this is merged in 'master' I will give it a try. We are extremely interested to have C# support in CMake. That is the last piece of our entire toolchain that is currently not using CMake, so it would be more than welcome to have the entire system built with CMake. Good job! -----Original Message----- From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Stuermer, Michael SP/HZA-ZSEP Sent: Thursday, February 25, 2016 5:52 AM To: Gilles Khouzam ; CMake Developers Subject: Re: [cmake-developers] C# support ready for review Hi Gilles, good to hear C# support is working not only for me and some people are actually interested in it :-). Thanks for the patch, I already added to my github. All the changes make perfectly sense for me. Let me explain a bit more about things like hardcoding LangVersion in the module scripts etc. (in short, there is no reason for hardcoding langversion 3): The current C# support was developed by plain trial-and-error. I started out copying the CXX compiler module scripts, finding out the relevant/necessary variables, trying to find reasonable values etc. By starting with a copy of the CXX scripts I am quite sure there are some leftovers that do not make sense there. To adapt everything for C# I started by looking at a existing .csproj file and changing the target generator until everything went as expected. Initial values like the flags in CMakeCSharpInformation.cmake where copied as is from my first simple reference .csproj files. Also the special handling of .xaml, .xaml.cs and .Designer.cs files with the tags was just introduced when I realized I need it somewhere in our new project. Putting it all together I just want to say that the current state of development leaves room for a lot of improvement and if something seems like it could be done better, this is most probably the case. I really only pushed it to a level where I feel it's working well enough for me and I can focus on my actual job. The part that probably needs most additional work is all the C# detection and configuration part in the module scripts. I got it all up and running so we can develop our C/C++/C# cross-platform software here, but it's still some steps away from a perfectly configurable solution where everyone could be happy. best regards, Michael From: Gilles Khouzam [mailto:Gilles.Khouzam at microsoft.com] Sent: Thursday, February 25, 2016 8:44 AM To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers Subject: RE: C# support ready for review Hi Michael, Things are looking really good, I've just converted one of my personal projects to using CMake in very little time. I've included a small patch for your CSharp implementation. The first change is to add support to specify C# 6.0 in the flag table. The second removes the exception handling tag and the precompiled header tags since they don't make sense for C#, as well as adding a space between the platform comparisons. The space is not necessary for the project, but is you make any change in the property page inside of VS, a new property group is created instead of modifying the existing one. While this would not be a typical CMake scenario, it might be better to stay consistent with how VS and MSBuild process the file. The next thing that I want to start looking at, is to make this work for Windows Phone and Windows Store apps, so that it can match the support that we have with C++ in this regards. From: Gilles Khouzam Sent: Wednesday, February 24, 2016 14:47 To: 'Stuermer, Michael SP/HZA-ZSEP' ; CMake Developers Subject: RE: C# support ready for review Hi Michael, I've had more time to try this, what is the reasoning to hardcode the default LangVersion to 3 in Modules\CMakeCSharpInformation.cmake? Can we remove it? I'm trying this on some projects of mine. From: Stuermer, Michael SP/HZA-ZSEP [mailto:michael.stuermer at schaeffler.com] Sent: Thursday, February 18, 2016 03:44 To: Gilles Khouzam ; CMake Developers Subject: RE: C# support ready for review Hi Gilles, you are right about the specific user path. I already fixed this in my github "csharp" branch. Sorry for the inconvenience. As for the discrepancies: I just found out that my TortoiseGitMerge tool was not configured correctly: changes in comments where ignored (which is not what I wanted). I'll go over the patch again and remove the changes that are irrelevant to the C# features. Thanks for the hint on using MSBuild detection. I currently use the msbuild version that is provided automatically by visual studio, so I do not need any real detection. I didn't dig too deep into MSBuild versions, .NET framework versions, what can be configured etc. The configuration possibilities and what would make sense especially for other developers as well is something that should be discussed. My main aim was to be able to work with C# and .NET in a similar way as Visual Studio provides it. I only started C# development during the last year, so many things concerning configuration etc. could probably be improved. I'll post a new version of the patch later (or tomorrow) with the mentioned changes. best regards, Michael From: Gilles Khouzam [mailto:Gilles.Khouzam at microsoft.com] Sent: Thursday, February 18, 2016 8:17 AM To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers Subject: RE: C# support ready for review Hi Michael, Great work, this looks really good. I have a few comments on the changes. 1. You should use the registry to find the install path for MSBuild, it should be in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild with the version that you're looking for. This also bring the question of do you want to be able to specify the version of MSBuild that is used or base it off the generator? 2. In CMakeTestCSharpCompiler, you seem to still have a reference to your specific user path (COPY_FILE "C:/Users/stuermic/git/cmake_build/x64_14/Tests/CSharp")) You seem to have some slight discrepancies between your code and the release as there are changes that seem to be either unnecessary or going backwards. I noticed a tegra comment that seemed out of place as well as a comment change going from 14 to 12 where 14 was accurate. I'll try to play with this next week and get projects running on it. ~Gilles From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Stuermer, Michael SP/HZA-ZSEP Sent: Wednesday, February 10, 2016 06:03 To: CMake Developers Subject: [cmake-developers] C# support ready for review Native C# support is ready for review. I split the patch in two parts: ? part 1: ? Some preparational stuff that does not really change or enable anything. Documentation and Test files as well as the required CMake module is added. The changes to existing code are small, only few methods in existing classes are added/changed. Changes to existing code should be easy to review in this part ? part 2: ? This contains the main work. Almost everything takes place within cmVisualStudio10TargetGenerator. ? ? In addition to C# support three more target properties were introduced: ? . VS_USER_PROPS_CXX (allows use of custom .user.props MSBuild file in .vcxproj files) . VS_USER_PROPS_CSHARP (allows use of custom .user.props MSBuild file in .csproj files) . VS_DEBUGGER_WORKING_DIRECTORY (allows setting of debugger working directory in .vcxproj files) ? I tested the features using Visual Studio 2010-2015 in 32/64 bit and everything works on my machine so far. ? Please review/test/comment and give feedback what is necessary to get native C# support in upstream cmake. ? best regards, Michael ? ? -- 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 From brad.king at kitware.com Mon Feb 29 10:23:18 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 29 Feb 2016 10:23:18 -0500 Subject: [cmake-developers] [PATCH SET] Support of Clang/C2 compiler In-Reply-To: References: Message-ID: <56D46266.5090104@kitware.com> On 02/27/2016 09:38 AM, Mariusz Pluci?ski wrote: > select appropriate toolset - "c140_clang_3_7". CMake already has support of toolsets, so it's already possible to generate VS project with the following command: Gilles, IIRC you have been working on support for this too. Please take a look to see how the work can be integrated to add support for this. Thanks, -Brad From brad.king at kitware.com Mon Feb 29 10:23:27 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 29 Feb 2016 10:23:27 -0500 Subject: [cmake-developers] Adding Swift support to CMake for Linux/Makefiles In-Reply-To: References: <568FE434.1020501@kitware.com> <569556D8.80308@kitware.com> <5696683B.2050703@kitware.com> <5697EF44.60001@kitware.com> <5699597B.80108@kitware.com> <569E644B.2020404@kitware.com> <569FA49B.2070005@kitware.com> <56B39386.1000709@kitware.com> Message-ID: <56D4626F.9020803@kitware.com> On 02/29/2016 06:59 AM, Eric Wing wrote: > I see in the CMakeSwiftInformation.cmake, there is a > . However, I do not see a , > just . That is implicitly the flags for the corresponding language since it appears in the compilation rule specific to the language. > Additionally, in regular CMake script, I was trying to set/use > ${CMAKE_Swift_FLAGS} hoping it would just work, but it doesn't seem to > have any effect. Is this something I'm going to have to implement in > the C++ core? For the Makefile generator take a look at cmMakefileTargetGenerator::WriteTargetLanguageFlags cmMakefileTargetGenerator::WriteObjectBuildFile methods. They generate a _FLAGS variable in the makefile and reference it. Make sure those code paths are executed for Swift. There should be similar code for the Ninja generator too. -Brad From brad.king at kitware.com Mon Feb 29 10:23:34 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 29 Feb 2016 10:23:34 -0500 Subject: [cmake-developers] [PATCH] Add FindLTTngUST module to find LTTng-UST library In-Reply-To: References: <1455930565-10273-1-git-send-email-eeppeliteloop@gmail.com> <56D07261.6020903@kitware.com> Message-ID: <56D46276.6040404@kitware.com> On 02/26/2016 08:18 PM, Philippe Proulx wrote: > I submitted a v2, but I'm still wondering: do I need to extract the > documentation somehow, to put it in Help/module, or is it > automatically extracted once it's merged? You need to add a Help/module/FindLTTngUST.rst file containing: .. cmake-module:: ../../Modules/FindLTTngUST.cmake in order to hook the documentation extraction up. Also update Help/manual/cmake-modules.7.rst to add a reference to the module. Thanks, -Brad From brad.king at kitware.com Mon Feb 29 10:55:50 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 29 Feb 2016 10:55:50 -0500 Subject: [cmake-developers] [CMake 0015992]: Xcode generator's ReRunCMake.make fails if dependencies have been deleted In-Reply-To: <56D322DA.7000203@googlemail.com> References: <34262953990ed2f82cc5ec81c53f48d7@public.kitware.com> <56D322DA.7000203@googlemail.com> Message-ID: <56D46A06.5040209@kitware.com> On 02/28/2016 11:39 AM, Gregor Jasny via cmake-developers wrote: > Brad: I pushed and merged the xcode-regenerate-on-deleted-files topic > but I'm unsure about the test location itself and if this is a feature > all generators should provide. I tested it with Xcode, Make, and Ninja. Grep for `rerun` under Tests/RunCMake to see some tests that cover rerunning CMake already for try_compile and configure_file cases. A similar test could be added to Tests/RunCMake/BuildDepends, perhaps, to cover rerunning on removal of a CMakeLists.txt file. Thanks, -Brad From mantis at public.kitware.com Mon Feb 29 11:21:10 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 29 Feb 2016 11:21:10 -0500 Subject: [cmake-developers] [CMake 0015994]: CMake support for the Linux x86-64 32-bit ABI (x32-abi) Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15994 ====================================================================== Reported By: Steven Newbury Assigned To: ====================================================================== Project: CMake Issue ID: 15994 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-02-29 11:21 EST Last Modified: 2016-02-29 11:21 EST ====================================================================== Summary: CMake support for the Linux x86-64 32-bit ABI (x32-abi) Description: Currently CMake assumes library files can be located in ${CMAKE_INSTALL_PREFIX}/lib{64}, or otherwise on the system in /lib{64}, /usr/lib{64} etc. This isn't the case with x32-abi, where library directories are postfixed with x32, for example: ${CMAKE_INSTALL_PREFIX}/libx32 This results in CMake modules being unable to locate their resources, including failure during the configuration of CMake itself after initial bootstrap if CMAKE_INSTALL_PREFIX and individual *_DIR=/usr/libx32/cmake/* variables aren't manually provided. Steps to Reproduce: Build CMake from source on x32. Attempt to build projects with CMake. Additional Information: The attached patch is from pld-linux, a similar patch also exists for Gentoo Linux. This gives CMake the extra knowledge necessary to successfully locate the library paths on x32-abi. Perhaps, in the future a centralised CMake facility could provide system library paths? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-02-29 11:21 Steven Newbury New Issue 2016-02-29 11:21 Steven Newbury File Added: cmake-libx32.patch ====================================================================== From eeppeliteloop at gmail.com Mon Feb 29 12:35:27 2016 From: eeppeliteloop at gmail.com (Philippe Proulx) Date: Mon, 29 Feb 2016 12:35:27 -0500 Subject: [cmake-developers] [PATCH v3] Add FindLTTngUST module to find LTTng-UST library Message-ID: <1456767327-16790-1-git-send-email-eeppeliteloop@gmail.com> This patch adds the FindLTTngUST module which can be used to find the LTTng-UST library. It sets result variables and creates an imported target, LTTng::UST. Since the module is able to find the LTTng-UST version string, this is tested in Tests/CMakeOnly/AllFindModules. The module is tested individually in Tests/FindLTTngUST, enabled by setting CMake_TEST_FindLTTngUST. Documentation is added in Help/module/FindLTTngUST.rst. Signed-off-by: Philippe Proulx --- Help/manual/cmake-modules.7.rst | 1 + Help/module/FindLTTngUST.rst | 1 + Modules/FindLTTngUST.cmake | 111 ++++++++++++++++++++++++++ Tests/CMakeLists.txt | 4 + Tests/CMakeOnly/AllFindModules/CMakeLists.txt | 2 +- Tests/FindLTTngUST/CMakeLists.txt | 10 +++ Tests/FindLTTngUST/Test/CMakeLists.txt | 18 +++++ Tests/FindLTTngUST/Test/main.c | 31 +++++++ 8 files changed, 177 insertions(+), 1 deletion(-) create mode 100644 Help/module/FindLTTngUST.rst create mode 100644 Modules/FindLTTngUST.cmake create mode 100644 Tests/FindLTTngUST/CMakeLists.txt create mode 100644 Tests/FindLTTngUST/Test/CMakeLists.txt create mode 100644 Tests/FindLTTngUST/Test/main.c diff --git a/Help/manual/cmake-modules.7.rst b/Help/manual/cmake-modules.7.rst index 10f05df..62910cf 100644 --- a/Help/manual/cmake-modules.7.rst +++ b/Help/manual/cmake-modules.7.rst @@ -135,6 +135,7 @@ All Modules /module/FindLibLZMA /module/FindLibXml2 /module/FindLibXslt + /module/FindLTTngUST /module/FindLua50 /module/FindLua51 /module/FindLua diff --git a/Help/module/FindLTTngUST.rst b/Help/module/FindLTTngUST.rst new file mode 100644 index 0000000..a775462 --- /dev/null +++ b/Help/module/FindLTTngUST.rst @@ -0,0 +1 @@ +.. cmake-module:: ../../Modules/FindLTTngUST.cmake diff --git a/Modules/FindLTTngUST.cmake b/Modules/FindLTTngUST.cmake new file mode 100644 index 0000000..07a50ca --- /dev/null +++ b/Modules/FindLTTngUST.cmake @@ -0,0 +1,111 @@ +#.rst: +# FindLTTngUST +# ------------ +# +# This module finds the `LTTng-UST `_ library. +# +# Imported target +# ^^^^^^^^^^^^^^^ +# +# This module defines the following :prop_tgt:`IMPORTED` target: +# +# ``LTTng::UST`` +# The LTTng-UST library, if found +# +# Result variables +# ^^^^^^^^^^^^^^^^ +# +# This module sets the following +# +# ``LTTNGUST_FOUND`` +# ``TRUE`` if system has LTTng-UST +# ``LTTNGUST_INCLUDE_DIRS`` +# The LTTng-UST include directories +# ``LTTNGUST_LIBRARIES`` +# The libraries needed to use LTTng-UST +# ``LTTNGUST_VERSION_STRING`` +# The LTTng-UST version +# ``LTTNGUST_HAS_TRACEF`` +# ``TRUE`` if the ``tracef()`` API is available in the system's LTTng-UST +# ``LTTNGUST_HAS_TRACELOG`` +# ``TRUE`` if the ``tracelog()`` API is available in the system's LTTng-UST +# +#============================================================================= +# Copyright 2016 Kitware, Inc. +# Copyright 2016 Philippe Proulx +# +# Distributed under the OSI-approved BSD License (the "License"); +# see accompanying file Copyright.txt for details. +# +# This software is distributed WITHOUT ANY WARRANTY; without even the +# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +# See the License for more information. +#============================================================================= +# (To distribute this file outside of CMake, substitute the full +# License text for the above reference.) + +find_path(LTTNGUST_INCLUDE_DIRS NAMES lttng/tracepoint.h) +find_library(LTTNGUST_LIBRARIES NAMES lttng-ust) + +if(LTTNGUST_INCLUDE_DIRS AND LTTNGUST_LIBRARIES) + # find tracef() and tracelog() support + set(LTTNGUST_HAS_TRACEF 0) + set(LTTNGUST_HAS_TRACELOG 0) + + if(EXISTS "${LTTNGUST_INCLUDE_DIRS}/lttng/tracef.h") + set(LTTNGUST_HAS_TRACEF TRUE) + endif() + + if(EXISTS "${LTTNGUST_INCLUDE_DIRS}/lttng/tracelog.h") + set(LTTNGUST_HAS_TRACELOG TRUE) + endif() + + # get version + set(lttngust_version_file "${LTTNGUST_INCLUDE_DIRS}/lttng/ust-version.h") + + if(EXISTS "${lttngust_version_file}") + file(STRINGS "${lttngust_version_file}" lttngust_version_major_string + REGEX "^[\t ]*#define[\t ]+LTTNG_UST_MAJOR_VERSION[\t ]+[0-9]+[\t ]*$") + file(STRINGS "${lttngust_version_file}" lttngust_version_minor_string + REGEX "^[\t ]*#define[\t ]+LTTNG_UST_MINOR_VERSION[\t ]+[0-9]+[\t ]*$") + file(STRINGS "${lttngust_version_file}" lttngust_version_patch_string + REGEX "^[\t ]*#define[\t ]+LTTNG_UST_PATCHLEVEL_VERSION[\t ]+[0-9]+[\t ]*$") + string(REGEX REPLACE ".*([0-9]+).*" "\\1" + lttngust_v_major "${lttngust_version_major_string}") + string(REGEX REPLACE ".*([0-9]+).*" "\\1" + lttngust_v_minor "${lttngust_version_minor_string}") + string(REGEX REPLACE ".*([0-9]+).*" "\\1" + lttngust_v_patch "${lttngust_version_patch_string}") + set(LTTNGUST_VERSION_STRING + "${lttngust_v_major}.${lttngust_v_minor}.${lttngust_v_patch}") + unset(lttngust_version_major_string) + unset(lttngust_version_minor_string) + unset(lttngust_version_patch_string) + unset(lttngust_v_major) + unset(lttngust_v_minor) + unset(lttngust_v_patch) + endif() + + unset(lttngust_version_file) + + if(NOT TARGET LTTng::UST) + add_library(LTTng::UST UNKNOWN IMPORTED) + set_target_properties(LTTng::UST PROPERTIES + INTERFACE_INCLUDE_DIRECTORIES "${LTTNGUST_INCLUDE_DIRS}" + INTERFACE_LINK_LIBRARIES ${CMAKE_DL_LIBS} + IMPORTED_LINK_INTERFACE_LANGUAGES "C" + IMPORTED_LOCATION "${LTTNGUST_LIBRARIES}") + endif() + + # add libdl to required libraries + set(LTTNGUST_LIBRARIES ${LTTNGUST_LIBRARIES} ${CMAKE_DL_LIBS}) +endif() + +# handle the QUIETLY and REQUIRED arguments and set LTTNGUST_FOUND to +# TRUE if all listed variables are TRUE +include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) +find_package_handle_standard_args(LTTngUST FOUND_VAR LTTNGUST_FOUND + REQUIRED_VARS LTTNGUST_LIBRARIES + LTTNGUST_INCLUDE_DIRS + VERSION_VAR LTTNGUST_VERSION_STRING) +mark_as_advanced(LTTNGUST_LIBRARIES LTTNGUST_INCLUDE_DIRS) diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt index b43275a..1e9d6f8 100644 --- a/Tests/CMakeLists.txt +++ b/Tests/CMakeLists.txt @@ -1371,6 +1371,10 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P ${CMake_SOURCE_DIR}/Utilities/Release add_subdirectory(FindJsonCpp) endif() + if(CMake_TEST_FindLTTngUST) + add_subdirectory(FindLTTngUST) + endif() + if(CMake_TEST_FindOpenSSL) add_subdirectory(FindOpenSSL) endif() diff --git a/Tests/CMakeOnly/AllFindModules/CMakeLists.txt b/Tests/CMakeOnly/AllFindModules/CMakeLists.txt index 0aad161..1f39052 100644 --- a/Tests/CMakeOnly/AllFindModules/CMakeLists.txt +++ b/Tests/CMakeOnly/AllFindModules/CMakeLists.txt @@ -81,7 +81,7 @@ endmacro() # reported. foreach(VTEST ALSA ARMADILLO BZIP2 CUPS CURL EXPAT FREETYPE GETTEXT GIT HG - HSPELL ICOTOOL JASPER LIBLZMA LIBXML2 LIBXSLT PERL PKG_CONFIG + HSPELL ICOTOOL JASPER LIBLZMA LIBXML2 LIBXSLT LTTNGUST PERL PKG_CONFIG PostgreSQL TIFF ZLIB) check_version_string(${VTEST} ${VTEST}_VERSION_STRING) endforeach() diff --git a/Tests/FindLTTngUST/CMakeLists.txt b/Tests/FindLTTngUST/CMakeLists.txt new file mode 100644 index 0000000..c9c471d --- /dev/null +++ b/Tests/FindLTTngUST/CMakeLists.txt @@ -0,0 +1,10 @@ +add_test(NAME FindLTTngUST.Test COMMAND + ${CMAKE_CTEST_COMMAND} -C $ + --build-and-test + "${CMake_SOURCE_DIR}/Tests/FindLTTngUST/Test" + "${CMake_BINARY_DIR}/Tests/FindLTTngUST/Test" + ${build_generator_args} + --build-project TestFindLTTngUST + --build-options ${build_options} + --test-command ${CMAKE_CTEST_COMMAND} -V -C $ + ) diff --git a/Tests/FindLTTngUST/Test/CMakeLists.txt b/Tests/FindLTTngUST/Test/CMakeLists.txt new file mode 100644 index 0000000..e5bd9f3 --- /dev/null +++ b/Tests/FindLTTngUST/Test/CMakeLists.txt @@ -0,0 +1,18 @@ +cmake_minimum_required(VERSION 3.5) +project(TestFindLTTngUST C) +include(CTest) + +find_package(LTTngUST REQUIRED) + +add_definitions(-DCMAKE_EXPECTED_LTTNGUST_VERSION="${LTTNGUST_VERSION_STRING}") +add_definitions(-DCMAKE_LTTNGUST_HAS_TRACEF="${LTTNGUST_HAS_TRACEF}") +add_definitions(-DCMAKE_LTTNGUST_HAS_TRACELOG="${LTTNGUST_HAS_TRACELOG}") + +add_executable(test_tgt main.c) +target_link_libraries(test_tgt LTTng::UST) +add_test(NAME test_tgt COMMAND test_tgt) + +add_executable(test_var main.c) +target_include_directories(test_var PRIVATE ${LTTNGUST_INCLUDE_DIRS}) +target_link_libraries(test_var PRIVATE ${LTTNGUST_LIBRARIES}) +add_test(NAME test_var COMMAND test_var) diff --git a/Tests/FindLTTngUST/Test/main.c b/Tests/FindLTTngUST/Test/main.c new file mode 100644 index 0000000..ac775a0 --- /dev/null +++ b/Tests/FindLTTngUST/Test/main.c @@ -0,0 +1,31 @@ +#include +#include +#include +#include + +#ifdef CMAKE_LTTNGUST_HAS_TRACEF +#include +#endif + +#ifdef CMAKE_LTTNGUST_HAS_TRACELOG +#include +#endif + +int main(void) +{ + char lttng_version_string[16]; + + snprintf(lttng_version_string, 16, "%u.%u.%u", LTTNG_UST_MAJOR_VERSION, + LTTNG_UST_MINOR_VERSION, LTTNG_UST_PATCHLEVEL_VERSION); + assert(!strcmp(lttng_version_string, CMAKE_EXPECTED_LTTNGUST_VERSION)); + +#ifdef CMAKE_LTTNGUST_HAS_TRACEF + tracef("calling tracef()! %d %s", -23, CMAKE_EXPECTED_LTTNGUST_VERSION); +#endif + +#ifdef CMAKE_LTTNGUST_HAS_TRACELOG + tracelog(TRACE_WARNING, "calling tracelog()! %d", 17); +#endif + + return 0; +} -- 2.7.1 From Gilles.Khouzam at microsoft.com Mon Feb 29 12:38:54 2016 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Mon, 29 Feb 2016 17:38:54 +0000 Subject: [cmake-developers] [PATCH SET] Support of Clang/C2 compiler In-Reply-To: <56D46266.5090104@kitware.com> References: <56D46266.5090104@kitware.com> Message-ID: Yes, I have a prototype of similar changes on our for https://github.com/microsoft/cmake Honestly, Mariusz's changes are more complete (I haven't had a chance to fixup the tests. Let me try to find some time this week and examine the changes. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Monday, February 29, 2016 07:23 To: Mariusz Pluci?ski ; Gilles Khouzam Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [PATCH SET] Support of Clang/C2 compiler On 02/27/2016 09:38 AM, Mariusz Pluci?ski wrote: > select appropriate toolset - "c140_clang_3_7". CMake already has support of toolsets, so it's already possible to generate VS project with the following command: Gilles, IIRC you have been working on support for this too. Please take a look to see how the work can be integrated to add support for this. Thanks, -Brad