From brad.king at kitware.com Tue Sep 1 08:57:51 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 01 Sep 2015 08:57:51 -0400 Subject: [cmake-developers] [PATCH] Tests: Use a less strict regular expression to look for "SONAME". In-Reply-To: <1441059937-17067-1-git-send-email-rakuco@FreeBSD.org> References: <1441059937-17067-1-git-send-email-rakuco@FreeBSD.org> Message-ID: <55E5A0CF.4030208@kitware.com> On 08/31/2015 06:25 PM, Raphael Kubo da Costa wrote: > Commit 899458ab ("Tests: Cover NO_SONAME property for SHARED libraries") > introduced a few new ExportImport tests, and the > check_lib_{no}soname.cmake scripts that parse readelf(1)'s output. > > Make the regular expression matching the SONAME line output by readelf > less strict, as the output format varies across implementations Thanks! The changes look good, but perhaps more are needed. The same regex appears in Tests/Plugin/check_mod_soname.cmake and has for years. I think that one should be updated too, but I wonder why this problem has not been revealed in that test before. Thanks, -Brad From rakuco at FreeBSD.org Tue Sep 1 09:30:26 2015 From: rakuco at FreeBSD.org (Raphael Kubo da Costa) Date: Tue, 01 Sep 2015 15:30:26 +0200 Subject: [cmake-developers] [PATCH] Tests: Use a less strict regular expression to look for "SONAME". References: <1441059937-17067-1-git-send-email-rakuco@FreeBSD.org> <55E5A0CF.4030208@kitware.com> Message-ID: <86zj16gtcd.fsf@FreeBSD.org> Brad King writes: > The same regex appears in > > Tests/Plugin/check_mod_soname.cmake > > and has for years. I think that one should be updated too, but I > wonder why this problem has not been revealed in that test before. That's because that script is asserting that the regular expression does _not_ match, which is always the case when GNU binutils is not used. I'll send another version of the patch fixing this one as well. From rakuco at FreeBSD.org Tue Sep 1 09:33:15 2015 From: rakuco at FreeBSD.org (Raphael Kubo da Costa) Date: Tue, 1 Sep 2015 15:33:15 +0200 Subject: [cmake-developers] [PATCH v2] Tests: Use a less strict regular expression to look for "SONAME". Message-ID: <1441114395-1618-1-git-send-email-rakuco@FreeBSD.org> Commit 899458ab ("Tests: Cover NO_SONAME property for SHARED libraries") introduced a few new ExportImport tests, and the check_lib_{no}soname.cmake scripts that parse readelf(1)'s output. Make the regular expression matching the SONAME line output by readelf less strict, as the output format varies across implementations: GNU binutils' readelf is the only one to write each ELF header within parentheses (which the previous regular expression expected). The new tests were thus failing when either Fedora's elfutils (eu-readelf) or elftoolchain's readelf (present on recent FreeBSD versions) were being used, as they both list the headers without parentheses. The same issue also affected Tests/Plugin's check_mod_soname.cmake, so fix that one as well -- the only reason the test was not failing is that it tested that the regular expression did not match, which was always the case with a non-binutils readelf. --- Tests/ExportImport/Import/A/check_lib_nosoname.cmake | 2 +- Tests/ExportImport/Import/A/check_lib_soname.cmake | 2 +- Tests/Plugin/check_mod_soname.cmake | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Tests/ExportImport/Import/A/check_lib_nosoname.cmake b/Tests/ExportImport/Import/A/check_lib_nosoname.cmake index 6261ff4..613391e 100644 --- a/Tests/ExportImport/Import/A/check_lib_nosoname.cmake +++ b/Tests/ExportImport/Import/A/check_lib_nosoname.cmake @@ -1,5 +1,5 @@ execute_process(COMMAND ${readelf} -d ${lib} OUTPUT_FILE ${lib}.readelf.txt) -file(STRINGS ${lib}.readelf.txt soname REGEX "\\(SONAME\\)") +file(STRINGS ${lib}.readelf.txt soname REGEX "SONAME") if(soname) message(FATAL_ERROR "${lib} has soname but should not:\n ${soname}") else() diff --git a/Tests/ExportImport/Import/A/check_lib_soname.cmake b/Tests/ExportImport/Import/A/check_lib_soname.cmake index 7794e80..a3c4b54 100644 --- a/Tests/ExportImport/Import/A/check_lib_soname.cmake +++ b/Tests/ExportImport/Import/A/check_lib_soname.cmake @@ -1,5 +1,5 @@ execute_process(COMMAND ${readelf} -d ${lib} OUTPUT_FILE ${lib}.readelf.txt) -file(STRINGS ${lib}.readelf.txt soname REGEX "\\(SONAME\\)") +file(STRINGS ${lib}.readelf.txt soname REGEX "SONAME") if(soname) message(STATUS "${lib} has soname as expected:\n ${soname}") else() diff --git a/Tests/Plugin/check_mod_soname.cmake b/Tests/Plugin/check_mod_soname.cmake index 21a33b1..eeededa 100644 --- a/Tests/Plugin/check_mod_soname.cmake +++ b/Tests/Plugin/check_mod_soname.cmake @@ -1,5 +1,5 @@ execute_process(COMMAND ${readelf} -d ${mod} OUTPUT_FILE ${mod}.readelf.txt) -file(STRINGS ${mod}.readelf.txt soname REGEX "\\(SONAME\\)") +file(STRINGS ${mod}.readelf.txt soname REGEX "SONAME") if(soname) message(FATAL_ERROR "${mod} has soname but should not:\n ${soname}") else() -- 2.4.6 From brad.king at kitware.com Tue Sep 1 09:39:07 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 01 Sep 2015 09:39:07 -0400 Subject: [cmake-developers] [PATCH] Tests: Use a less strict regular expression to look for "SONAME". In-Reply-To: <86zj16gtcd.fsf@FreeBSD.org> References: <1441059937-17067-1-git-send-email-rakuco@FreeBSD.org> <55E5A0CF.4030208@kitware.com> <86zj16gtcd.fsf@FreeBSD.org> Message-ID: <55E5AA7B.3050708@kitware.com> On 09/01/2015 09:30 AM, Raphael Kubo da Costa wrote: > That's because that script is asserting that the regular expression does > _not_ match, which is always the case when GNU binutils is not used. Prior to the refactoring it also tested for existence. See below. How did that pass before? Thanks, -Brad $ git show v3.3.1:Tests/Plugin/check_mod_soname.cmake execute_process(COMMAND ${readelf} -d ${mod1} OUTPUT_FILE ${mod1}.readelf.txt) execute_process(COMMAND ${readelf} -d ${mod2} OUTPUT_FILE ${mod2}.readelf.txt) file(STRINGS ${mod1}.readelf.txt soname1 REGEX "\\(SONAME\\)") file(STRINGS ${mod2}.readelf.txt soname2 REGEX "\\(SONAME\\)") if(soname1) message(STATUS "${mod1} has soname as expected: ${soname1}") else() message(FATAL_ERROR "${mod1} has no soname but should:\n ${soname1}") endif() if(soname2) message(FATAL_ERROR "${mod2} has soname but should not:\n ${soname2}") else() message(STATUS "${mod2} has no soname as expected") endif() From rakuco at FreeBSD.org Tue Sep 1 10:13:05 2015 From: rakuco at FreeBSD.org (Raphael Kubo da Costa) Date: Tue, 01 Sep 2015 16:13:05 +0200 Subject: [cmake-developers] [PATCH] Tests: Use a less strict regular expression to look for "SONAME". References: <1441059937-17067-1-git-send-email-rakuco@FreeBSD.org> <55E5A0CF.4030208@kitware.com> <86zj16gtcd.fsf@FreeBSD.org> <55E5AA7B.3050708@kitware.com> Message-ID: <86wpwai5xq.fsf@FreeBSD.org> Brad King writes: > On 09/01/2015 09:30 AM, Raphael Kubo da Costa wrote: >> That's because that script is asserting that the regular expression does >> _not_ match, which is always the case when GNU binutils is not used. > > Prior to the refactoring it also tested for existence. See below. > How did that pass before? Interesting. I think it has always been "broken". >From a FreeBSD perspective (now that I'm getting its nightly test results back on track), what happened is that all FreeBSD releases so far use GNU binutils by default, and the switch to the elftoolchain utilities has been happening in HEAD (that's going to be FreeBSD 11). The readelf switch happened at the end of March, the machine stopped producing results in early April and thus this combination had never been tested until yesterday. From brad.king at kitware.com Tue Sep 1 10:27:47 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 01 Sep 2015 10:27:47 -0400 Subject: [cmake-developers] [PATCH] Tests: Use a less strict regular expression to look for "SONAME". In-Reply-To: <86wpwai5xq.fsf@FreeBSD.org> References: <1441059937-17067-1-git-send-email-rakuco@FreeBSD.org> <55E5A0CF.4030208@kitware.com> <86zj16gtcd.fsf@FreeBSD.org> <55E5AA7B.3050708@kitware.com> <86wpwai5xq.fsf@FreeBSD.org> Message-ID: <55E5B5E3.3030507@kitware.com> On 09/01/2015 10:13 AM, Raphael Kubo da Costa wrote: > Interesting. I think it has always been "broken". > > From a FreeBSD perspective (now that I'm getting its nightly test > results back on track), what happened is that all FreeBSD releases so > far use GNU binutils by default, and the switch to the elftoolchain > utilities has been happening in HEAD (that's going to be FreeBSD 11). > The readelf switch happened at the end of March, the machine stopped > producing results in early April and thus this combination had never > been tested until yesterday. Okay, thanks for that explanation. I'll apply patch v2. Thanks, -Brad From brad.king at kitware.com Tue Sep 1 10:31:02 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 01 Sep 2015 10:31:02 -0400 Subject: [cmake-developers] [PATCH v2] Tests: Use a less strict regular expression to look for "SONAME". In-Reply-To: <1441114395-1618-1-git-send-email-rakuco@FreeBSD.org> References: <1441114395-1618-1-git-send-email-rakuco@FreeBSD.org> Message-ID: <55E5B6A6.3040403@kitware.com> On 09/01/2015 09:33 AM, Raphael Kubo da Costa wrote: > Make the regular expression matching the SONAME line output by readelf > less strict, as the output format varies across implementations Applied, thanks: Tests: Use a less strict regular expression to look for "SONAME" http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=21d99aa3 -Brad From steveire at gmail.com Tue Sep 1 12:54:14 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 1 Sep 2015 18:54:14 +0200 Subject: [cmake-developers] refactor-progress topic regressed Makefile progress In-Reply-To: <55E467C4.1080704@kitware.com> References: <55E467C4.1080704@kitware.com> Message-ID: On Mon, Aug 31, 2015 at 4:42 PM, Brad King wrote: > During the actual build I get no progress output either. > The problem bisects to: > > cmGlobalUnixMakefileGenerator3: Implement progress in terms of cmState. > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7fbc56ac > > Please take a look. Sorry about that. That commit changed the container key from something unique - there is one cmLocalGenerator per directory - to something not unique - there are multiple snapshots per directory. The cmGlobalUnixMakefileGenerator3::InitializeProgressMarks() method should always use a predicable snapshot, and the ::CountProgressMarksInAll should use the same predicable one. The last snapshot for a directory should be the predictable one to use. I made the attached patch to make cmState::GetBuildsystemDirectoryParent always return the last snapshot for a directory, which will make sense anyway when properties are versioned. That should account for one of the callers because it is always called after Configure() is finished, so the last snapshot is known. The ::CountProgressMarksInAll uses cmLocalGenerator::GetStateSnapshot, which is recorded when the cmLocalGenerator is created (so in master it is not the last snapshot for the directory). That would not be a problem if commit 7ccd4a7ceeeb5ec04c62cf5c2c6f7e31430bc254 had passed CI, but the other attached patch should be enough to fix it too. Unfortunately I won't have time until next week to verify this or to work on getting the fix through CI, so if you can, please verify my clams and take the patches from here. Thanks, Steve. -------------- next part -------------- A non-text attachment was scrubbed... Name: fix.patch Type: application/octet-stream Size: 866 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: possibly.patch Type: application/octet-stream Size: 710 bytes Desc: not available URL: From michael.scott250 at gmail.com Tue Sep 1 15:56:49 2015 From: michael.scott250 at gmail.com (Michael Scott) Date: Tue, 1 Sep 2015 20:56:49 +0100 Subject: [cmake-developers] FindZLIB module should find debug and, release variants In-Reply-To: <55E49088.4040106@kitware.com> References: <55E49088.4040106@kitware.com> Message-ID: <55E60301.1040601@gmail.com> > Thanks. We also need to be compatible with projects or scripts that > set ZLIB_LIBRARY themselves. The attached patch should maintain that compatibility now. If ZLIB_LIBRARY is set manually, then it won't try and find the library and it'll set the ZLIB_LIBRARIES and IMPORTED_LOCATION variables using the provided ZLIB_LIBRARY variable (if the library was found). Cheers, Michael -------------- next part -------------- From c7905e97fa0a1412a1b05ee295d4bfa97c699b3e Mon Sep 17 00:00:00 2001 From: Michael Scott Date: Tue, 1 Sep 2015 20:41:27 +0100 Subject: [PATCH] Support finding the debug and release variants as separate libraries, providing each variant in ZLIB_LIBRARIES and ZLIB::ZLIB's imported location properties when one is found, while maintaining support for manually setting the library via ZLIB_LIBRARY. --- Modules/FindZLIB.cmake | 45 ++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 40 insertions(+), 5 deletions(-) diff --git a/Modules/FindZLIB.cmake b/Modules/FindZLIB.cmake index d4a27d5..88aac56 100644 --- a/Modules/FindZLIB.cmake +++ b/Modules/FindZLIB.cmake @@ -74,14 +74,28 @@ set(_ZLIB_SEARCH_NORMAL ) list(APPEND _ZLIB_SEARCHES _ZLIB_SEARCH_NORMAL) -set(ZLIB_NAMES z zlib zdll zlib1 zlibd zlibd1) +set(ZLIB_NAMES z zlib zdll zlib1) +set(ZLIB_NAMES_DEBUG zlibd zlibd1) # Try each search configuration. foreach(search ${_ZLIB_SEARCHES}) - find_path(ZLIB_INCLUDE_DIR NAMES zlib.h ${${search}} PATH_SUFFIXES include) - find_library(ZLIB_LIBRARY NAMES ${ZLIB_NAMES} ${${search}} PATH_SUFFIXES lib) + find_path(ZLIB_INCLUDE_DIR NAMES zlib.h ${${search}} PATH_SUFFIXES include) endforeach() +# Allow ZLIB_LIBRARY to be set manually, as the location of the zlib library +if(NOT ZLIB_LIBRARY) + foreach(search ${_ZLIB_SEARCHES}) + find_library(ZLIB_LIBRARY_RELEASE NAMES ${ZLIB_NAMES} ${${search}} PATH_SUFFIXES lib) + find_library(ZLIB_LIBRARY_DEBUG NAMES ${ZLIB_NAMES_DEBUG} ${${search}} PATH_SUFFIXES lib) + endforeach() + + include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake) + select_library_configurations(ZLIB) +endif() + +unset(ZLIB_NAMES) +unset(ZLIB_NAMES_DEBUG) + mark_as_advanced(ZLIB_LIBRARY ZLIB_INCLUDE_DIR) if(ZLIB_INCLUDE_DIR AND EXISTS "${ZLIB_INCLUDE_DIR}/zlib.h") @@ -112,12 +126,33 @@ FIND_PACKAGE_HANDLE_STANDARD_ARGS(ZLIB REQUIRED_VARS ZLIB_LIBRARY ZLIB_INCLUDE_D if(ZLIB_FOUND) set(ZLIB_INCLUDE_DIRS ${ZLIB_INCLUDE_DIR}) - set(ZLIB_LIBRARIES ${ZLIB_LIBRARY}) + + if(NOT ZLIB_LIBRARIES) + set(ZLIB_LIBRARIES ${ZLIB_LIBRARY}) + endif() if(NOT TARGET ZLIB::ZLIB) add_library(ZLIB::ZLIB UNKNOWN IMPORTED) set_target_properties(ZLIB::ZLIB PROPERTIES - IMPORTED_LOCATION "${ZLIB_LIBRARY}" INTERFACE_INCLUDE_DIRECTORIES "${ZLIB_INCLUDE_DIRS}") + + if(ZLIB_LIBRARY_RELEASE) + set_property(TARGET ZLIB::ZLIB APPEND PROPERTY + IMPORTED_CONFIGURATIONS RELEASE) + set_target_properties(ZLIB::ZLIB PROPERTIES + IMPORTED_LOCATION_RELEASE "${ZLIB_LIBRARY_RELEASE}") + endif() + + if(ZLIB_LIBRARY_DEBUG) + set_property(TARGET ZLIB::ZLIB APPEND PROPERTY + IMPORTED_CONFIGURATIONS DEBUG) + set_target_properties(ZLIB::ZLIB PROPERTIES + IMPORTED_LOCATION_DEBUG "${ZLIB_LIBRARY_DEBUG}") + endif() + + if(NOT ZLIB_LIBRARY_RELEASE AND NOT ZLIB_LIBRARY_DEBUG) + set_property(TARGET ZLIB::ZLIB APPEND PROPERTY + IMPORTED_LOCATION "${ZLIB_LIBRARY}") + endif() endif() endif() -- 2.1.4 From Gilles.Khouzam at microsoft.com Tue Sep 1 17:09:16 2015 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Tue, 1 Sep 2015 21:09:16 +0000 Subject: [cmake-developers] [Patch] Build Windows Phone/Store 8.1 on VS 2015 Message-ID: Fixing issue: https://public.kitware.com/Bug/view.php?id=15662 [CMake 0015662]: Add support for Windows/Windows Phone SDKs with Visual Studio 2015 The issue raised it caused by the fact that we were validating that we have a desktop SDK based on the version of the app what we are producing instead of the generator being used. By making the method virtual, we can query that we have the desktop SDK installed for the generator selected. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Build8.1OnVS2015.patch Type: application/octet-stream Size: 3741 bytes Desc: Build8.1OnVS2015.patch URL: From Gilles.Khouzam at microsoft.com Tue Sep 1 17:19:27 2015 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Tue, 1 Sep 2015 21:19:27 +0000 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: <55E4B396.9090609@kitware.com> References: <55E4B396.9090609@kitware.com> Message-ID: Hi Brad, Thanks for the feedback. I've extracted the change to build Windows 8.1 on VS 2015 and submitted it as a separate change. Windows 10 support will need to be built on top of the other change since they share some of the same code. For VS_DEFAULT_TARGET_PLATFORM_VERSION, what I'm trying to achieve is almost an internal property that is used for the try_compile phase. Since the generator is not used in that scenario, the project is using the template from Modules/CompilerId/VS-10.vcxproj.in. In that case, we need to set the tag for the WindowsTargetPlatformVersion. During the generation, I query for the latest SDK version in the GlobalGenerator and set the VS_DEFAULT_TARGET_PLATFORM_VERSION property that is then used in CMakeDetermineCompilerId.cmake to set the variable that the template uses in the Windows 10 case. I'm not sure if there's a different/better way to handle this case. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Monday, August 31, 2015 13:06 To: Gilles Khouzam Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 08/30/2015 06:41 PM, Gilles Khouzam wrote: > http://www.cmake.org/Bug/view.php?id=15670 > Add support for setting "Windows target platform version" in VS2015 Most of your changes look good but I think this issue needs more discussion. There is already some discussion in the issue tracker entry linked above. Your patch checks a VS_DEFAULT_TARGET_PLATFORM_VERSION variable but does not document it or explain who/what is supposed to set it. There is a comment about using the latest SDK but right now it looks like the value of that variable is used directly. Having a VS_TARGET_PLATFORM_VERSION target property is convenient for customization but should not be the main way to set this value. The WindowsTargetPlatformVersion value is something that should be set in try_compile projects too for consistency. If we were only cross-compiling then having a toolchain file setting would make sense. However, this should work when not cross-compiling too. On OS X we have CMAKE_OSX_SYSROOT to specify the SDK. The value is propagated by Source/cmCoreTryCompile.cxx into try_compile projects. It is selected originally by Modules/Platform/Darwin-Initialize.cmake if not specified by the user. I think similar infrastructure should be built for selecting the Windows SDK. > As part of this change, I'm also fixing a bug when using VS2015 to > target Windows Phone or Windows Store 8.1 without having VS2013 [snip] > simply to make the desktop detection code be virtual. Please split the relevant hunks for that part out so they can be committed with their own message/explanation. Thanks, -Brad From marc.chevrier at sap.com Wed Sep 2 05:31:33 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Wed, 2 Sep 2015 09:31:33 +0000 Subject: [cmake-developers] [BUG] HINTS not correctly handled in find_program Message-ID: Hi, I discovered a curious problem regarding handling of argument HINTS. If I use the following command: find_program (MY_EXE my_exe HINTS PATH1 PATH2 PATH3) And my_exe is available in various paths. In this case, paths specified in HINTS AND also defined in environment variable PATH are ignored ! For example, with environment variable PATH=PATH1:PATH2, find_program will gives PATH3/my_exe as result. This problem occurs on Windows and Linux (at least) in versions 3.2.1 and 3.3.1. The behavior is correct with version 3.1.3. Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gvjung at gmail.com Wed Sep 2 05:33:33 2015 From: gvjung at gmail.com (Greg Jung) Date: Wed, 2 Sep 2015 02:33:33 -0700 Subject: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion In-Reply-To: References: Message-ID: To revive this issue, I show a comparison of the CMakeCache entries for cmake run from the same configuration, 1) cmake 3.2.3 with "old" PythonLibs .vs. 2) cmake 3.3.1 with the new FindPythonLibs.cmake. Cmake 1): # This is the CMakeCache file. # For build in directory: d:/mingw/msys32/tmp/bld-32 # It was generated by CMake: D:/mingw/msys32/mingw32/bin/cmake.exe [...] //Path to a program. PYTHON_EXECUTABLE:FILEPATH=D:/mingw/msys32/mingw32/bin/python.exe //Path to a file. PYTHON_INCLUDE_DIR:PATH=D:/mingw/msys32/mingw32/include/python2.7 //Path to a library. PYTHON_LIBRARY:FILEPATH=E:/Python27/libs/libpython27.a //Dependencies for the target _plplotcmodule_LIB_DEPENDS:STATIC=general;plplot;general;E:/Python27/libs/libpython27.a; //Dependencies for the target plplot_widgetmodule_LIB_DEPENDS:STATIC=general;plplot;general;E:/Python27/libs/libpython27.a; //Path to CMake executable. CMAKE_COMMAND:INTERNAL=D:/mingw/msys32/mingw32/bin/cmake.exe //Details about finding PythonLibs FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[E:/Python27/libs/libpython27.a][D:/mingw/msys32/mingw32/include/python2.7][v2.7.10()] Cmake 2): cmake 3.3.1 run from outside the msys tree,using the patched FindPythonLibs.cmake # This is the CMakeCache file. # For build in directory: d:/mingw/msys32/tmp/bld-32 # It was generated by CMake: D:/programs/CMake-3.3/bin/cmake.exe [...] //Path to a program. PYTHON_EXECUTABLE:FILEPATH=D:/mingw/msys32/mingw32/bin/python.exe //Path to a file. PYTHON_INCLUDE_DIR:PATH=D:/mingw/msys32/mingw32/include/python2.7 //Path to a library. PYTHON_LIBRARY:FILEPATH=D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a //Dependencies for the target _plplotcmodule_LIB_DEPENDS:STATIC=general;plplot;general;D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a; //Dependencies for the target plplot_widgetmodule_LIB_DEPENDS:STATIC=general;plplot;general;D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a; //Path to CMake executable. CMAKE_COMMAND:INTERNAL=D:/programs/CMake-3.3/bin/cmake.exe //Details about finding PythonLibs FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a][D:/mingw/msys32/mingw32/include/python2.7][v2.7.10()] So, my windows-y python installation which is registered in the windows registry, interferes with my use of python until I replace the FindPythonLibs.cmake with the modified version. The new routine will find the registry version in the same manner if (WIN32 AND NOT (MINGW OR MSYS)). Someone using this routine from windows (MSVC) or from a non-win32 environment should have the same results as before. If the MSYS user only has a separate windows-based registry-registered python and there is nothing found in the unix-style searches, the previous behavior of providing answers from the registry-based installation kicks in. Regards, Greg On Fri, Aug 7, 2015 at 4:05 PM, Greg Jung wrote: > > I have two changes in FindPythonLibs that should make for less failure >> in >> > the MINGW/MSYS camp. >> >> While I support this stuff, I think for it to not >> break other people (who use either mingw.org/MinGW-w64 compilers or >> the old MSYS with 'normal' Windows CPython), > > > If there is not a python installation to be found in the mingw path, the > patched routine will drop into the registry search. which will look > exactly like previous. > > I think you explicitly mean the MSYS2 camp here. We have our own >> Pythons (4 of them, 2 native and 2 cygwin-y) all of which use a >> Linux-y layout. > > > I've been running with msys2, and lately I've done a lot of test-running > of plplot using plain vanilla > CMake without the patches I used to think were needed. I found that from > the CMake point of view, > msys1 or msys2 is a distinction without a difference. > > >> CMake needs to be able to >> identify MSYS2 distinctly from both MINGW and MSYS first. Would a >> patch making that distinction be acceptable to CMake? > > I have used CMakeFindMSYSmake and CMakeFindUnixMake to set a variable > designating > what /usr translates to: > # > # the variable MSYS_USR_PATH is here created for use > # where the /usr provided by an MSYS app needs to be translated for > Windows. > # > unset(_BIN) > find_path( _BIN msys-1.0.dll NAMES msys-2.0.dll HINTS ENV PATH > NO_DEFAULT_PATH) > if(_BIN) > set(MSYS 1) > find_path( MSYS_USR_PATH bin PATHS ${_BIN}/../ NO_DEFAULT_PATH) > > mark_as_advanced(MSYS_USR_PATH) > message(STATUS ": MSYS dll found on > ${MSYS_USR_PATH}") > endif() > unset(_BIN) > > > > > On Fri, Aug 7, 2015 at 2:25 AM, Ray Donnelly > wrote: > >> On Fri, Aug 7, 2015 at 7:58 AM, Greg Jung wrote: >> > Hi there, >> > A patch for review: >> > >> > I have two changes in FindPythonLibs that should make for less >> failure in >> > the MINGW/MSYS camp. >> >> I think you explicitly mean the MSYS2 camp here. We have our own >> Pythons (4 of them, 2 native and 2 cygwin-y) all of which use a >> Linux-y layout. While I support this stuff, I think for it to not >> break other people (who use either mingw.org/MinGW-w64 compilers or >> the old MSYS with 'normal' Windows CPython), CMake needs to be able to >> identify MSYS2 distinctly from both MINGW and MSYS first. Would a >> patch making that distinction be acceptable to CMake? >> >> > 1. Distinguish mingw and win32. Avoid the registry lookup. >> > if(WIN32) => if(WIN32 AND NOT (MINGW OR MSYS)) for the DEBUG library >> search, >> > a full unix-style find_library call without reference to possible >> registry >> > entries. >> > >> > + NAMES >> > + python${_CURRENT_VERSION_NO_DOTS} >> > + python${_CURRENT_VERSION}mu >> > + python${_CURRENT_VERSION}m >> > + python${_CURRENT_VERSION}u >> > + python${_CURRENT_VERSION} >> > +# >> > + NAMES_PER_DIR >> > + # Avoid finding the .dll in the PATH. We want the .lib. >> > +# The NAMES_PER_DIR above should allow the library to be found where >> it was >> > desired >> > +# in the prioritized location of PATH - cmake V3.3 behavior; >> > +# NO_SYSTEM_ENVIRONMENT_PATH works counter to cmake-3.3 improvement >> > where CMake will look into path. >> > +# >> > + ) >> > +endif() >> > >> > 2. NAMES_PER_DIR replaces NO_SYSTEM_ENVIRONMENT_PATH to modify the >> search >> > such that windows/system32/python27.dll >> > (for instance) is not picked up before finding the proper library under >> > /lib >> > >> > >> > Instead of throwing all of the possible locations into a single >> > find_library(), for WIN32+MINGW builds this may latch into a windows' >> > python. >> > This is not an issue when CMake is run from /MINGW. >> > CMake-3.3.0 (and above) can use PATH to discover targets of >> find_library, >> > allowing >> > a user with several MINGW installations to use a single cmake (and >> > cmake-gui) instead of >> > installing several copies for each mingw to be built with. Unless the >> > find_path or >> > find_library uses "NO_SYSTEM_ENVIRONMENT_PATH" which kills the new >> feature. >> > Even though /mingw32/bin is frontmost in the path, >> > windows/system32/python27.dll >> > was latched onto because the name matches earlier in the NAMES list than >> > python2.7. >> > to avoid this all of the names are tested as the direcftories are >> presented, >> > this via the >> > NAMES_PER_DIR qualifier. >> > >> > This makes is possible for me to run builds using Cmake-gui without >> > installing cmake-gui >> > in /mingw32/bin (and qt5 along with it!). >> > >> > Regards, >> > Greg >> > >> > -- >> > >> > 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 mantis at public.kitware.com Wed Sep 2 06:32:00 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 2 Sep 2015 06:32:00 -0400 Subject: [cmake-developers] [CMake 0015723]: Regression: FindCUDA fails for C++ only projects in CMake 3.3.1 due find_package(Threads), while it works well in CMake 3.2.3 Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15723 ====================================================================== Reported By: Adam Strzelecki Assigned To: ====================================================================== Project: CMake Issue ID: 15723 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-02 06:31 EDT Last Modified: 2015-09-02 06:31 EDT ====================================================================== Summary: Regression: FindCUDA fails for C++ only projects in CMake 3.3.1 due find_package(Threads), while it works well in CMake 3.2.3 Description: CUDA language is C++ superset, so developers may prefer using C++ only project together with CUDA. FindCUDA already supports such case (1) when neither CUDA_HOST_COMPILER nor CMAKE_C_COMPILER is defined, just skips adding --ccbin. Another case (2) is that user defined its own CUDA_HOST_COMPILER that is different than CMAKE_C_COMPILER, then custom host compiler is passed to --ccbin. The problem is that recently CUDA_USE_STATIC_CUDA_RUNTIME (default ON) started calling find_package(Threads REQUIRED) that tries to lookup pthread using CMAKE_C_COMPILER which is invalid in both cases (1) (2). However I don't see any clear solution here. I understand that linking CUDA static rt requires pthread linkage, but maybe we should just check if current linker can either link -lpthread or -pthread, rather falling back to C compiler that may be undefined for the project? Steps to Reproduce: # CMakeList.txt cmake_minimum_required(VERSION 2.6) project(OnlyCXXCUDA CXX) find_package(CUDA) $ cmake . -- The CXX compiler identification is AppleClang 7.0.0.7000059 -- Check for working CXX compiler: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- Check for working CXX compiler: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Looking for include file pthread.h CMake Error at /Applications/CMake.app/Contents/share/cmake-3.3/Modules/CheckIncludeFiles.cmake:79 (try_compile): Unknown extension ".c" for file /Users/ono/Documents/Bugs/CMake/FindCUDA/CMakeFiles/CMakeTmp/CheckIncludeFiles.c try_compile() works only for enabled languages. Currently these are: CXX See project() command to enable other languages. Call Stack (most recent call first): /Applications/CMake.app/Contents/share/cmake-3.3/Modules/FindThreads.cmake:123 (CHECK_INCLUDE_FILES) /Applications/CMake.app/Contents/share/cmake-3.3/Modules/FindCUDA.cmake:741 (find_package) CMakeLists.txt:3 (find_package) -- Looking for include file pthread.h - not found CMake Error at /Applications/CMake.app/Contents/share/cmake-3.3/Modules/FindPackageHandleStandardArgs.cmake:148 (message): Could NOT find Threads (missing: Threads_FOUND) Call Stack (most recent call first): /Applications/CMake.app/Contents/share/cmake-3.3/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE) /Applications/CMake.app/Contents/share/cmake-3.3/Modules/FindThreads.cmake:204 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) /Applications/CMake.app/Contents/share/cmake-3.3/Modules/FindCUDA.cmake:741 (find_package) CMakeLists.txt:3 (find_package) -- Configuring incomplete, errors occurred! See also "/Users/ono/Documents/Bugs/CMake/FindCUDA/CMakeFiles/CMakeOutput.log". See also "/Users/ono/Documents/Bugs/CMake/FindCUDA/CMakeFiles/CMakeError.log". ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-02 06:31 Adam StrzeleckiNew Issue ====================================================================== From mingw.android at gmail.com Wed Sep 2 07:13:39 2015 From: mingw.android at gmail.com (Ray Donnelly) Date: Wed, 2 Sep 2015 12:13:39 +0100 Subject: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion In-Reply-To: References: Message-ID: On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung wrote: > To revive this issue, I show a comparison of the CMakeCache entries for > cmake run from the same configuration, 1) cmake 3.2.3 with "old" PythonLibs > .vs. 2) cmake 3.3.1 with the new FindPythonLibs.cmake. > > Cmake 1): > > # This is the CMakeCache file. > # For build in directory: d:/mingw/msys32/tmp/bld-32 > # It was generated by CMake: D:/mingw/msys32/mingw32/bin/cmake.exe > [...] > //Path to a program. > PYTHON_EXECUTABLE:FILEPATH=D:/mingw/msys32/mingw32/bin/python.exe > > //Path to a file. > PYTHON_INCLUDE_DIR:PATH=D:/mingw/msys32/mingw32/include/python2.7 > > //Path to a library. > PYTHON_LIBRARY:FILEPATH=E:/Python27/libs/libpython27.a > > //Dependencies for the target > _plplotcmodule_LIB_DEPENDS:STATIC=general;plplot;general;E:/Python27/libs/libpython27.a; > > //Dependencies for the target > plplot_widgetmodule_LIB_DEPENDS:STATIC=general;plplot;general;E:/Python27/libs/libpython27.a; > //Path to CMake executable. > CMAKE_COMMAND:INTERNAL=D:/mingw/msys32/mingw32/bin/cmake.exe > //Details about finding PythonLibs > FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[E:/Python27/libs/libpython27.a][D:/mingw/msys32/mingw32/include/python2.7][v2.7.10()] > > > Cmake 2): cmake 3.3.1 run from outside the msys tree,using the patched > FindPythonLibs.cmake > > # This is the CMakeCache file. > # For build in directory: d:/mingw/msys32/tmp/bld-32 > # It was generated by CMake: D:/programs/CMake-3.3/bin/cmake.exe > [...] > //Path to a program. > PYTHON_EXECUTABLE:FILEPATH=D:/mingw/msys32/mingw32/bin/python.exe > > //Path to a file. > PYTHON_INCLUDE_DIR:PATH=D:/mingw/msys32/mingw32/include/python2.7 > > //Path to a library. > PYTHON_LIBRARY:FILEPATH=D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a > > //Dependencies for the target > _plplotcmodule_LIB_DEPENDS:STATIC=general;plplot;general;D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a; > > //Dependencies for the target > plplot_widgetmodule_LIB_DEPENDS:STATIC=general;plplot;general;D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a; > //Path to CMake executable. > CMAKE_COMMAND:INTERNAL=D:/programs/CMake-3.3/bin/cmake.exe > //Details about finding PythonLibs > FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a][D:/mingw/msys32/mingw32/include/python2.7][v2.7.10()] > > > So, my windows-y python installation which is registered in the windows > registry, interferes with my use of > python until I replace the FindPythonLibs.cmake with the modified version. > The new routine will find the registry version in the same manner if > (WIN32 AND NOT (MINGW OR MSYS)). > Would: if (MSVC) .. not be a better discriminator here? There's probably some people who use MSYS2 in conjunction with MSVC compilers. > Someone using this routine from windows (MSVC) or from a non-win32 > environment should have the same results as before. If the MSYS user only > has a separate windows-based registry-registered python > and there is nothing found in the unix-style searches, the previous behavior > of providing answers from the registry-based installation kicks in. > > Regards, Greg > > On Fri, Aug 7, 2015 at 4:05 PM, Greg Jung wrote: >>> >>> > I have two changes in FindPythonLibs that should make for less >>> > failure in >>> > the MINGW/MSYS camp. >>> >>> While I support this stuff, I think for it to not >>> break other people (who use either mingw.org/MinGW-w64 compilers or >>> the old MSYS with 'normal' Windows CPython), >> >> >> If there is not a python installation to be found in the mingw path, the >> patched routine will drop into the registry search. which will look >> exactly like previous. >> >>> I think you explicitly mean the MSYS2 camp here. We have our own >>> Pythons (4 of them, 2 native and 2 cygwin-y) all of which use a >>> Linux-y layout. >> >> >> I've been running with msys2, and lately I've done a lot of test-running >> of plplot using plain vanilla >> CMake without the patches I used to think were needed. I found that from >> the CMake point of view, >> msys1 or msys2 is a distinction without a difference. >> >>> >>> CMake needs to be able to >>> identify MSYS2 distinctly from both MINGW and MSYS first. Would a >>> patch making that distinction be acceptable to CMake? >> >> I have used CMakeFindMSYSmake and CMakeFindUnixMake to set a variable >> designating >> what /usr translates to: >> # >> # the variable MSYS_USR_PATH is here created for use >> # where the /usr provided by an MSYS app needs to be translated for >> Windows. >> # >> unset(_BIN) >> find_path( _BIN msys-1.0.dll NAMES msys-2.0.dll HINTS ENV PATH >> NO_DEFAULT_PATH) >> if(_BIN) >> set(MSYS 1) >> find_path( MSYS_USR_PATH bin PATHS ${_BIN}/../ NO_DEFAULT_PATH) >> >> mark_as_advanced(MSYS_USR_PATH) >> message(STATUS ": MSYS dll found on >> ${MSYS_USR_PATH}") >> endif() >> unset(_BIN) >> >> >> >> >> On Fri, Aug 7, 2015 at 2:25 AM, Ray Donnelly >> wrote: >>> >>> On Fri, Aug 7, 2015 at 7:58 AM, Greg Jung wrote: >>> > Hi there, >>> > A patch for review: >>> > >>> > I have two changes in FindPythonLibs that should make for less >>> > failure in >>> > the MINGW/MSYS camp. >>> >>> I think you explicitly mean the MSYS2 camp here. We have our own >>> Pythons (4 of them, 2 native and 2 cygwin-y) all of which use a >>> Linux-y layout. While I support this stuff, I think for it to not >>> break other people (who use either mingw.org/MinGW-w64 compilers or >>> the old MSYS with 'normal' Windows CPython), CMake needs to be able to >>> identify MSYS2 distinctly from both MINGW and MSYS first. Would a >>> patch making that distinction be acceptable to CMake? >>> >>> > 1. Distinguish mingw and win32. Avoid the registry lookup. >>> > if(WIN32) => if(WIN32 AND NOT (MINGW OR MSYS)) for the DEBUG library >>> > search, >>> > a full unix-style find_library call without reference to possible >>> > registry >>> > entries. >>> > >>> > + NAMES >>> > + python${_CURRENT_VERSION_NO_DOTS} >>> > + python${_CURRENT_VERSION}mu >>> > + python${_CURRENT_VERSION}m >>> > + python${_CURRENT_VERSION}u >>> > + python${_CURRENT_VERSION} >>> > +# >>> > + NAMES_PER_DIR >>> > + # Avoid finding the .dll in the PATH. We want the .lib. >>> > +# The NAMES_PER_DIR above should allow the library to be found where >>> > it was >>> > desired >>> > +# in the prioritized location of PATH - cmake V3.3 behavior; >>> > +# NO_SYSTEM_ENVIRONMENT_PATH works counter to cmake-3.3 improvement >>> > where CMake will look into path. >>> > +# >>> > + ) >>> > +endif() >>> > >>> > 2. NAMES_PER_DIR replaces NO_SYSTEM_ENVIRONMENT_PATH to modify the >>> > search >>> > such that windows/system32/python27.dll >>> > (for instance) is not picked up before finding the proper library under >>> > /lib >>> > >>> > >>> > Instead of throwing all of the possible locations into a single >>> > find_library(), for WIN32+MINGW builds this may latch into a windows' >>> > python. >>> > This is not an issue when CMake is run from /MINGW. >>> > CMake-3.3.0 (and above) can use PATH to discover targets of >>> > find_library, >>> > allowing >>> > a user with several MINGW installations to use a single cmake (and >>> > cmake-gui) instead of >>> > installing several copies for each mingw to be built with. Unless the >>> > find_path or >>> > find_library uses "NO_SYSTEM_ENVIRONMENT_PATH" which kills the new >>> > feature. >>> > Even though /mingw32/bin is frontmost in the path, >>> > windows/system32/python27.dll >>> > was latched onto because the name matches earlier in the NAMES list >>> > than >>> > python2.7. >>> > to avoid this all of the names are tested as the direcftories are >>> > presented, >>> > this via the >>> > NAMES_PER_DIR qualifier. >>> > >>> > This makes is possible for me to run builds using Cmake-gui without >>> > installing cmake-gui >>> > in /mingw32/bin (and qt5 along with it!). >>> > >>> > Regards, >>> > Greg >>> > >>> > -- >>> > >>> > 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 Wed Sep 2 08:58:54 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 02 Sep 2015 08:58:54 -0400 Subject: [cmake-developers] [BUG] HINTS not correctly handled in find_program In-Reply-To: References: Message-ID: <55E6F28E.1080706@kitware.com> On 09/02/2015 05:31 AM, CHEVRIER, Marc wrote: > find_program (MY_EXE my_exe HINTS PATH1 PATH2 PATH3) Try it with find_program (MY_EXE NAMES my_exe HINTS PATH1 PATH2 PATH3 ) -Brad From brad.king at kitware.com Wed Sep 2 09:02:28 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 02 Sep 2015 09:02:28 -0400 Subject: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion In-Reply-To: References: Message-ID: <55E6F364.7050103@kitware.com> On 09/02/2015 07:13 AM, Ray Donnelly wrote: > On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung wrote: >> To revive this issue, I show a comparison of the CMakeCache entries for >> cmake run from the same configuration, 1) cmake 3.2.3 with "old" PythonLibs >> .vs. 2) cmake 3.3.1 with the new FindPythonLibs.cmake. As a reminder, another branch of this discussion is pending over here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13948/focus=13982 -Brad From marc.chevrier at sap.com Wed Sep 2 09:09:16 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Wed, 2 Sep 2015 13:09:16 +0000 Subject: [cmake-developers] [BUG] HINTS not correctly handled in find_program In-Reply-To: <55E6F28E.1080706@kitware.com> References: <55E6F28E.1080706@kitware.com> Message-ID: <7F62CA7F-33C7-4D39-BA2C-D3D5669973B1@sap.com> Same problem. HINTS which are also defined in the environment variable PATH are ignored. On 02/09/15 14:58, "Brad King" wrote: >On 09/02/2015 05:31 AM, CHEVRIER, Marc wrote: >> find_program (MY_EXE my_exe HINTS PATH1 PATH2 PATH3) > >Try it with > > find_program (MY_EXE > NAMES my_exe > HINTS PATH1 PATH2 PATH3 > ) > >-Brad > From brad.king at kitware.com Wed Sep 2 10:19:52 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 02 Sep 2015 10:19:52 -0400 Subject: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module In-Reply-To: References: <55E4A2AB.8050909@kitware.com> Message-ID: <55E70588.8030302@kitware.com> On 08/31/2015 10:45 PM, Paul Romano wrote: > Here is a set of three patches that breaks out the changes. Thanks. I've applied the first two: FindHDF5: Fix support for HL and Fortran_HL components http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=19e7db07 FindHDF5: Add hdf5_hl to list of libraries to search for Fortran_HL http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f7f73df1 I've also drafted a find_program NAMES_PER_DIR option, merged to 'next' for testing here: Merge topic 'find_program-NAMES_PER_DIR' into next http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2bc3f46b Please look at basing work on commit 8ea7611b to use NAMES_PER_DIR for FindHDF5. Of course HDF5_PREFER_PARALLEL may also still be needed in case both executables sit in the same directory. Thanks, -Brad From brad.king at kitware.com Wed Sep 2 10:20:56 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 02 Sep 2015 10:20:56 -0400 Subject: [cmake-developers] [Patch] Build Windows Phone/Store 8.1 on VS 2015 In-Reply-To: References: Message-ID: <55E705C8.2070007@kitware.com> On 09/01/2015 05:09 PM, Gilles Khouzam wrote: > Fixing issue: > https://public.kitware.com/Bug/view.php?id=15662 Thanks, applied and merged to 'next' for testing: VS: Find Desktop SDK for current VS version (#15662) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4b8b9168 -Brad From tim.gallagher at gatech.edu Wed Sep 2 10:44:10 2015 From: tim.gallagher at gatech.edu (Tim Gallagher) Date: Wed, 2 Sep 2015 10:44:10 -0400 (EDT) Subject: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module In-Reply-To: <55E70588.8030302@kitware.com> Message-ID: <1114789191.3763766.1441205050812.JavaMail.root@mail.gatech.edu> I haven't followed the discussion on this issue, but how does it relate to the ticket I opened awhile ago? http://public.kitware.com/Bug/view.php?id=12316 It looks like it may supersede or fix that issue? If so, I guess the issue can be closed! Tim ----- Original Message ----- From: "Brad King" To: "Paul Romano" Cc: cmake-developers at cmake.org Sent: Wednesday, September 2, 2015 10:19:52 AM Subject: Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module On 08/31/2015 10:45 PM, Paul Romano wrote: > Here is a set of three patches that breaks out the changes. Thanks. I've applied the first two: FindHDF5: Fix support for HL and Fortran_HL components http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=19e7db07 FindHDF5: Add hdf5_hl to list of libraries to search for Fortran_HL http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f7f73df1 I've also drafted a find_program NAMES_PER_DIR option, merged to 'next' for testing here: Merge topic 'find_program-NAMES_PER_DIR' into next http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2bc3f46b Please look at basing work on commit 8ea7611b to use NAMES_PER_DIR for FindHDF5. Of course HDF5_PREFER_PARALLEL may also still be needed in case both executables sit in the same directory. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers From brad.king at kitware.com Wed Sep 2 10:59:34 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 02 Sep 2015 10:59:34 -0400 Subject: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module In-Reply-To: <1114789191.3763766.1441205050812.JavaMail.root@mail.gatech.edu> References: <1114789191.3763766.1441205050812.JavaMail.root@mail.gatech.edu> Message-ID: <55E70ED6.2050401@kitware.com> On 09/02/2015 10:44 AM, Tim Gallagher wrote: > I haven't followed the discussion on this issue, but how does it > relate to the ticket I opened awhile ago? > > http://public.kitware.com/Bug/view.php?id=12316 Sorry we missed that patch. > It looks like it may supersede or fix that issue? If so, I guess > the issue can be closed! I've updated the issue with links to this thread and the fixes so far. Please check if it resolves the problem and comment in the issue. Otherwise we can look at taking your patch from there too. Thanks, -Brad From tim.gallagher at gatech.edu Wed Sep 2 11:07:26 2015 From: tim.gallagher at gatech.edu (Tim Gallagher) Date: Wed, 2 Sep 2015 11:07:26 -0400 (EDT) Subject: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module In-Reply-To: <55E70ED6.2050401@kitware.com> Message-ID: <212319808.3774637.1441206446318.JavaMail.root@mail.gatech.edu> It looks like the 2nd commit you linked to does the same thing as my patch (add hdf5hl_fortran to the Fortran library list). So it should work fine and my patch is no longer needed. I will have to see if I have a project that still uses the HL library, it's been 4 years since I think I've used it. So it wasn't an outstanding issue for me -- I just wanted to help close out an open issue if they were related! Thanks, Tim ----- Original Message ----- From: "Brad King" To: "Tim Gallagher" Cc: cmake-developers at cmake.org, "Paul Romano" Sent: Wednesday, September 2, 2015 10:59:34 AM Subject: Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module On 09/02/2015 10:44 AM, Tim Gallagher wrote: > I haven't followed the discussion on this issue, but how does it > relate to the ticket I opened awhile ago? > > http://public.kitware.com/Bug/view.php?id=12316 Sorry we missed that patch. > It looks like it may supersede or fix that issue? If so, I guess > the issue can be closed! I've updated the issue with links to this thread and the fixes so far. Please check if it resolves the problem and comment in the issue. Otherwise we can look at taking your patch from there too. Thanks, -Brad From brad.king at kitware.com Wed Sep 2 11:16:34 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 02 Sep 2015 11:16:34 -0400 Subject: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module In-Reply-To: <212319808.3774637.1441206446318.JavaMail.root@mail.gatech.edu> References: <212319808.3774637.1441206446318.JavaMail.root@mail.gatech.edu> Message-ID: <55E712D2.8010102@kitware.com> On 09/02/2015 11:07 AM, Tim Gallagher wrote: > It looks like the 2nd commit you linked to does the same thing as > my patch (add hdf5hl_fortran to the Fortran library list). Not quite. It is: > - set( HDF5_Fortran_HL_LIBRARY_NAMES_INIT hdf5hl_fortran > + set( HDF5_Fortran_HL_LIBRARY_NAMES_INIT hdf5hl_fortran hdf5_hl One can see hdf5hl_fortran was already in that list. Your patch was: > - set( HDF5_Fortran_LIBRARY_NAMES_INIT hdf5_fortran ${HDF5_C_LIBRARY_NAMES_INIT} ) > + set( HDF5_Fortran_LIBRARY_NAMES_INIT hdf5_fortran hdf5hl_fortran ${HDF5_C_LIBRARY_NAMES_INIT} ) which adds it to a different list, though perhaps the wrong one since it is not for the _HL component. -Brad From brad.king at kitware.com Wed Sep 2 11:25:21 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 02 Sep 2015 11:25:21 -0400 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: References: <55E4B396.9090609@kitware.com> Message-ID: <55E714E1.10505@kitware.com> On 09/01/2015 05:19 PM, Gilles Khouzam wrote: > For VS_DEFAULT_TARGET_PLATFORM_VERSION, what I'm trying to > achieve is almost an internal property that is used for the > try_compile phase. Since the generator is not used in that > scenario, the project is using the template from > Modules/CompilerId/VS-10.vcxproj.in. In that case, we need to set > the tag for the WindowsTargetPlatformVersion. During the > generation, I query for the latest SDK version in the > GlobalGenerator and set the VS_DEFAULT_TARGET_PLATFORM_VERSION > property that is then used in CMakeDetermineCompilerId.cmake to > set the variable that the template uses in the Windows 10 case. The generator *is* used for try_compile calls. The template in Modules/CompilerId/VS-10.vcxproj.in is used *only* for the compiler identification step which occurs before we have enough information to do a full try_compile. The compiler id step does need special handling to set this value, but it should be based on however the value is determined for the generator normally. As discussed in http://www.cmake.org/Bug/view.php?id=15670 the SDK for the latest Windows version may not be the proper default choice. Perhaps it should be the SDK for the host machine's version of Windows to make sure we don't use APIs that cannot run on the current machine. IIRC this is the default on OS X with CMAKE_OSX_SYSROOT. Unlike CMAKE_OSX_SYSROOT, which is used by all generators on OS X, the WindowsTargetPlatformVersion value is something only for the VS IDE generators. In any command-line build we expect the INCLUDE/LIB environment variables to already be set to the proper location. Therefore we need to define a way to set the WindowsTargetPlatformVersion only for VS IDE generators since they generate the environment in which to run the toolchain. CMAKE_GENERATOR_TOOLSET and CMAKE_GENERATOR_PLATFORM are existing options with generator-specific behavior. For VS they set and , respectively. There is quite a bit of C++-side infrastructure to propagate these values to all the right places (and honor cmake -T and -A options on the command line). I'd rather not have something quite so heavyweight for WindowsTargetPlatformVersion because it is a pretty narrow case that should not need a dedicated command-line option and won't be meaningful to other generators. We could simply define a CMAKE_VS_TARGET_PLATFORM_VERSION variable that is used to initialize VS_TARGET_PLATFORM_VERSION target properties (see SetPropertyDefault calls in the source). Then the generator can look just at the target property. If not set it should choose a default based on the current host version of Windows as discussed above. Then we just need to teach cmCoreTryCompile to propagate this setting. The above-linked issue also mentions that TargetFrameworkVersion may need similar infrastructure. -Brad From tim.gallagher at gatech.edu Wed Sep 2 11:35:21 2015 From: tim.gallagher at gatech.edu (Tim Gallagher) Date: Wed, 2 Sep 2015 11:35:21 -0400 (EDT) Subject: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module In-Reply-To: <55E712D2.8010102@kitware.com> Message-ID: <1863012101.3782681.1441208121250.JavaMail.root@mail.gatech.edu> Good catch! The version I patched against didn't have the HDF5_Fortran_HL_LIBRARY_NAMES_INIT variable at the time. There was only the HDF5_Fortran_LIBRARY_NAMES_INIT variable. I'm not sure which version of the code my original patch was against after this long. However, since I submitted my ticket in July of 2011, Will committed support for the HL libraries in August of 2011 with commit http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad218e4 , which added the HDF5_Fortran_HL_LIBRARY_NAMES_INIT variable. Perhaps that commit was intended to reference/fix my ticket? At any rate, since what I submitted wouldn't apply against the current version, it looks like this work supersedes that patch. Tim ----- Original Message ----- From: "Brad King" To: "tim gallagher" Cc: cmake-developers at cmake.org, "Paul Romano" Sent: Wednesday, September 2, 2015 11:16:34 AM Subject: Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module On 09/02/2015 11:07 AM, Tim Gallagher wrote: > It looks like the 2nd commit you linked to does the same thing as > my patch (add hdf5hl_fortran to the Fortran library list). Not quite. It is: > - set( HDF5_Fortran_HL_LIBRARY_NAMES_INIT hdf5hl_fortran > + set( HDF5_Fortran_HL_LIBRARY_NAMES_INIT hdf5hl_fortran hdf5_hl One can see hdf5hl_fortran was already in that list. Your patch was: > - set( HDF5_Fortran_LIBRARY_NAMES_INIT hdf5_fortran ${HDF5_C_LIBRARY_NAMES_INIT} ) > + set( HDF5_Fortran_LIBRARY_NAMES_INIT hdf5_fortran hdf5hl_fortran ${HDF5_C_LIBRARY_NAMES_INIT} ) which adds it to a different list, though perhaps the wrong one since it is not for the _HL component. -Brad From brad.king at kitware.com Wed Sep 2 11:38:31 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 02 Sep 2015 11:38:31 -0400 Subject: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module In-Reply-To: <1863012101.3782681.1441208121250.JavaMail.root@mail.gatech.edu> References: <1863012101.3782681.1441208121250.JavaMail.root@mail.gatech.edu> Message-ID: <55E717F7.3030902@kitware.com> On 09/02/2015 11:35 AM, Tim Gallagher wrote: > it looks like this work supersedes that patch. Okay, thanks for checking! -Brad From brad.king at kitware.com Wed Sep 2 11:39:57 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 02 Sep 2015 11:39:57 -0400 Subject: [cmake-developers] FindZLIB module should find debug and, release variants In-Reply-To: <55E60301.1040601@gmail.com> References: <55E49088.4040106@kitware.com> <55E60301.1040601@gmail.com> Message-ID: <55E7184D.4080506@kitware.com> On 09/01/2015 03:56 PM, Michael Scott wrote: > The attached patch should maintain that compatibility now. If > ZLIB_LIBRARY is set manually, then it won't try and find the library and > it'll set the ZLIB_LIBRARIES and IMPORTED_LOCATION variables using the > provided ZLIB_LIBRARY variable (if the library was found). Thanks. Applied: FindZLIB: Find debug and release variants separately http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=11097f52 -Brad From brad.king at kitware.com Wed Sep 2 11:44:21 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 02 Sep 2015 11:44:21 -0400 Subject: [cmake-developers] [BUG] HINTS not correctly handled in find_program In-Reply-To: <7F62CA7F-33C7-4D39-BA2C-D3D5669973B1@sap.com> References: <55E6F28E.1080706@kitware.com> <7F62CA7F-33C7-4D39-BA2C-D3D5669973B1@sap.com> Message-ID: <55E71955.1070603@kitware.com> On 09/02/2015 09:09 AM, CHEVRIER, Marc wrote: > On 02/09/15 14:58, "Brad King" wrote: >> On 09/02/2015 05:31 AM, CHEVRIER, Marc wrote: >>> find_program (MY_EXE my_exe HINTS PATH1 PATH2 PATH3) >> >> find_program (MY_EXE >> NAMES my_exe >> HINTS PATH1 PATH2 PATH3 >> ) > Same problem. HINTS which are also defined in the environment > variable PATH are ignored. I'm having trouble reproducing this. Please provide a tarball with a full CMakeLists.txt and supporting files that demonstrate this. You can "set(ENV{PATH} ...)" if needed. Thanks, -Brad From gvjung at gmail.com Wed Sep 2 14:59:58 2015 From: gvjung at gmail.com (Greg Jung) Date: Wed, 2 Sep 2015 11:59:58 -0700 Subject: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion In-Reply-To: References: Message-ID: > > Would: > if (MSVC) > .. not be a better discriminator here? There's probably some people > who use MSYS2 in conjunction with MSVC compilers. > > If they are doing that, won't they want the MSYS-installed version? If it's not found then the library reverts to the windows-registered version. It just gives the possible python living under the designated path the first crack. On Wed, Sep 2, 2015 at 4:13 AM, Ray Donnelly wrote: > On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung wrote: > > To revive this issue, I show a comparison of the CMakeCache entries for > > cmake run from the same configuration, 1) cmake 3.2.3 with "old" > PythonLibs > > .vs. 2) cmake 3.3.1 with the new FindPythonLibs.cmake. > > > > Cmake 1): > > > > # This is the CMakeCache file. > > # For build in directory: d:/mingw/msys32/tmp/bld-32 > > # It was generated by CMake: D:/mingw/msys32/mingw32/bin/cmake.exe > > [...] > > //Path to a program. > > PYTHON_EXECUTABLE:FILEPATH=D:/mingw/msys32/mingw32/bin/python.exe > > > > //Path to a file. > > PYTHON_INCLUDE_DIR:PATH=D:/mingw/msys32/mingw32/include/python2.7 > > > > //Path to a library. > > PYTHON_LIBRARY:FILEPATH=E:/Python27/libs/libpython27.a > > > > //Dependencies for the target > > > _plplotcmodule_LIB_DEPENDS:STATIC=general;plplot;general;E:/Python27/libs/libpython27.a; > > > > //Dependencies for the target > > > plplot_widgetmodule_LIB_DEPENDS:STATIC=general;plplot;general;E:/Python27/libs/libpython27.a; > > //Path to CMake executable. > > CMAKE_COMMAND:INTERNAL=D:/mingw/msys32/mingw32/bin/cmake.exe > > //Details about finding PythonLibs > > > FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[E:/Python27/libs/libpython27.a][D:/mingw/msys32/mingw32/include/python2.7][v2.7.10()] > > > > > > Cmake 2): cmake 3.3.1 run from outside the msys tree,using the patched > > FindPythonLibs.cmake > > > > # This is the CMakeCache file. > > # For build in directory: d:/mingw/msys32/tmp/bld-32 > > # It was generated by CMake: D:/programs/CMake-3.3/bin/cmake.exe > > [...] > > //Path to a program. > > PYTHON_EXECUTABLE:FILEPATH=D:/mingw/msys32/mingw32/bin/python.exe > > > > //Path to a file. > > PYTHON_INCLUDE_DIR:PATH=D:/mingw/msys32/mingw32/include/python2.7 > > > > //Path to a library. > > PYTHON_LIBRARY:FILEPATH=D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a > > > > //Dependencies for the target > > > _plplotcmodule_LIB_DEPENDS:STATIC=general;plplot;general;D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a; > > > > //Dependencies for the target > > > plplot_widgetmodule_LIB_DEPENDS:STATIC=general;plplot;general;D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a; > > //Path to CMake executable. > > CMAKE_COMMAND:INTERNAL=D:/programs/CMake-3.3/bin/cmake.exe > > //Details about finding PythonLibs > > > FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a][D:/mingw/msys32/mingw32/include/python2.7][v2.7.10()] > > > > > > So, my windows-y python installation which is registered in the windows > > registry, interferes with my use of > > python until I replace the FindPythonLibs.cmake with the modified > version. > > The new routine will find the registry version in the same manner if > > (WIN32 AND NOT (MINGW OR MSYS)). > > > > > Would: > if (MSVC) > .. not be a better discriminator here? There's probably some people > who use MSYS2 in conjunction with MSVC compilers. > > > Someone using this routine from windows (MSVC) or from a non-win32 > > environment should have the same results as before. If the MSYS user > only > > has a separate windows-based registry-registered python > > and there is nothing found in the unix-style searches, the previous > behavior > > of providing answers from the registry-based installation kicks in. > > > > Regards, Greg > > > > On Fri, Aug 7, 2015 at 4:05 PM, Greg Jung wrote: > >>> > >>> > I have two changes in FindPythonLibs that should make for less > >>> > failure in > >>> > the MINGW/MSYS camp. > >>> > >>> While I support this stuff, I think for it to not > >>> break other people (who use either mingw.org/MinGW-w64 compilers or > >>> the old MSYS with 'normal' Windows CPython), > >> > >> > >> If there is not a python installation to be found in the mingw path, the > >> patched routine will drop into the registry search. which will look > >> exactly like previous. > >> > >>> I think you explicitly mean the MSYS2 camp here. We have our own > >>> Pythons (4 of them, 2 native and 2 cygwin-y) all of which use a > >>> Linux-y layout. > >> > >> > >> I've been running with msys2, and lately I've done a lot of > test-running > >> of plplot using plain vanilla > >> CMake without the patches I used to think were needed. I found that > from > >> the CMake point of view, > >> msys1 or msys2 is a distinction without a difference. > >> > >>> > >>> CMake needs to be able to > >>> identify MSYS2 distinctly from both MINGW and MSYS first. Would a > >>> patch making that distinction be acceptable to CMake? > >> > >> I have used CMakeFindMSYSmake and CMakeFindUnixMake to set a variable > >> designating > >> what /usr translates to: > >> # > >> # the variable MSYS_USR_PATH is here created for use > >> # where the /usr provided by an MSYS app needs to be translated for > >> Windows. > >> # > >> unset(_BIN) > >> find_path( _BIN msys-1.0.dll NAMES msys-2.0.dll HINTS ENV > PATH > >> NO_DEFAULT_PATH) > >> if(_BIN) > >> set(MSYS 1) > >> find_path( MSYS_USR_PATH bin PATHS ${_BIN}/../ NO_DEFAULT_PATH) > >> > >> mark_as_advanced(MSYS_USR_PATH) > >> message(STATUS ": MSYS dll found on > >> ${MSYS_USR_PATH}") > >> endif() > >> unset(_BIN) > >> > >> > >> > >> > >> On Fri, Aug 7, 2015 at 2:25 AM, Ray Donnelly > >> wrote: > >>> > >>> On Fri, Aug 7, 2015 at 7:58 AM, Greg Jung wrote: > >>> > Hi there, > >>> > A patch for review: > >>> > > >>> > I have two changes in FindPythonLibs that should make for less > >>> > failure in > >>> > the MINGW/MSYS camp. > >>> > >>> I think you explicitly mean the MSYS2 camp here. We have our own > >>> Pythons (4 of them, 2 native and 2 cygwin-y) all of which use a > >>> Linux-y layout. While I support this stuff, I think for it to not > >>> break other people (who use either mingw.org/MinGW-w64 compilers or > >>> the old MSYS with 'normal' Windows CPython), CMake needs to be able to > >>> identify MSYS2 distinctly from both MINGW and MSYS first. Would a > >>> patch making that distinction be acceptable to CMake? > >>> > >>> > 1. Distinguish mingw and win32. Avoid the registry lookup. > >>> > if(WIN32) => if(WIN32 AND NOT (MINGW OR MSYS)) for the DEBUG library > >>> > search, > >>> > a full unix-style find_library call without reference to possible > >>> > registry > >>> > entries. > >>> > > >>> > + NAMES > >>> > + python${_CURRENT_VERSION_NO_DOTS} > >>> > + python${_CURRENT_VERSION}mu > >>> > + python${_CURRENT_VERSION}m > >>> > + python${_CURRENT_VERSION}u > >>> > + python${_CURRENT_VERSION} > >>> > +# > >>> > + NAMES_PER_DIR > >>> > + # Avoid finding the .dll in the PATH. We want the .lib. > >>> > +# The NAMES_PER_DIR above should allow the library to be found where > >>> > it was > >>> > desired > >>> > +# in the prioritized location of PATH - cmake V3.3 behavior; > >>> > +# NO_SYSTEM_ENVIRONMENT_PATH works counter to cmake-3.3 > improvement > >>> > where CMake will look into path. > >>> > +# > >>> > + ) > >>> > +endif() > >>> > > >>> > 2. NAMES_PER_DIR replaces NO_SYSTEM_ENVIRONMENT_PATH to modify the > >>> > search > >>> > such that windows/system32/python27.dll > >>> > (for instance) is not picked up before finding the proper library > under > >>> > /lib > >>> > > >>> > > >>> > Instead of throwing all of the possible locations into a single > >>> > find_library(), for WIN32+MINGW builds this may latch into a windows' > >>> > python. > >>> > This is not an issue when CMake is run from /MINGW. > >>> > CMake-3.3.0 (and above) can use PATH to discover targets of > >>> > find_library, > >>> > allowing > >>> > a user with several MINGW installations to use a single cmake (and > >>> > cmake-gui) instead of > >>> > installing several copies for each mingw to be built with. Unless > the > >>> > find_path or > >>> > find_library uses "NO_SYSTEM_ENVIRONMENT_PATH" which kills the new > >>> > feature. > >>> > Even though /mingw32/bin is frontmost in the path, > >>> > windows/system32/python27.dll > >>> > was latched onto because the name matches earlier in the NAMES list > >>> > than > >>> > python2.7. > >>> > to avoid this all of the names are tested as the direcftories are > >>> > presented, > >>> > this via the > >>> > NAMES_PER_DIR qualifier. > >>> > > >>> > This makes is possible for me to run builds using Cmake-gui > without > >>> > installing cmake-gui > >>> > in /mingw32/bin (and qt5 along with it!). > >>> > > >>> > Regards, > >>> > Greg > >>> > > >>> > -- > >>> > > >>> > 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 mingw.android at gmail.com Wed Sep 2 15:04:13 2015 From: mingw.android at gmail.com (Ray Donnelly) Date: Wed, 2 Sep 2015 20:04:13 +0100 Subject: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion In-Reply-To: References: Message-ID: On Wed, Sep 2, 2015 at 7:59 PM, Greg Jung wrote: >> Would: >> if (MSVC) >> .. not be a better discriminator here? There's probably some people >> who use MSYS2 in conjunction with MSVC compilers. >> > If they are doing that, won't they want the MSYS-installed version? If it's > not found then the library > reverts to the windows-registered version. It just gives the possible python > living under the designated path the first crack. > Not necessarily; I mean, if MSVC is set, then CMake is going to use MSVC and if it then finds our Python and links to it then you'll have two c-runtimes in play .. not good .. so my vote is for "if MSVC" or "if MINGW" with no reference to "MSYS" as that's just a general purpose build environment. > On Wed, Sep 2, 2015 at 4:13 AM, Ray Donnelly > wrote: >> >> On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung wrote: >> > To revive this issue, I show a comparison of the CMakeCache entries for >> > cmake run from the same configuration, 1) cmake 3.2.3 with "old" >> > PythonLibs >> > .vs. 2) cmake 3.3.1 with the new FindPythonLibs.cmake. >> > >> > Cmake 1): >> > >> > # This is the CMakeCache file. >> > # For build in directory: d:/mingw/msys32/tmp/bld-32 >> > # It was generated by CMake: D:/mingw/msys32/mingw32/bin/cmake.exe >> > [...] >> > //Path to a program. >> > PYTHON_EXECUTABLE:FILEPATH=D:/mingw/msys32/mingw32/bin/python.exe >> > >> > //Path to a file. >> > PYTHON_INCLUDE_DIR:PATH=D:/mingw/msys32/mingw32/include/python2.7 >> > >> > //Path to a library. >> > PYTHON_LIBRARY:FILEPATH=E:/Python27/libs/libpython27.a >> > >> > //Dependencies for the target >> > >> > _plplotcmodule_LIB_DEPENDS:STATIC=general;plplot;general;E:/Python27/libs/libpython27.a; >> > >> > //Dependencies for the target >> > >> > plplot_widgetmodule_LIB_DEPENDS:STATIC=general;plplot;general;E:/Python27/libs/libpython27.a; >> > //Path to CMake executable. >> > CMAKE_COMMAND:INTERNAL=D:/mingw/msys32/mingw32/bin/cmake.exe >> > //Details about finding PythonLibs >> > >> > FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[E:/Python27/libs/libpython27.a][D:/mingw/msys32/mingw32/include/python2.7][v2.7.10()] >> > >> > >> > Cmake 2): cmake 3.3.1 run from outside the msys tree,using the patched >> > FindPythonLibs.cmake >> > >> > # This is the CMakeCache file. >> > # For build in directory: d:/mingw/msys32/tmp/bld-32 >> > # It was generated by CMake: D:/programs/CMake-3.3/bin/cmake.exe >> > [...] >> > //Path to a program. >> > PYTHON_EXECUTABLE:FILEPATH=D:/mingw/msys32/mingw32/bin/python.exe >> > >> > //Path to a file. >> > PYTHON_INCLUDE_DIR:PATH=D:/mingw/msys32/mingw32/include/python2.7 >> > >> > //Path to a library. >> > PYTHON_LIBRARY:FILEPATH=D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a >> > >> > //Dependencies for the target >> > >> > _plplotcmodule_LIB_DEPENDS:STATIC=general;plplot;general;D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a; >> > >> > //Dependencies for the target >> > >> > plplot_widgetmodule_LIB_DEPENDS:STATIC=general;plplot;general;D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a; >> > //Path to CMake executable. >> > CMAKE_COMMAND:INTERNAL=D:/programs/CMake-3.3/bin/cmake.exe >> > //Details about finding PythonLibs >> > >> > FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a][D:/mingw/msys32/mingw32/include/python2.7][v2.7.10()] >> > >> > >> > So, my windows-y python installation which is registered in the windows >> > registry, interferes with my use of >> > python until I replace the FindPythonLibs.cmake with the modified >> > version. >> > The new routine will find the registry version in the same manner if >> > (WIN32 AND NOT (MINGW OR MSYS)). >> > >> >> >> Would: >> if (MSVC) >> .. not be a better discriminator here? There's probably some people >> who use MSYS2 in conjunction with MSVC compilers. >> >> > Someone using this routine from windows (MSVC) or from a non-win32 >> > environment should have the same results as before. If the MSYS user >> > only >> > has a separate windows-based registry-registered python >> > and there is nothing found in the unix-style searches, the previous >> > behavior >> > of providing answers from the registry-based installation kicks in. >> > >> > Regards, Greg >> > >> > On Fri, Aug 7, 2015 at 4:05 PM, Greg Jung wrote: >> >>> >> >>> > I have two changes in FindPythonLibs that should make for less >> >>> > failure in >> >>> > the MINGW/MSYS camp. >> >>> >> >>> While I support this stuff, I think for it to not >> >>> break other people (who use either mingw.org/MinGW-w64 compilers or >> >>> the old MSYS with 'normal' Windows CPython), >> >> >> >> >> >> If there is not a python installation to be found in the mingw path, >> >> the >> >> patched routine will drop into the registry search. which will look >> >> exactly like previous. >> >> >> >>> I think you explicitly mean the MSYS2 camp here. We have our own >> >>> Pythons (4 of them, 2 native and 2 cygwin-y) all of which use a >> >>> Linux-y layout. >> >> >> >> >> >> I've been running with msys2, and lately I've done a lot of >> >> test-running >> >> of plplot using plain vanilla >> >> CMake without the patches I used to think were needed. I found that >> >> from >> >> the CMake point of view, >> >> msys1 or msys2 is a distinction without a difference. >> >> >> >>> >> >>> CMake needs to be able to >> >>> identify MSYS2 distinctly from both MINGW and MSYS first. Would a >> >>> patch making that distinction be acceptable to CMake? >> >> >> >> I have used CMakeFindMSYSmake and CMakeFindUnixMake to set a variable >> >> designating >> >> what /usr translates to: >> >> # >> >> # the variable MSYS_USR_PATH is here created for use >> >> # where the /usr provided by an MSYS app needs to be translated for >> >> Windows. >> >> # >> >> unset(_BIN) >> >> find_path( _BIN msys-1.0.dll NAMES msys-2.0.dll HINTS ENV >> >> PATH >> >> NO_DEFAULT_PATH) >> >> if(_BIN) >> >> set(MSYS 1) >> >> find_path( MSYS_USR_PATH bin PATHS ${_BIN}/../ NO_DEFAULT_PATH) >> >> >> >> mark_as_advanced(MSYS_USR_PATH) >> >> message(STATUS ": MSYS dll found on >> >> ${MSYS_USR_PATH}") >> >> endif() >> >> unset(_BIN) >> >> >> >> >> >> >> >> >> >> On Fri, Aug 7, 2015 at 2:25 AM, Ray Donnelly >> >> wrote: >> >>> >> >>> On Fri, Aug 7, 2015 at 7:58 AM, Greg Jung wrote: >> >>> > Hi there, >> >>> > A patch for review: >> >>> > >> >>> > I have two changes in FindPythonLibs that should make for less >> >>> > failure in >> >>> > the MINGW/MSYS camp. >> >>> >> >>> I think you explicitly mean the MSYS2 camp here. We have our own >> >>> Pythons (4 of them, 2 native and 2 cygwin-y) all of which use a >> >>> Linux-y layout. While I support this stuff, I think for it to not >> >>> break other people (who use either mingw.org/MinGW-w64 compilers or >> >>> the old MSYS with 'normal' Windows CPython), CMake needs to be able to >> >>> identify MSYS2 distinctly from both MINGW and MSYS first. Would a >> >>> patch making that distinction be acceptable to CMake? >> >>> >> >>> > 1. Distinguish mingw and win32. Avoid the registry lookup. >> >>> > if(WIN32) => if(WIN32 AND NOT (MINGW OR MSYS)) for the DEBUG library >> >>> > search, >> >>> > a full unix-style find_library call without reference to possible >> >>> > registry >> >>> > entries. >> >>> > >> >>> > + NAMES >> >>> > + python${_CURRENT_VERSION_NO_DOTS} >> >>> > + python${_CURRENT_VERSION}mu >> >>> > + python${_CURRENT_VERSION}m >> >>> > + python${_CURRENT_VERSION}u >> >>> > + python${_CURRENT_VERSION} >> >>> > +# >> >>> > + NAMES_PER_DIR >> >>> > + # Avoid finding the .dll in the PATH. We want the .lib. >> >>> > +# The NAMES_PER_DIR above should allow the library to be found >> >>> > where >> >>> > it was >> >>> > desired >> >>> > +# in the prioritized location of PATH - cmake V3.3 behavior; >> >>> > +# NO_SYSTEM_ENVIRONMENT_PATH works counter to cmake-3.3 >> >>> > improvement >> >>> > where CMake will look into path. >> >>> > +# >> >>> > + ) >> >>> > +endif() >> >>> > >> >>> > 2. NAMES_PER_DIR replaces NO_SYSTEM_ENVIRONMENT_PATH to modify the >> >>> > search >> >>> > such that windows/system32/python27.dll >> >>> > (for instance) is not picked up before finding the proper library >> >>> > under >> >>> > /lib >> >>> > >> >>> > >> >>> > Instead of throwing all of the possible locations into a single >> >>> > find_library(), for WIN32+MINGW builds this may latch into a >> >>> > windows' >> >>> > python. >> >>> > This is not an issue when CMake is run from /MINGW. >> >>> > CMake-3.3.0 (and above) can use PATH to discover targets of >> >>> > find_library, >> >>> > allowing >> >>> > a user with several MINGW installations to use a single cmake (and >> >>> > cmake-gui) instead of >> >>> > installing several copies for each mingw to be built with. Unless >> >>> > the >> >>> > find_path or >> >>> > find_library uses "NO_SYSTEM_ENVIRONMENT_PATH" which kills the new >> >>> > feature. >> >>> > Even though /mingw32/bin is frontmost in the path, >> >>> > windows/system32/python27.dll >> >>> > was latched onto because the name matches earlier in the NAMES list >> >>> > than >> >>> > python2.7. >> >>> > to avoid this all of the names are tested as the direcftories are >> >>> > presented, >> >>> > this via the >> >>> > NAMES_PER_DIR qualifier. >> >>> > >> >>> > This makes is possible for me to run builds using Cmake-gui >> >>> > without >> >>> > installing cmake-gui >> >>> > in /mingw32/bin (and qt5 along with it!). >> >>> > >> >>> > Regards, >> >>> > Greg >> >>> > >> >>> > -- >> >>> > >> >>> > 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 gvjung at gmail.com Wed Sep 2 15:06:01 2015 From: gvjung at gmail.com (Greg Jung) Date: Wed, 2 Sep 2015 12:06:01 -0700 Subject: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion In-Reply-To: <55E6F364.7050103@kitware.com> References: <55E6F364.7050103@kitware.com> Message-ID: > > As a reminder, another branch of this discussion is pending over here: > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13948/focus=13982 That devolved into another issue. This also applies to msys-1 with a targetted python installation. I don't think there are any "structural" issues in running the mingw-w64/msys2 system using "MSYS Makefiles". The cmake adapted to running posix-mode msys2 is another matter. On Wed, Sep 2, 2015 at 6:02 AM, Brad King wrote: > On 09/02/2015 07:13 AM, Ray Donnelly wrote: > > On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung wrote: > >> To revive this issue, I show a comparison of the CMakeCache entries for > >> cmake run from the same configuration, 1) cmake 3.2.3 with "old" > PythonLibs > >> .vs. 2) cmake 3.3.1 with the new FindPythonLibs.cmake. > > As a reminder, another branch of this discussion is pending over here: > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13948/focus=13982 > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gvjung at gmail.com Wed Sep 2 15:27:17 2015 From: gvjung at gmail.com (Greg Jung) Date: Wed, 2 Sep 2015 12:27:17 -0700 Subject: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion In-Reply-To: References: Message-ID: > > On Wed, Sep 2, 2015 at 7:59 PM, Greg Jung wrote: > >> Would: > >> if (MSVC) > >> .. not be a better discriminator here? There's probably some people > >> who use MSYS2 in conjunction with MSVC compilers. > >> > > If they are doing that, won't they want the MSYS-installed version? If > it's > > not found then the library > > reverts to the windows-registered version. It just gives the possible > python > > living under the designated path the first crack. > > > > Not necessarily; I mean, if MSVC is set, then CMake is going to use > MSVC and if it then finds our Python and links to it then you'll have > two c-runtimes in play .. not good .. so my vote is for "if MSVC" or > "if MINGW" with no reference to "MSYS" as that's just a general > purpose build environment. If MSVC is the only compiler that is capable of using the registered python, then replacing if(WIN32 AND NOT (MINGW OR MSYS)) with if(MSVC) and if((NOT WIN32) OR (MINGW OR MSYS)) replaced by if(NOT MSVC) would definitely be a better read. On Wed, Sep 2, 2015 at 12:04 PM, Ray Donnelly wrote: > On Wed, Sep 2, 2015 at 7:59 PM, Greg Jung wrote: > >> Would: > >> if (MSVC) > >> .. not be a better discriminator here? There's probably some people > >> who use MSYS2 in conjunction with MSVC compilers. > >> > > If they are doing that, won't they want the MSYS-installed version? If > it's > > not found then the library > > reverts to the windows-registered version. It just gives the possible > python > > living under the designated path the first crack. > > > > Not necessarily; I mean, if MSVC is set, then CMake is going to use > MSVC and if it then finds our Python and links to it then you'll have > two c-runtimes in play .. not good .. so my vote is for "if MSVC" or > "if MINGW" with no reference to "MSYS" as that's just a general > purpose build environment. > > > On Wed, Sep 2, 2015 at 4:13 AM, Ray Donnelly > > wrote: > >> > >> On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung wrote: > >> > To revive this issue, I show a comparison of the CMakeCache entries > for > >> > cmake run from the same configuration, 1) cmake 3.2.3 with "old" > >> > PythonLibs > >> > .vs. 2) cmake 3.3.1 with the new FindPythonLibs.cmake. > >> > > >> > Cmake 1): > >> > > >> > # This is the CMakeCache file. > >> > # For build in directory: d:/mingw/msys32/tmp/bld-32 > >> > # It was generated by CMake: D:/mingw/msys32/mingw32/bin/cmake.exe > >> > [...] > >> > //Path to a program. > >> > PYTHON_EXECUTABLE:FILEPATH=D:/mingw/msys32/mingw32/bin/python.exe > >> > > >> > //Path to a file. > >> > PYTHON_INCLUDE_DIR:PATH=D:/mingw/msys32/mingw32/include/python2.7 > >> > > >> > //Path to a library. > >> > PYTHON_LIBRARY:FILEPATH=E:/Python27/libs/libpython27.a > >> > > >> > //Dependencies for the target > >> > > >> > > _plplotcmodule_LIB_DEPENDS:STATIC=general;plplot;general;E:/Python27/libs/libpython27.a; > >> > > >> > //Dependencies for the target > >> > > >> > > plplot_widgetmodule_LIB_DEPENDS:STATIC=general;plplot;general;E:/Python27/libs/libpython27.a; > >> > //Path to CMake executable. > >> > CMAKE_COMMAND:INTERNAL=D:/mingw/msys32/mingw32/bin/cmake.exe > >> > //Details about finding PythonLibs > >> > > >> > > FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[E:/Python27/libs/libpython27.a][D:/mingw/msys32/mingw32/include/python2.7][v2.7.10()] > >> > > >> > > >> > Cmake 2): cmake 3.3.1 run from outside the msys tree,using the patched > >> > FindPythonLibs.cmake > >> > > >> > # This is the CMakeCache file. > >> > # For build in directory: d:/mingw/msys32/tmp/bld-32 > >> > # It was generated by CMake: D:/programs/CMake-3.3/bin/cmake.exe > >> > [...] > >> > //Path to a program. > >> > PYTHON_EXECUTABLE:FILEPATH=D:/mingw/msys32/mingw32/bin/python.exe > >> > > >> > //Path to a file. > >> > PYTHON_INCLUDE_DIR:PATH=D:/mingw/msys32/mingw32/include/python2.7 > >> > > >> > //Path to a library. > >> > PYTHON_LIBRARY:FILEPATH=D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a > >> > > >> > //Dependencies for the target > >> > > >> > > _plplotcmodule_LIB_DEPENDS:STATIC=general;plplot;general;D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a; > >> > > >> > //Dependencies for the target > >> > > >> > > plplot_widgetmodule_LIB_DEPENDS:STATIC=general;plplot;general;D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a; > >> > //Path to CMake executable. > >> > CMAKE_COMMAND:INTERNAL=D:/programs/CMake-3.3/bin/cmake.exe > >> > //Details about finding PythonLibs > >> > > >> > > FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a][D:/mingw/msys32/mingw32/include/python2.7][v2.7.10()] > >> > > >> > > >> > So, my windows-y python installation which is registered in the > windows > >> > registry, interferes with my use of > >> > python until I replace the FindPythonLibs.cmake with the modified > >> > version. > >> > The new routine will find the registry version in the same manner if > >> > (WIN32 AND NOT (MINGW OR MSYS)). > >> > > >> > >> > >> Would: > >> if (MSVC) > >> .. not be a better discriminator here? There's probably some people > >> who use MSYS2 in conjunction with MSVC compilers. > >> > >> > Someone using this routine from windows (MSVC) or from a non-win32 > >> > environment should have the same results as before. If the MSYS user > >> > only > >> > has a separate windows-based registry-registered python > >> > and there is nothing found in the unix-style searches, the previous > >> > behavior > >> > of providing answers from the registry-based installation kicks in. > >> > > >> > Regards, Greg > >> > > >> > On Fri, Aug 7, 2015 at 4:05 PM, Greg Jung wrote: > >> >>> > >> >>> > I have two changes in FindPythonLibs that should make for less > >> >>> > failure in > >> >>> > the MINGW/MSYS camp. > >> >>> > >> >>> While I support this stuff, I think for it to not > >> >>> break other people (who use either mingw.org/MinGW-w64 compilers or > >> >>> the old MSYS with 'normal' Windows CPython), > >> >> > >> >> > >> >> If there is not a python installation to be found in the mingw path, > >> >> the > >> >> patched routine will drop into the registry search. which will look > >> >> exactly like previous. > >> >> > >> >>> I think you explicitly mean the MSYS2 camp here. We have our own > >> >>> Pythons (4 of them, 2 native and 2 cygwin-y) all of which use a > >> >>> Linux-y layout. > >> >> > >> >> > >> >> I've been running with msys2, and lately I've done a lot of > >> >> test-running > >> >> of plplot using plain vanilla > >> >> CMake without the patches I used to think were needed. I found that > >> >> from > >> >> the CMake point of view, > >> >> msys1 or msys2 is a distinction without a difference. > >> >> > >> >>> > >> >>> CMake needs to be able to > >> >>> identify MSYS2 distinctly from both MINGW and MSYS first. Would a > >> >>> patch making that distinction be acceptable to CMake? > >> >> > >> >> I have used CMakeFindMSYSmake and CMakeFindUnixMake to set a variable > >> >> designating > >> >> what /usr translates to: > >> >> # > >> >> # the variable MSYS_USR_PATH is here created for use > >> >> # where the /usr provided by an MSYS app needs to be translated for > >> >> Windows. > >> >> # > >> >> unset(_BIN) > >> >> find_path( _BIN msys-1.0.dll NAMES msys-2.0.dll HINTS ENV > >> >> PATH > >> >> NO_DEFAULT_PATH) > >> >> if(_BIN) > >> >> set(MSYS 1) > >> >> find_path( MSYS_USR_PATH bin PATHS ${_BIN}/../ NO_DEFAULT_PATH) > >> >> > >> >> mark_as_advanced(MSYS_USR_PATH) > >> >> message(STATUS ": MSYS dll found on > >> >> ${MSYS_USR_PATH}") > >> >> endif() > >> >> unset(_BIN) > >> >> > >> >> > >> >> > >> >> > >> >> On Fri, Aug 7, 2015 at 2:25 AM, Ray Donnelly < > mingw.android at gmail.com> > >> >> wrote: > >> >>> > >> >>> On Fri, Aug 7, 2015 at 7:58 AM, Greg Jung wrote: > >> >>> > Hi there, > >> >>> > A patch for review: > >> >>> > > >> >>> > I have two changes in FindPythonLibs that should make for less > >> >>> > failure in > >> >>> > the MINGW/MSYS camp. > >> >>> > >> >>> I think you explicitly mean the MSYS2 camp here. We have our own > >> >>> Pythons (4 of them, 2 native and 2 cygwin-y) all of which use a > >> >>> Linux-y layout. While I support this stuff, I think for it to not > >> >>> break other people (who use either mingw.org/MinGW-w64 compilers or > >> >>> the old MSYS with 'normal' Windows CPython), CMake needs to be able > to > >> >>> identify MSYS2 distinctly from both MINGW and MSYS first. Would a > >> >>> patch making that distinction be acceptable to CMake? > >> >>> > >> >>> > 1. Distinguish mingw and win32. Avoid the registry lookup. > >> >>> > if(WIN32) => if(WIN32 AND NOT (MINGW OR MSYS)) for the DEBUG > library > >> >>> > search, > >> >>> > a full unix-style find_library call without reference to possible > >> >>> > registry > >> >>> > entries. > >> >>> > > >> >>> > + NAMES > >> >>> > + python${_CURRENT_VERSION_NO_DOTS} > >> >>> > + python${_CURRENT_VERSION}mu > >> >>> > + python${_CURRENT_VERSION}m > >> >>> > + python${_CURRENT_VERSION}u > >> >>> > + python${_CURRENT_VERSION} > >> >>> > +# > >> >>> > + NAMES_PER_DIR > >> >>> > + # Avoid finding the .dll in the PATH. We want the .lib. > >> >>> > +# The NAMES_PER_DIR above should allow the library to be found > >> >>> > where > >> >>> > it was > >> >>> > desired > >> >>> > +# in the prioritized location of PATH - cmake V3.3 behavior; > >> >>> > +# NO_SYSTEM_ENVIRONMENT_PATH works counter to cmake-3.3 > >> >>> > improvement > >> >>> > where CMake will look into path. > >> >>> > +# > >> >>> > + ) > >> >>> > +endif() > >> >>> > > >> >>> > 2. NAMES_PER_DIR replaces NO_SYSTEM_ENVIRONMENT_PATH to modify the > >> >>> > search > >> >>> > such that windows/system32/python27.dll > >> >>> > (for instance) is not picked up before finding the proper library > >> >>> > under > >> >>> > /lib > >> >>> > > >> >>> > > >> >>> > Instead of throwing all of the possible locations into a single > >> >>> > find_library(), for WIN32+MINGW builds this may latch into a > >> >>> > windows' > >> >>> > python. > >> >>> > This is not an issue when CMake is run from /MINGW. > >> >>> > CMake-3.3.0 (and above) can use PATH to discover targets of > >> >>> > find_library, > >> >>> > allowing > >> >>> > a user with several MINGW installations to use a single cmake (and > >> >>> > cmake-gui) instead of > >> >>> > installing several copies for each mingw to be built with. Unless > >> >>> > the > >> >>> > find_path or > >> >>> > find_library uses "NO_SYSTEM_ENVIRONMENT_PATH" which kills the new > >> >>> > feature. > >> >>> > Even though /mingw32/bin is frontmost in the path, > >> >>> > windows/system32/python27.dll > >> >>> > was latched onto because the name matches earlier in the NAMES > list > >> >>> > than > >> >>> > python2.7. > >> >>> > to avoid this all of the names are tested as the direcftories are > >> >>> > presented, > >> >>> > this via the > >> >>> > NAMES_PER_DIR qualifier. > >> >>> > > >> >>> > This makes is possible for me to run builds using Cmake-gui > >> >>> > without > >> >>> > installing cmake-gui > >> >>> > in /mingw32/bin (and qt5 along with it!). > >> >>> > > >> >>> > Regards, > >> >>> > Greg > >> >>> > > >> >>> > -- > >> >>> > > >> >>> > 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 JamesJ at motionview3d.com Wed Sep 2 15:34:44 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Wed, 2 Sep 2015 19:34:44 -0000 Subject: [cmake-developers] [CMake] Visual Studio - Ninja Generator In-Reply-To: References: <55E48101.2010502@gmail.com> Message-ID: <053901d0e5b6$6c47ae70$44d70b50$@motionview3d.com> Recently I have wondered if it would be useful if the Visual Studio generators in CMake were refactored somewhat (to what degree, I am not sure). Not that I have time to work on it right now, and I have not studied this section of CMake code in detail, so I may be a little off base with some of this - please bear with me... Example: instead of Visual C++ 2008 generator, we have a back-end generator for VC++2005/2008 projects. Then instead of Visual C++ 2010 generator, we have back-end MSBuild generator. (Perhaps the back-end generators could be tools reused by existing normal "Visual Studio 2008" CMake generators and so on). If a VC++ 2008 project is needed, the back-end VC2008 generator is used. If a C# 2008 project is needed, the back-end MSBuild generator is used. There are some use cases: * The example given by Guillaume Dumont. In this case, it would be useful to have Visual Studio available as an "Extra" CMake generator. For example, specification of "Visual Studio 2015 - Ninja" (much like how you can do "CodeBlocks - Ninja" today, etc.). This would run Ninja in background to do the building, while retaining the IDE. Presumably this generator will have to share a lot of code with the regular VS2015 generator. I would be very happy if this feature existed and would use it tomorrow. The MSBuild system has serious concurrency issues resulting in serious over/undersubscription. * Recently there have been mailings from Michael Stuermer about adding C# as a language CMake. Another feature I would use tomorrow if it worked well. I skimmed through some of the commits to see how he is doing it; while helpful, I think there are some shortcomings that may not be easy to fix without some preliminary work related to Visual Studio project generation. IIRC the author's code works for generating Visual C# 2013 projects using the Visual C++ 2013 generator, but that's it. Ideally you really want to be able to: (1) build C# 2005/2008 projects, (2) use more efficient tools like Ninja. And to do that I think requires decoupling the language from the project file generator. Right now, CMake makes the assumption that the language project file format of each VS version is basically identical (e.g. all MSBuild, or not), and this is not true. To elaborate on the C# example some more, suppose the user wants to generate a Visual Studio 2008 solution. So they pick the normal VS2008 generator. In this situation: (1) C++ projects need to be generated using the C++ project generation code in the existing VS2008 generator, (2) C# projects need to be generated using an MSBuild generator, which is very different from the VS2008 C++ project format - i.e. these projects will need to use code from the current VC++ 2010 generator. Summary: to do this right for VS2005/2008 requires using significant code from two different existing CMake generators: some code from existing VS2005/2008 generator, and some code from VS2010 generator. The Ninja C# example is also tricky to get right. It may not be practical to invoke csc.exe directly; there might be other tools involved and a lot of how things "should" work is currently largely undocumented and hidden away inside of the system MSBuild .targets files. An example is resolving assembly references. If you pass in an unqualified assembly reference directly to csc.exe, the compiler searches for the assembly in various directories using rules defined here: https://msdn.microsoft.com/en-us/library/s5bac5fx.aspx - however, these rules do not match what actually happens when you add an assembly reference to a Visual C# project and compile it with MSBuild.exe. In that situation, MSBuild.exe resolves assemblies using a COMPLETELY DIFFERENT set of rules than csc.exe, and then passes absolute paths to csc.exe. The correct rules to use are probably the ones inside of Microsoft.Common.targets file, which doesn't seem to be documented in MSDN, and only documented by a comment in the XML: For example, I found when building with MSBuild, absolute paths to assemblies in "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5" were used, and this location is not used if I pass an unqualified path directly to csc.exe and use csc's rules. This blog post suggests that these new assembly resolution rules are very important: http://blogs.msdn.com/b/msbuild/archive/2007/04/12/new-reference-assemblies-location.aspx --- Therefore, I have to conclude that there are only two valid ways of compiling a C# project from CMake: a. Reverse engineer the MSBuild files for each Visual Studio project and teach CMake largely undocumented rules for things like assembly resolution and whatever else we run into. If it's just assembly resolution it might be manageable, but I fear it's a rabbit hole... b. Have CMake generate a C# project file for each C# project - even when using non-VS generators like Ninja. The Ninja build rule for a C# project would just be to invoke MSBuild.exe and build that one project. (Only generate projects, not solutions.) But this requires the ability for a CMake language to invoke the MSBuild-generating code inside CMake to spit out a Visual Studio project for each C# target. Benefit: now CMake doesn't reimplement undocumented behavior of Microsoft's MSBuild targets; we just use them directly as a black box. Best regards, James Johnston From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Guillaume Dumont Sent: Monday, August 31, 2015 16:49 To: Gonzalo Cc: cmake at cmake.org Subject: Re: [CMake] Visual Studio - Ninja Generator @Hendrik Sattler I have not experimented with the /MP flag that much, but this won't solve my problem when the project contains a lot of CUDA files. The /MP flag as not effect there. Yes I could indeed create a custom build target and create additional build trees to build using ninja in there but this is suboptimal in my opinion. @Gonzalo Yes this is precisely what I do but then you only get the ninja build files. No solution for debugging etc. My question is more about the difficulty of creating a new generator that makes the use of ninja as transparent as possible to the user instead of writing custom CMake code to do this in my own projects. On Mon, Aug 31, 2015 at 12:29 PM, Gonzalo wrote: s it has changed names a couple of times). That shoul -- Guillaume Dumont ========================= dumont.guillaume at gmail.com From gjasny at googlemail.com Wed Sep 2 16:47:09 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 2 Sep 2015 22:47:09 +0200 Subject: [cmake-developers] CDash broken Message-ID: <55E7604D.6060702@googlemail.com> Hello, from time to time the CMake Dashboard at http://www.cdash.org/CDash/index.php?project=CMake is very slow. Right now I cannot access it at all. Does anyone know what's wrong? Thanks, Gregor From mantis at public.kitware.com Wed Sep 2 19:41:12 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 3 Sep 2015 11:41:12 +1200 Subject: [cmake-developers] [CMake 0015724]: Unable to specify iwyu options Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15724 ====================================================================== Reported By: Jeremie Delaitre Assigned To: ====================================================================== Project: CMake Issue ID: 15724 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-03 11:41 NZST Last Modified: 2015-09-03 11:41 NZST ====================================================================== Summary: Unable to specify iwyu options Description: I am trying the new include-what-you-use support of CMake (3.3.0). It is working fine when I just run iwyu, but I'd like to specify some additional options (most importantly "-Xiwyu --mapping-file=..."). I could not find a way to make it work. I tried to specify the options with: set(CMAKE_CXX_INCLUDE_WHAT_YOU_USE "/usr/bin/iwyu -Xiwyu --mapping-file=...") without success (I tried other iwyu options too). The command line generated looks like: FAILED: /usr/bin/cmake -E __run_iwyu --iwyu="/usr/bin/include-what-you-use -Xiwyu --mapping_file=" -- /g++ --sysroot= Error running '/usr/bin/include-what-you-use -Xiwyu --mapping_file=""': No such file or directory I tried to change the command by hand (e.g. moving the iwyu option after the "--") but it did not work neither. Any hint? Additional Information: - CMake 3.3.0 - include-what-you-use 0.3 based on clang version 3.5.0 (tags/RELEASE_350/final) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-03 11:41 Jeremie DelaitreNew Issue ====================================================================== From marc.chevrier at sap.com Thu Sep 3 03:51:10 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Thu, 3 Sep 2015 07:51:10 +0000 Subject: [cmake-developers] [BUG] HINTS not correctly handled in find_program In-Reply-To: <55E71955.1070603@kitware.com> References: <55E6F28E.1080706@kitware.com> <7F62CA7F-33C7-4D39-BA2C-D3D5669973B1@sap.com> <55E71955.1070603@kitware.com> Message-ID: <2A8C1310-D3AA-404A-88A3-5298D04A35AC@sap.com> Hi, Attached is a minimal example. To use it: 1. Build phase. Under find_program.BUG/build, use CMakeLists.txt to prepare runtime part 2. Test phase. Under find_program.BUG/runtime, use CMakeLists.txt to show the bug. Here is the result on my SuSE Linux with CMake 3.3.1 (binaries retrieved from CMake web site): -- The C compiler identification is GNU 4.3.4 -- The CXX compiler identification is GNU 4.3.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 Test1: Fail to found correct exe: /home/marc/tests/find_program.BUG/runtime/dir2/exe Test2: Found correct exe: /home/marc/tests/find_program.BUG/runtime/dir1/exe -- Configuring done -- Generating done -- Build files have been written to: /home/marc/tests/find_program.BUG/runtime/gen Marc On 02/09/15 17:44, "Brad King" wrote: >On 09/02/2015 09:09 AM, CHEVRIER, Marc wrote: >> On 02/09/15 14:58, "Brad King" wrote: >>> On 09/02/2015 05:31 AM, CHEVRIER, Marc wrote: >>>> find_program (MY_EXE my_exe HINTS PATH1 PATH2 PATH3) >>> >>> find_program (MY_EXE >>> NAMES my_exe >>> HINTS PATH1 PATH2 PATH3 >>> ) >> Same problem. HINTS which are also defined in the environment >> variable PATH are ignored. > >I'm having trouble reproducing this. Please provide a tarball >with a full CMakeLists.txt and supporting files that demonstrate >this. You can "set(ENV{PATH} ...)" if needed. > >Thanks, >-Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: find_program.BUG.tar.gz Type: application/x-gzip Size: 703 bytes Desc: find_program.BUG.tar.gz URL: From paul.k.romano at gmail.com Thu Sep 3 05:16:35 2015 From: paul.k.romano at gmail.com (Paul Romano) Date: Thu, 3 Sep 2015 16:16:35 +0700 Subject: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module In-Reply-To: <55E717F7.3030902@kitware.com> References: <1863012101.3782681.1441208121250.JavaMail.root@mail.gatech.edu> <55E717F7.3030902@kitware.com> Message-ID: Tim- I did notice your issue about Fortran HL not working but wasn't sure what the original problem was or if it was still relevant. Anyway, I'm glad we got a fix in, albeit four years later -- better late than never! Brad- here's a new patch based off of 8ea7611 that uses the new NAMES_PER_DIR option of find_program as well adds the HDF5_PREFER_PARALLEL variable. The only case I know of where h5cc and h5pcc would get into the same directory is in /usr/bin, e.g. the hdf5-helpers and libhdf5-openmpi-dev packages in debian. However, the packagers don't use the name h5pcc but rather h5pcc.mpich and h5pcc.openmpi, so in that case HDF5_PREFER_PARALLEL doesn't actually help. Anyway, I'm going to cogitate on the best way to handle that and may return with one more patch to handle this situation. Best, Paul On Wed, Sep 2, 2015 at 10:38 PM, Brad King wrote: > On 09/02/2015 11:35 AM, Tim Gallagher wrote: > > it looks like this work supersedes that patch. > > Okay, thanks for checking! > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindHDF5-Add-NAMES_PER_DIR-and-introduce-HDF5_PREFER.patch Type: text/x-patch Size: 2273 bytes Desc: not available URL: From mantis at public.kitware.com Thu Sep 3 12:11:02 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 3 Sep 2015 12:11:02 -0400 Subject: [cmake-developers] [CMake 0015725]: post generate action Message-ID: <96d1cca0337c945ab6852b3b20156f1c@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15725 ====================================================================== Reported By: Gregory Kramida Assigned To: ====================================================================== Project: CMake Issue ID: 15725 Category: CMake Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-03 12:11 EDT Last Modified: 2015-09-03 12:11 EDT ====================================================================== Summary: post generate action Description: It would be great if users had the ability to schedule processes after the generation step. There are many ways, i.e. adding another command, but I guess the easiest way to achieve that would be by extending the execute_process command with something like a SCHEDULE_AFTER_GENERATION flag. Additional Information: See http://www.cmake.org/pipermail/cmake/2010-May/037151.html See comments in answer here http://stackoverflow.com/questions/7091447/run-command-after-generation-step-in-cmake ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-03 12:11 Gregory KramidaNew Issue ====================================================================== From Gilles.Khouzam at microsoft.com Thu Sep 3 15:19:22 2015 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Thu, 3 Sep 2015 19:19:22 +0000 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: <55E714E1.10505@kitware.com> References: <55E4B396.9090609@kitware.com> <55E714E1.10505@kitware.com> Message-ID: Sorry, you are right, try_compile calls do use the generator and don't have a problem. I was trying to do something similar to what you are describing here: > We could simply define a > > CMAKE_VS_TARGET_PLATFORM_VERSION > > variable that is used to initialize VS_TARGET_PLATFORM_VERSION target properties (see SetPropertyDefault calls in the source). > Then the generator can look just at the target property. If not set it should choose a default based on the current host version of Windows as discussed above. Then we just need to teach cmCoreTryCompile to propagate this > setting. > > The above-linked issue also mentions that TargetFrameworkVersion may need similar infrastructure. Perhaps the default selection (at least for Store apps since that's the one that requires the flag) should be the newest SDK less than the version of the host System. If CMAKE_VS_TARGET_PLATFORM_VERSION is specified then we would simply use it. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Wednesday, September 2, 2015 08:25 To: Gilles Khouzam Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/01/2015 05:19 PM, Gilles Khouzam wrote: > For VS_DEFAULT_TARGET_PLATFORM_VERSION, what I'm trying to achieve is > almost an internal property that is used for the try_compile phase. > Since the generator is not used in that scenario, the project is using > the template from Modules/CompilerId/VS-10.vcxproj.in. In that case, > we need to set the tag for the WindowsTargetPlatformVersion. During > the generation, I query for the latest SDK version in the > GlobalGenerator and set the VS_DEFAULT_TARGET_PLATFORM_VERSION > property that is then used in CMakeDetermineCompilerId.cmake to set > the variable that the template uses in the Windows 10 case. The generator *is* used for try_compile calls. The template in Modules/CompilerId/VS-10.vcxproj.in is used *only* for the compiler identification step which occurs before we have enough information to do a full try_compile. The compiler id step does need special handling to set this value, but it should be based on however the value is determined for the generator normally. As discussed in http://www.cmake.org/Bug/view.php?id=15670 the SDK for the latest Windows version may not be the proper default choice. Perhaps it should be the SDK for the host machine's version of Windows to make sure we don't use APIs that cannot run on the current machine. IIRC this is the default on OS X with CMAKE_OSX_SYSROOT. Unlike CMAKE_OSX_SYSROOT, which is used by all generators on OS X, the WindowsTargetPlatformVersion value is something only for the VS IDE generators. In any command-line build we expect the INCLUDE/LIB environment variables to already be set to the proper location. Therefore we need to define a way to set the WindowsTargetPlatformVersion only for VS IDE generators since they generate the environment in which to run the toolchain. CMAKE_GENERATOR_TOOLSET and CMAKE_GENERATOR_PLATFORM are existing options with generator-specific behavior. For VS they set and , respectively. There is quite a bit of C++-side infrastructure to propagate these values to all the right places (and honor cmake -T and -A options on the command line). I'd rather not have something quite so heavyweight for WindowsTargetPlatformVersion because it is a pretty narrow case that should not need a dedicated command-line option and won't be meaningful to other generators. We could simply define a CMAKE_VS_TARGET_PLATFORM_VERSION variable that is used to initialize VS_TARGET_PLATFORM_VERSION target properties (see SetPropertyDefault calls in the source). Then the generator can look just at the target property. If not set it should choose a default based on the current host version of Windows as discussed above. Then we just need to teach cmCoreTryCompile to propagate this setting. The above-linked issue also mentions that TargetFrameworkVersion may need similar infrastructure. -Brad From dpb at corrigendum.ru Thu Sep 3 16:00:09 2015 From: dpb at corrigendum.ru (=?UTF-8?q?=D0=A0=D0=BE=D0=BC=D0=B0=D0=BD=20=D0=94=D0=BE=D0=BD=D1=87=D0=B5=D0=BD=D0=BA=D0=BE?=) Date: Thu, 3 Sep 2015 23:00:09 +0300 Subject: [cmake-developers] [PATCH] CPack: don't mangle CMake-special characters when applying default settings Message-ID: <1441310409-1172-1-git-send-email-dpb@corrigendum.ru> By using a function to do it instead of a macro. Deprecate the old macro, but keep it for backwards compatibility. Remove existing workarounds for this problem and add a test. --- Help/release/dev/CPack-updates.rst | 6 ++ Modules/CPack.cmake | 92 ++++++++++++++------------ Tests/RunCMake/CPackConfig/Default-check.cmake | 7 ++ Tests/RunCMake/CPackConfig/Default.cmake | 3 + Tests/RunCMake/CPackConfig/RunCMakeTest.cmake | 1 + Tests/RunCMake/CPackConfig/check.cmake | 4 ++ 6 files changed, 70 insertions(+), 43 deletions(-) create mode 100644 Help/release/dev/CPack-updates.rst create mode 100644 Tests/RunCMake/CPackConfig/Default-check.cmake create mode 100644 Tests/RunCMake/CPackConfig/Default.cmake diff --git a/Help/release/dev/CPack-updates.rst b/Help/release/dev/CPack-updates.rst new file mode 100644 index 0000000..7ac1ed7 --- /dev/null +++ b/Help/release/dev/CPack-updates.rst @@ -0,0 +1,6 @@ +CPack-updates +------------- + +* The :module:`CPack` module no longer mangles settings with CMake-special + characters when they're used as defaults for other settings. The macro + ``cpack_set_if_not_set``, which was responsible for this, is now deprecated. diff --git a/Modules/CPack.cmake b/Modules/CPack.cmake index e223286..9fe349c 100644 --- a/Modules/CPack.cmake +++ b/Modules/CPack.cmake @@ -299,10 +299,10 @@ endif() include(CPackComponent) # Macro for setting values if a user did not overwrite them +# Mangles CMake-special characters. Only kept for backwards compatibility. macro(cpack_set_if_not_set name value) - if(NOT DEFINED "${name}") - set(${name} "${value}") - endif() + message(DEPRECATION "cpack_set_if_not_set is obsolete; do not use.") + _cpack_set_default("${name}" "${value}") endmacro() # cpack_encode_variables - Macro to encode variables for the configuration file @@ -321,27 +321,35 @@ macro(cpack_encode_variables) endforeach() endmacro() +# Internal use functions + +function(_cpack_set_default name value) + if(NOT DEFINED "${name}") + set("${name}" "${value}" PARENT_SCOPE) + endif() +endfunction() + # Set the package name -cpack_set_if_not_set(CPACK_PACKAGE_NAME "${CMAKE_PROJECT_NAME}") -cpack_set_if_not_set(CPACK_PACKAGE_VERSION_MAJOR "0") -cpack_set_if_not_set(CPACK_PACKAGE_VERSION_MINOR "1") -cpack_set_if_not_set(CPACK_PACKAGE_VERSION_PATCH "1") -cpack_set_if_not_set(CPACK_PACKAGE_VERSION +_cpack_set_default(CPACK_PACKAGE_NAME "${CMAKE_PROJECT_NAME}") +_cpack_set_default(CPACK_PACKAGE_VERSION_MAJOR "0") +_cpack_set_default(CPACK_PACKAGE_VERSION_MINOR "1") +_cpack_set_default(CPACK_PACKAGE_VERSION_PATCH "1") +_cpack_set_default(CPACK_PACKAGE_VERSION "${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}") -cpack_set_if_not_set(CPACK_PACKAGE_VENDOR "Humanity") -cpack_set_if_not_set(CPACK_PACKAGE_DESCRIPTION_SUMMARY +_cpack_set_default(CPACK_PACKAGE_VENDOR "Humanity") +_cpack_set_default(CPACK_PACKAGE_DESCRIPTION_SUMMARY "${CMAKE_PROJECT_NAME} built using CMake") -cpack_set_if_not_set(CPACK_PACKAGE_DESCRIPTION_FILE +_cpack_set_default(CPACK_PACKAGE_DESCRIPTION_FILE "${CMAKE_ROOT}/Templates/CPack.GenericDescription.txt") -cpack_set_if_not_set(CPACK_RESOURCE_FILE_LICENSE +_cpack_set_default(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_ROOT}/Templates/CPack.GenericLicense.txt") -cpack_set_if_not_set(CPACK_RESOURCE_FILE_README +_cpack_set_default(CPACK_RESOURCE_FILE_README "${CMAKE_ROOT}/Templates/CPack.GenericDescription.txt") -cpack_set_if_not_set(CPACK_RESOURCE_FILE_WELCOME +_cpack_set_default(CPACK_RESOURCE_FILE_WELCOME "${CMAKE_ROOT}/Templates/CPack.GenericWelcome.txt") -cpack_set_if_not_set(CPACK_MODULE_PATH "${CMAKE_MODULE_PATH}") +_cpack_set_default(CPACK_MODULE_PATH "${CMAKE_MODULE_PATH}") if(CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL) set(CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL ON) @@ -359,7 +367,7 @@ if(__cpack_system_name MATCHES "Windows") set(__cpack_system_name win32) endif() endif() -cpack_set_if_not_set(CPACK_SYSTEM_NAME "${__cpack_system_name}") +_cpack_set_default(CPACK_SYSTEM_NAME "${__cpack_system_name}") # Root dir: default value should be the string literal "$PROGRAMFILES" # for backwards compatibility. Projects may set this value to anything. @@ -369,17 +377,17 @@ if("x${__cpack_system_name}" STREQUAL "xwin64") else() set(__cpack_root_default "$PROGRAMFILES") endif() -cpack_set_if_not_set(CPACK_NSIS_INSTALL_ROOT "${__cpack_root_default}") +_cpack_set_default(CPACK_NSIS_INSTALL_ROOT "${__cpack_root_default}") # -..--. -cpack_set_if_not_set(CPACK_PACKAGE_FILE_NAME +_cpack_set_default(CPACK_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION}-${CPACK_SYSTEM_NAME}") -cpack_set_if_not_set(CPACK_PACKAGE_INSTALL_DIRECTORY +_cpack_set_default(CPACK_PACKAGE_INSTALL_DIRECTORY "${CPACK_PACKAGE_NAME} ${CPACK_PACKAGE_VERSION}") -cpack_set_if_not_set(CPACK_PACKAGE_INSTALL_REGISTRY_KEY +_cpack_set_default(CPACK_PACKAGE_INSTALL_REGISTRY_KEY "${CPACK_PACKAGE_INSTALL_DIRECTORY}") -cpack_set_if_not_set(CPACK_PACKAGE_DEFAULT_LOCATION "/") -cpack_set_if_not_set(CPACK_PACKAGE_RELOCATABLE "true") +_cpack_set_default(CPACK_PACKAGE_DEFAULT_LOCATION "/") +_cpack_set_default(CPACK_PACKAGE_RELOCATABLE "true") # always force to exactly "true" or "false" for CPack.Info.plist.in: if(CPACK_PACKAGE_RELOCATABLE) @@ -519,10 +527,10 @@ mark_as_advanced( ) # Set some other variables -cpack_set_if_not_set(CPACK_INSTALL_CMAKE_PROJECTS +_cpack_set_default(CPACK_INSTALL_CMAKE_PROJECTS "${CMAKE_BINARY_DIR};${CMAKE_PROJECT_NAME};ALL;/") -cpack_set_if_not_set(CPACK_CMAKE_GENERATOR "${CMAKE_GENERATOR}") -cpack_set_if_not_set(CPACK_TOPLEVEL_TAG "${CPACK_SYSTEM_NAME}") +_cpack_set_default(CPACK_CMAKE_GENERATOR "${CMAKE_GENERATOR}") +_cpack_set_default(CPACK_TOPLEVEL_TAG "${CPACK_SYSTEM_NAME}") # if the user has set CPACK_NSIS_DISPLAY_NAME remember it if(DEFINED CPACK_NSIS_DISPLAY_NAME) set(CPACK_NSIS_DISPLAY_NAME_SET TRUE) @@ -531,34 +539,32 @@ endif() # explicitly, then use that as the default # value of CPACK_NSIS_PACKAGE_NAME instead # of CPACK_PACKAGE_INSTALL_DIRECTORY -cpack_set_if_not_set(CPACK_NSIS_DISPLAY_NAME "${CPACK_PACKAGE_INSTALL_DIRECTORY}") +_cpack_set_default(CPACK_NSIS_DISPLAY_NAME "${CPACK_PACKAGE_INSTALL_DIRECTORY}") if(CPACK_NSIS_DISPLAY_NAME_SET) - string(REPLACE "\\" "\\\\" - _NSIS_DISPLAY_NAME_TMP "${CPACK_NSIS_DISPLAY_NAME}") - cpack_set_if_not_set(CPACK_NSIS_PACKAGE_NAME "${_NSIS_DISPLAY_NAME_TMP}") + _cpack_set_default(CPACK_NSIS_PACKAGE_NAME "${CPACK_NSIS_DISPLAY_NAME}") else() - cpack_set_if_not_set(CPACK_NSIS_PACKAGE_NAME "${CPACK_PACKAGE_INSTALL_DIRECTORY}") + _cpack_set_default(CPACK_NSIS_PACKAGE_NAME "${CPACK_PACKAGE_INSTALL_DIRECTORY}") endif() -cpack_set_if_not_set(CPACK_OUTPUT_CONFIG_FILE +_cpack_set_default(CPACK_OUTPUT_CONFIG_FILE "${CMAKE_BINARY_DIR}/CPackConfig.cmake") -cpack_set_if_not_set(CPACK_SOURCE_OUTPUT_CONFIG_FILE +_cpack_set_default(CPACK_SOURCE_OUTPUT_CONFIG_FILE "${CMAKE_BINARY_DIR}/CPackSourceConfig.cmake") -cpack_set_if_not_set(CPACK_SET_DESTDIR OFF) -cpack_set_if_not_set(CPACK_INSTALL_PREFIX "${CMAKE_INSTALL_PREFIX}") +_cpack_set_default(CPACK_SET_DESTDIR OFF) +_cpack_set_default(CPACK_INSTALL_PREFIX "${CMAKE_INSTALL_PREFIX}") -cpack_set_if_not_set(CPACK_NSIS_INSTALLER_ICON_CODE "") -cpack_set_if_not_set(CPACK_NSIS_INSTALLER_MUI_ICON_CODE "") +_cpack_set_default(CPACK_NSIS_INSTALLER_ICON_CODE "") +_cpack_set_default(CPACK_NSIS_INSTALLER_MUI_ICON_CODE "") # WiX specific variables -cpack_set_if_not_set(CPACK_WIX_SIZEOF_VOID_P "${CMAKE_SIZEOF_VOID_P}") +_cpack_set_default(CPACK_WIX_SIZEOF_VOID_P "${CMAKE_SIZEOF_VOID_P}") # set sysroot so SDK tools can be used if(CMAKE_OSX_SYSROOT) - cpack_set_if_not_set(CPACK_OSX_SYSROOT "${CMAKE_OSX_SYSROOT}") + _cpack_set_default(CPACK_OSX_SYSROOT "${CMAKE_OSX_SYSROOT}") endif() if(DEFINED CPACK_COMPONENTS_ALL) @@ -598,13 +604,13 @@ cpack_encode_variables() configure_file("${cpack_input_file}" "${CPACK_OUTPUT_CONFIG_FILE}" @ONLY) # Generate source file -cpack_set_if_not_set(CPACK_SOURCE_INSTALLED_DIRECTORIES +_cpack_set_default(CPACK_SOURCE_INSTALLED_DIRECTORIES "${CMAKE_SOURCE_DIR};/") -cpack_set_if_not_set(CPACK_SOURCE_TOPLEVEL_TAG "${CPACK_SYSTEM_NAME}-Source") -cpack_set_if_not_set(CPACK_SOURCE_PACKAGE_FILE_NAME +_cpack_set_default(CPACK_SOURCE_TOPLEVEL_TAG "${CPACK_SYSTEM_NAME}-Source") +_cpack_set_default(CPACK_SOURCE_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION}-Source") -cpack_set_if_not_set(CPACK_SOURCE_IGNORE_FILES - "/CVS/;/\\\\\\\\.svn/;/\\\\\\\\.bzr/;/\\\\\\\\.hg/;/\\\\\\\\.git/;\\\\\\\\.swp$;\\\\\\\\.#;/#") +_cpack_set_default(CPACK_SOURCE_IGNORE_FILES + "/CVS/;/\\\\.svn/;/\\\\.bzr/;/\\\\.hg/;/\\\\.git/;\\\\.swp$;\\\\.#;/#") set(CPACK_INSTALL_CMAKE_PROJECTS "${CPACK_SOURCE_INSTALL_CMAKE_PROJECTS}") set(CPACK_INSTALLED_DIRECTORIES "${CPACK_SOURCE_INSTALLED_DIRECTORIES}") set(CPACK_GENERATOR "${CPACK_SOURCE_GENERATOR}") diff --git a/Tests/RunCMake/CPackConfig/Default-check.cmake b/Tests/RunCMake/CPackConfig/Default-check.cmake new file mode 100644 index 0000000..b67fe81 --- /dev/null +++ b/Tests/RunCMake/CPackConfig/Default-check.cmake @@ -0,0 +1,7 @@ +include(${RunCMake_SOURCE_DIR}/check.cmake) + +test_variable(CPACK_PACKAGE_INSTALL_REGISTRY_KEY "Foo\\Bar") +test_variable(CPACK_NSIS_PACKAGE_NAME "Bar\\Foo") + +test_variable(CPACK_SOURCE_IGNORE_FILES + "/CVS/;/\\.svn/;/\\.bzr/;/\\.hg/;/\\.git/;\\.swp$;\\.#;/#") diff --git a/Tests/RunCMake/CPackConfig/Default.cmake b/Tests/RunCMake/CPackConfig/Default.cmake new file mode 100644 index 0000000..3b3beb3 --- /dev/null +++ b/Tests/RunCMake/CPackConfig/Default.cmake @@ -0,0 +1,3 @@ +# two levels of escaping to pass through CPackConfig.cmake +set(CPACK_PACKAGE_INSTALL_DIRECTORY "Foo\\\\Bar") +set(CPACK_NSIS_DISPLAY_NAME "Bar\\\\Foo") diff --git a/Tests/RunCMake/CPackConfig/RunCMakeTest.cmake b/Tests/RunCMake/CPackConfig/RunCMakeTest.cmake index 6787eb8..ef018b5 100644 --- a/Tests/RunCMake/CPackConfig/RunCMakeTest.cmake +++ b/Tests/RunCMake/CPackConfig/RunCMakeTest.cmake @@ -1,3 +1,4 @@ include(RunCMake) run_cmake(Simple) +run_cmake(Default) diff --git a/Tests/RunCMake/CPackConfig/check.cmake b/Tests/RunCMake/CPackConfig/check.cmake index 2fc9f11..cafab70 100644 --- a/Tests/RunCMake/CPackConfig/check.cmake +++ b/Tests/RunCMake/CPackConfig/check.cmake @@ -1,3 +1,6 @@ +cmake_policy(SET CMP0011 NEW) +cmake_policy(SET CMP0010 NEW) # error out on broken escape sequences + function(test_variable NAME EXPECTED_VALUE) if(NOT "${${NAME}}" STREQUAL "${EXPECTED_VALUE}") message(FATAL_ERROR "${NAME}: variable mismatch; expected [${EXPECTED_VALUE}] actual [${${NAME}}]") @@ -5,3 +8,4 @@ function(test_variable NAME EXPECTED_VALUE) endfunction() include(${RunCMake_TEST_BINARY_DIR}/CPackConfig.cmake) +include(${RunCMake_TEST_BINARY_DIR}/CPackSourceConfig.cmake) -- 1.9.5.msysgit.0 From ben at salilab.org Fri Sep 4 17:33:37 2015 From: ben at salilab.org (Ben Webb) Date: Fri, 04 Sep 2015 14:33:37 -0700 Subject: [cmake-developers] [PATCH] Don't generate erroneous outputs with -noproxy. Message-ID: <201509042133.t84LXbKF028144@guitar.compbio.ucsf.edu> Generally for a module foo, SWIG generates (in Python mode) an extension module _foo.so and a proxy Python module foo.py. However, if -noproxy is specified, instead it builds only foo.so (without the leading underscore). The custom command generated by CMake correctly handles the removal of this underscore when -noproxy is given; however, it still adds foo.py to the expected outputs. This upsets build tools that expect foo.py to be generated (for example, 'make' will run the SWIG command twice). Fix this by removing foo.py from the set of extra generated files when -noproxy is specified. --- Modules/UseSWIG.cmake | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/Modules/UseSWIG.cmake b/Modules/UseSWIG.cmake index 96b0b35..d757f65 100644 --- a/Modules/UseSWIG.cmake +++ b/Modules/UseSWIG.cmake @@ -153,10 +153,12 @@ macro(SWIG_ADD_SOURCE_TO_MODULE name outfiles infile) else() set(swig_outdir ${CMAKE_CURRENT_BINARY_DIR}) endif() - SWIG_GET_EXTRA_OUTPUT_FILES(${SWIG_MODULE_${name}_LANGUAGE} - swig_extra_generated_files - "${swig_outdir}" - "${swig_source_file_fullname}") + if (NOT SWIG_MODULE_${name}_NOPROXY) + SWIG_GET_EXTRA_OUTPUT_FILES(${SWIG_MODULE_${name}_LANGUAGE} + swig_extra_generated_files + "${swig_outdir}" + "${swig_source_file_fullname}") + endif() set(swig_generated_file_fullname "${swig_outdir}/${swig_source_file_name_we}") # add the language into the name of the file (i.e. TCL_wrap) -- 2.3.2 (Apple Git-55) From mantis at public.kitware.com Sat Sep 5 15:49:29 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 5 Sep 2015 15:49:29 -0400 Subject: [cmake-developers] [CMake 0015727]: Support C compiler features for GNU on windows Message-ID: <66babff3a69ac4eb147bf4dad357e977@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15727 ====================================================================== Reported By: Lectem Assigned To: ====================================================================== Project: CMake Issue ID: 15727 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-05 15:49 EDT Last Modified: 2015-09-05 15:49 EDT ====================================================================== Summary: Support C compiler features for GNU on windows Description: When using target_compile_features(hello_world PRIVATE c_static_assert) I am getting this error : CMake Error at CMakeLists.txt:16 (target_compile_features): target_compile_features no known features for C compiler "GNU" version 5.1.0. Removing the UNIX check in Modules/Compiler/GNU-CXX.cmake fixed it Steps to Reproduce: Using mingw-w64 (x86_64) on windows Additional Information: Same problem as https://public.kitware.com/Bug/view.php?id=15443 but for C. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-05 15:49 Lectem New Issue ====================================================================== From mantis at public.kitware.com Sun Sep 6 00:48:58 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 6 Sep 2015 00:48:58 -0400 Subject: [cmake-developers] [CMake 0015728]: cmake-3.3.1 is a clever Dick Message-ID: <740b98f61faa5c6accaeff71be4a066d@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15728 ====================================================================== Reported By: szukw000 Assigned To: ====================================================================== Project: CMake Issue ID: 15728 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-06 00:48 EDT Last Modified: 2015-09-06 00:48 EDT ====================================================================== Summary: cmake-3.3.1 is a clever Dick Description: cmake-3.3.1 is a clever Dick: FindFLTK.cmake ==> /usr/local/fltk11/include But: which -a fltk-config /usr/local/fltk13/bin/fltk-config fltk-config --includedir /usr/local/fltk13/include winfried ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-06 00:48 szukw000 New Issue ====================================================================== From Simon.Richter at hogyros.de Sun Sep 6 01:16:28 2015 From: Simon.Richter at hogyros.de (Simon Richter) Date: Sun, 06 Sep 2015 07:16:28 +0200 Subject: [cmake-developers] Interface for GCC -fvisibility Message-ID: <55EBCC2C.1050307@hogyros.de> Hi, I'm trying to replace our package's own test for the existence of the -fvisibility flag with CMake's. I've found CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY, which is set if the flag exists, to something that you can directly append the desired default visibility to, so this is used by extending CXXFLAGS with "${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY}hidden" That still looks awfully compiler-specific to me, besides being ugly. Would it make sense to introduce a higher-level interface where I could specify whether I want implicit or explicit exports, and it would do the right thing? There is the variable CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS that does the exact opposite of the functionality I want -- basically I'd like to declare that my program has all exported functionality marked in the source code, and only these should be exported. 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 Geoffrey.Viola at asirobots.com Sun Sep 6 01:43:08 2015 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Sun, 6 Sep 2015 05:43:08 +0000 Subject: [cmake-developers] Improvements for GHS MULTI Generator Message-ID: Attached is a patch for some minor improvements for the GHS MULTI generator. Geoffrey Viola This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Improved-integration-with-GHS-MULTI.patch Type: application/octet-stream Size: 5038 bytes Desc: 0002-Improved-integration-with-GHS-MULTI.patch URL: From mantis at public.kitware.com Sun Sep 6 04:36:23 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 6 Sep 2015 04:36:23 -0400 Subject: [cmake-developers] [CMake 0015729]: ninja: TARGET_OBJECTS not working, ObjectDirectory and ObjectPathMax used before they are set Message-ID: <962c919f42250a4ae9eaae7b7a0a64c8@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15729 ====================================================================== Reported By: Stefan B?hler Assigned To: ====================================================================== Project: CMake Issue ID: 15729 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-06 04:36 EDT Last Modified: 2015-09-06 04:36 EDT ====================================================================== Summary: ninja: TARGET_OBJECTS not working, ObjectDirectory and ObjectPathMax used before they are set Description: I converted a project to Qt5, and TARGET_OBJECTS are not working across directories anymore with ninja; traditional make is still working. I pulled cmake from git (master 9e64fda6a77b49b394835dadba0e2951580eb86b), and got even stranger errors (but not everytime) that CMAKE_OBJECT_PATH_MAX was 0 and the "Object file ... cannot be safely placed under this directory.". I added some debugging and got a backtrace like this: https://public.kitware.com/Bug/view.php?id=0 cmLocalGenerator::CreateSafeUniqueObjectFileName (this=0x12f2010, sin=..., dir_max=...) at ../Source/cmLocalGenerator.cxx:2660 https://public.kitware.com/Bug/view.php?id=1 0x0000000000aeab84 in cmLocalGenerator::GetObjectFileNameWithoutTarget (this=0x12f2010, source=..., dir_max=..., hasSourceExtension=0x0) at ../Source/cmLocalGenerator.cxx:2810 https://public.kitware.com/Bug/view.php?id=2 0x00000000009223a5 in cmLocalNinjaGenerator::ComputeObjectFilenames (this=0x12f2010, mapping=..., gt=0x13ea920) at ../Source/cmLocalNinjaGenerator.cxx:269 https://public.kitware.com/Bug/view.php?id=3 0x0000000000a5ddec in cmGeneratorTarget::GetObjectSources (this=0x13ea920, data=..., config=...) at ../Source/cmGeneratorTarget.cxx:480 https://public.kitware.com/Bug/view.php?id=4 0x0000000000a4b820 in TargetObjectsNode::Evaluate (this=0xfdd3c0 , parameters=..., context=0x7fffffffb010, content=0x131d850) at ../Source/cmGeneratorExpressionNode.cxx:1285 https://public.kitware.com/Bug/view.php?id=5 0x0000000000a413f6 in GeneratorExpressionContent::Evaluate[abi:cxx11](cmGeneratorExpressionContext*, cmGeneratorExpressionDAGChecker*) const (this=0x131d850, context=0x7fffffffb010, dagChecker=0x7fffffffb720) at ../Source/cmGeneratorExpressionEvaluator.cxx:154 https://public.kitware.com/Bug/view.php?id=6 0x0000000000a5856c in cmCompiledGeneratorExpression::EvaluateWithContext (this=0x132cff0, context=..., dagChecker=0x7fffffffb720) at ../Source/cmGeneratorExpression.cxx:101 https://public.kitware.com/Bug/view.php?id=7 0x0000000000a58474 in cmCompiledGeneratorExpression::Evaluate (this=0x132cff0, mf=0x130f300, config=..., quiet=false, headTarget=0x1333028, currentTarget=0x1333028, dagChecker=0x7fffffffb720, language=...) at ../Source/cmGeneratorExpression.cxx:79 https://public.kitware.com/Bug/view.php?id=8 0x00000000008d140d in processSources (tgt=0x1333028, entries=..., srcs=..., uniqueSrcs=..., dagChecker=0x7fffffffb720, config=..., debugSources=false) at ../Source/cmTarget.cxx:557 https://public.kitware.com/Bug/view.php?id=9 0x00000000008d21b7 in cmTarget::GetSourceFiles (this=0x1333028, files=..., config=...) at ../Source/cmTarget.cxx:700 https://public.kitware.com/Bug/view.php?id=10 0x00000000008d25e8 in cmTarget::GetSourceFiles (this=0x1333028, files=..., config=...) at ../Source/cmTarget.cxx:750 https://public.kitware.com/Bug/view.php?id=11 0x0000000000a70b8a in cmGeneratorTarget::GetConfigCommonSourceFiles (this=0x13f0240, files=...) at ../Source/cmGeneratorTarget.cxx:4431 https://public.kitware.com/Bug/view.php?id=12 0x0000000000888ecd in cmQtAutoGenerators::InitializeAutogenTarget (this=0x7fffffffc6d0, lg=0x1312970, target=0x1333028) at ../Source/cmQtAutoGenerators.cxx:408 https://public.kitware.com/Bug/view.php?id=13 0x0000000000a99924 in cmGlobalGenerator::CreateQtAutoGeneratorsTargets (this=0x101ad40, autogens=...) at ../Source/cmGlobalGenerator.cxx:1465 https://public.kitware.com/Bug/view.php?id=14 0x0000000000a986c3 in cmGlobalGenerator::Compute (this=0x101ad40) at ../Source/cmGlobalGenerator.cxx:1272 https://public.kitware.com/Bug/view.php?id=15 0x0000000000900927 in cmake::Generate (this=0x7fffffffd7f0) at ../Source/cmake.cxx:1770 https://public.kitware.com/Bug/view.php?id=16 0x0000000000900783 in cmake::Run (this=0x7fffffffd7f0, args=..., noconfigure=false) at ../Source/cmake.cxx:1757 https://public.kitware.com/Bug/view.php?id=17 0x00000000008197d5 in do_cmake (ac=4, av=0x10111f0) at ../Source/cmakemain.cxx:330 https://public.kitware.com/Bug/view.php?id=18 0x0000000000818d8a in main (ac=4, av=0x10111f0) at ../Source/cmakemain.cxx:190 CreateQtAutoGeneratorsTargets gets called before ComputeObjectMaxPath in cmGlobalGenerator::Compute, and ObjectPathMax is not initialized, i.e. has a random value at that point (for me 0 or 1). Also it turned out gt->ObjectDirectory is empty when TargetObjectsNode::Evaluate is called in a similar backtrace from CreateQtAutoGeneratorsTargets, which is why newer cmake version can't find the object files (older cmake versions simply drop the object, leading to undefined symbols during linking). Moving the call to CreateQtAutoGeneratorsTargets below InitGeneratorTargets fixes it; calling ComputeTargetObjectDirectory and ComputeObjectMaxPath on demand and initializing ObjectPathMax to 0 fixes it too. Steps to Reproduce: git clone -b v0.6.0 https://github.com/dosnut/nut cd nut mkdir build cd build cmake -G Ninja .. ninja cnut ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-06 04:36 Stefan B?hler New Issue ====================================================================== From Simon.Richter at hogyros.de Sun Sep 6 12:26:46 2015 From: Simon.Richter at hogyros.de (Simon Richter) Date: Sun, 06 Sep 2015 18:26:46 +0200 Subject: [cmake-developers] [PATCH 2/3] wxWidgets module: Expect wxWidgets 3.1 In-Reply-To: <3438415.E4kMjXBYYs@caliban.sf-tec.de> References: <1430521180-9336-1-git-send-email-Simon.Richter@hogyros.de> <1430521180-9336-2-git-send-email-Simon.Richter@hogyros.de> <1430521180-9336-3-git-send-email-Simon.Richter@hogyros.de> <3438415.E4kMjXBYYs@caliban.sf-tec.de> Message-ID: <55EC6946.6050200@hogyros.de> Hi, On 02.05.2015 09:43, Rolf Eike Beer wrote: >> @@ -746,7 +750,7 @@ else() >> # UNIX: Start actual work. >> #----------------------------------------------------------------- >> # Support cross-compiling, only search in the target platform. >> - find_program(wxWidgets_CONFIG_EXECUTABLE wx-config wx-config-3.0 >> + find_program(wxWidgets_CONFIG_EXECUTABLE wx-config wx-config-3.0 >> wx-config-3.1 DOC "Location of wxWidgets library configuration provider >> binary (wx-config)." ONLY_CMAKE_FIND_ROOT_PATH >> ) > I would expect here (and probably at the other places, too), that you would > not search for 3.1 if I specified "3.0 EXACT", or not search for 3.0 if I > requested at least 3.1. That is difficult -- find_program will use the first one it finds, and there is no good way to return here from FPHSA. 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 Sun Sep 6 12:35:36 2015 From: Simon.Richter at hogyros.de (Simon Richter) Date: Sun, 6 Sep 2015 18:35:36 +0200 Subject: [cmake-developers] [PATCH 1/3] wxWidgets module: allow specifying required version In-Reply-To: <1441557338-25895-1-git-send-email-Simon.Richter@hogyros.de> References: <1441557338-25895-1-git-send-email-Simon.Richter@hogyros.de> Message-ID: <1441557338-25895-2-git-send-email-Simon.Richter@hogyros.de> --- Modules/FindwxWidgets.cmake | 31 ++++++++++++++++++++++++++++--- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git a/Modules/FindwxWidgets.cmake b/Modules/FindwxWidgets.cmake index 9a70678..0c95529 100644 --- a/Modules/FindwxWidgets.cmake +++ b/Modules/FindwxWidgets.cmake @@ -857,6 +857,28 @@ else() endif() endif() +# Check if a specfic version was requested by find_package(). +if(wxWidgets_FOUND) + find_file(_filename wx/version.h PATHS ${wxWidgets_INCLUDE_DIRS} NO_DEFAULT_PATH) + dbg_msg("_filename: ${_filename}") + + if(NOT _filename) + message(FATAL_ERROR "wxWidgets wx/version.h file not found in ${wxWidgets_INCLUDE_DIRS}.") + endif() + + file(READ ${_filename} _wx_version_h) + + string(REGEX REPLACE "^(.*\n)?#define +wxMAJOR_VERSION +([0-9]+).*" + "\\2" wxWidgets_VERSION_MAJOR "${_wx_version_h}" ) + string(REGEX REPLACE "^(.*\n)?#define +wxMINOR_VERSION +([0-9]+).*" + "\\2" wxWidgets_VERSION_MINOR "${_wx_version_h}" ) + string(REGEX REPLACE "^(.*\n)?#define +wxRELEASE_NUMBER +([0-9]+).*" + "\\2" wxWidgets_VERSION_PATCH "${_wx_version_h}" ) + set(wxWidgets_VERSION_STRING + "${wxWidgets_VERSION_MAJOR}.${wxWidgets_VERSION_MINOR}.${wxWidgets_VERSION_PATCH}" ) + dbg_msg("wxWidgets_VERSION_STRING: ${wxWidgets_VERSION_STRING}") +endif() + # Debug output: DBG_MSG("wxWidgets_FOUND : ${wxWidgets_FOUND}") DBG_MSG("wxWidgets_INCLUDE_DIRS : ${wxWidgets_INCLUDE_DIRS}") @@ -867,10 +889,13 @@ DBG_MSG("wxWidgets_USE_FILE : ${wxWidgets_USE_FILE}") #===================================================================== #===================================================================== + include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) -FIND_PACKAGE_HANDLE_STANDARD_ARGS(wxWidgets DEFAULT_MSG wxWidgets_FOUND) -# Maintain consistency with all other variables. -set(wxWidgets_FOUND ${WXWIDGETS_FOUND}) + +find_package_handle_standard_args(wxWidgets + REQUIRED_VARS wxWidgets_LIBRARIES wxWidgets_INCLUDE_DIRS + VERSION_VAR wxWidgets_VERSION_STRING + ) #===================================================================== # Macros for use in wxWidgets apps. -- 2.1.4 From Simon.Richter at hogyros.de Sun Sep 6 12:35:37 2015 From: Simon.Richter at hogyros.de (Simon Richter) Date: Sun, 6 Sep 2015 18:35:37 +0200 Subject: [cmake-developers] [PATCH 2/3] wxWidgets module: Expect wxWidgets 3.1 In-Reply-To: <1441557338-25895-2-git-send-email-Simon.Richter@hogyros.de> References: <1441557338-25895-1-git-send-email-Simon.Richter@hogyros.de> <1441557338-25895-2-git-send-email-Simon.Richter@hogyros.de> Message-ID: <1441557338-25895-3-git-send-email-Simon.Richter@hogyros.de> --- Modules/FindwxWidgets.cmake | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Modules/FindwxWidgets.cmake b/Modules/FindwxWidgets.cmake index 0c95529..52aafd7 100644 --- a/Modules/FindwxWidgets.cmake +++ b/Modules/FindwxWidgets.cmake @@ -302,6 +302,7 @@ if(wxWidgets_FIND_STYLE STREQUAL "win32") # Find wxWidgets multilib base libraries. find_library(WX_base${_DBG} NAMES + wxbase31${_UCD}${_DBG} wxbase30${_UCD}${_DBG} wxbase29${_UCD}${_DBG} wxbase28${_UCD}${_DBG} @@ -315,6 +316,7 @@ if(wxWidgets_FIND_STYLE STREQUAL "win32") foreach(LIB net odbc xml) find_library(WX_${LIB}${_DBG} NAMES + wxbase31${_UCD}${_DBG}_${LIB} wxbase30${_UCD}${_DBG}_${LIB} wxbase29${_UCD}${_DBG}_${LIB} wxbase28${_UCD}${_DBG}_${LIB} @@ -330,6 +332,7 @@ if(wxWidgets_FIND_STYLE STREQUAL "win32") # Find wxWidgets monolithic library. find_library(WX_mono${_DBG} NAMES + wxmsw${_UNV}31${_UCD}${_DBG} wxmsw${_UNV}30${_UCD}${_DBG} wxmsw${_UNV}29${_UCD}${_DBG} wxmsw${_UNV}28${_UCD}${_DBG} @@ -346,6 +349,7 @@ if(wxWidgets_FIND_STYLE STREQUAL "win32") stc ribbon propgrid webview) find_library(WX_${LIB}${_DBG} NAMES + wxmsw${_UNV}31${_UCD}${_DBG}_${LIB} wxmsw${_UNV}30${_UCD}${_DBG}_${LIB} wxmsw${_UNV}29${_UCD}${_DBG}_${LIB} wxmsw${_UNV}28${_UCD}${_DBG}_${LIB} @@ -741,7 +745,7 @@ else() #----------------------------------------------------------------- # Support cross-compiling, only search in the target platform. find_program(wxWidgets_CONFIG_EXECUTABLE - NAMES wx-config wx-config-3.0 wx-config-2.9 wx-config-2.8 + NAMES wx-config wx-config-3.1 wx-config-3.0 wx-config-2.9 wx-config-2.8 DOC "Location of wxWidgets library configuration provider binary (wx-config)." ONLY_CMAKE_FIND_ROOT_PATH ) -- 2.1.4 From Simon.Richter at hogyros.de Sun Sep 6 12:35:35 2015 From: Simon.Richter at hogyros.de (Simon Richter) Date: Sun, 6 Sep 2015 18:35:35 +0200 Subject: [cmake-developers] [PATCH 0/3] FindwxWidgets improvements Message-ID: <1441557338-25895-1-git-send-email-Simon.Richter@hogyros.de> Hi, three small improvements for FindwxWidgets.cmake. I've already sent these in May, and I've incorporated all but one of the comments I've got so far. The last remaining issue, ignoring wx-config with the wrong version if a specific version was requested, is difficult to implement as the version mismatch is detected in FPHSA, where it is too late to go back to look for another version. Other than that, I think these are worthwhile additions. Simon Simon Richter (3): wxWidgets module: allow specifying required version wxWidgets module: Expect wxWidgets 3.1 wxWidgets module: Add wxWidgets webview component Modules/FindwxWidgets.cmake | 39 ++++++++++++++++++++++++++++++++++----- 1 file changed, 34 insertions(+), 5 deletions(-) -- 2.1.4 From Simon.Richter at hogyros.de Sun Sep 6 12:35:38 2015 From: Simon.Richter at hogyros.de (Simon Richter) Date: Sun, 6 Sep 2015 18:35:38 +0200 Subject: [cmake-developers] [PATCH 3/3] wxWidgets module: Add wxWidgets webview component In-Reply-To: <1441557338-25895-3-git-send-email-Simon.Richter@hogyros.de> References: <1441557338-25895-1-git-send-email-Simon.Richter@hogyros.de> <1441557338-25895-2-git-send-email-Simon.Richter@hogyros.de> <1441557338-25895-3-git-send-email-Simon.Richter@hogyros.de> Message-ID: <1441557338-25895-4-git-send-email-Simon.Richter@hogyros.de> --- Modules/FindwxWidgets.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Modules/FindwxWidgets.cmake b/Modules/FindwxWidgets.cmake index 52aafd7..54a74f6 100644 --- a/Modules/FindwxWidgets.cmake +++ b/Modules/FindwxWidgets.cmake @@ -390,7 +390,7 @@ if(wxWidgets_FIND_STYLE STREQUAL "win32") # Clear wxWidgets multilib libraries. foreach(LIB core adv aui html media xrc dbgrid gl qa richtext - stc ribbon propgrid) + webview stc ribbon propgrid) WX_CLEAR_LIB(WX_${LIB}${_DBG}) endforeach() endmacro() -- 2.1.4 From robert.maynard at kitware.com Mon Sep 7 12:46:56 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 7 Sep 2015 12:46:56 -0400 Subject: [cmake-developers] Interface for GCC -fvisibility In-Reply-To: <55EBCC2C.1050307@hogyros.de> References: <55EBCC2C.1050307@hogyros.de> Message-ID: The better approach is to use the CXX/C target property _VISIBILITY_PRESET or set the CMAKE__VISIBILITY_PRESET global variable. These when true will automatically enable the visibility flag. see: http://www.cmake.org/cmake/help/v3.0/prop_tgt/LANG_VISIBILITY_PRESET.html On Sun, Sep 6, 2015 at 1:16 AM, Simon Richter wrote: > Hi, > > I'm trying to replace our package's own test for the existence of the > -fvisibility flag with CMake's. > > I've found CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY, which is set if the > flag exists, to something that you can directly append the desired > default visibility to, so this is used by extending CXXFLAGS with > > "${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY}hidden" > > That still looks awfully compiler-specific to me, besides being ugly. > Would it make sense to introduce a higher-level interface where I could > specify whether I want implicit or explicit exports, and it would do the > right thing? > > There is the variable CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS that does the > exact opposite of the functionality I want -- basically I'd like to > declare that my program has all exported functionality marked in the > source code, and only these should be exported. > > Simon > > > -- > > 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 Geoffrey.Viola at asirobots.com Mon Sep 7 22:36:58 2015 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Tue, 8 Sep 2015 02:36:58 +0000 Subject: [cmake-developers] New Nightly Build Server Message-ID: I setup a new server to run the nightly ctest test suite. It's named "builder.asi" and should be more reliable than "glv.asi" and also run the GHSMulti tests. Even though the systems, compilers, and CMake variables are nearly identical, there are some differences between the two servers. Since the builder.asi server runs as an administrator, it has some issues running the VSMidl test. It resolved the "USERPROFILE" environment variable as a path in system32, which I assumed caused some writing issues. I set the "CTEST_REAL_HOME" environment variable to the CTEST_DASHBOARD_ROOT CMake variable and now it passes. Also, there are two test case fewer in builder.asi than glv.asi. Geoffrey Viola This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Tue Sep 8 08:51:12 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 8 Sep 2015 08:51:12 -0400 Subject: [cmake-developers] [CMake 0015730]: foreach() mis items from list when brackets are unclosed Message-ID: <66bb3ee5144fdb34099d1b90434266cd@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15730 ====================================================================== Reported By: nmeunier Assigned To: ====================================================================== Project: CMake Issue ID: 15730 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-08 08:51 EDT Last Modified: 2015-09-08 08:51 EDT ====================================================================== Summary: foreach() mis items from list when brackets are unclosed Description: I wanted to read all lines of a file, and iterate on them. But I wasn't same account of line in my ''foreach()'' as there was in my file. The last iterated line was like a concatenation of all remaining lines of the file. The cause is the incorrect item was containing an opening bracket '['. Steps to Reproduce: function(test_list_items _nb_lines _lines) set(_i 0) message("-- test '${_lines}'") # string(REPLACE "]" "" _lines "${_lines}") # string(REPLACE "[" "" _lines "${_lines}") foreach (_l IN LISTS _lines) math(EXPR _i "${_i}+1") message(" ${_i}: '${_l}'") endforeach() if (NOT _i EQUAL ${_nb_lines}) message(" ${_i} != ${_nb_lines}") else() message(" OK") endif() endfunction() set(_a "line-1;line-2\;;line-3 // [;line-4") test_list_items(4 "${_a}") set(_a "line-1;line-2\;;line-3 // ];line-4") test_list_items(4 "${_a}") set(_a "line-1;line-2\; // [;line-3 // ];line-4") test_list_items(4 "${_a}") set(_a "line-1;line-2\; // ];line-3 // [;line-4") test_list_items(4 "${_a}") set(_a "line-1;line-2\; // {;line-3 // };line-4") test_list_items(4 "${_a}") set(_a "line-1;line-2\;;line-3 // {;line-4") test_list_items(4 "${_a}") set(_a "line-1;line-2\;;line-3 // };line-4") test_list_items(4 "${_a}") Here is the output: -- test 'line-1;line-2\;;line-3 // [;line-4' 1: 'line-1' 2: 'line-2;' 3: 'line-3 // [;line-4' 3 != 4 -- test 'line-1;line-2\;;line-3 // ];line-4' 1: 'line-1' 2: 'line-2;' 3: 'line-3 // ];line-4' 3 != 4 -- test 'line-1;line-2\; // [;line-3 // ];line-4' 1: 'line-1' 2: 'line-2; // [;line-3 // ]' 3: 'line-4' 3 != 4 -- test 'line-1;line-2\; // ];line-3 // [;line-4' 1: 'line-1' 2: 'line-2; // ];line-3 // [' 3: 'line-4' 3 != 4 -- test 'line-1;line-2\; // {;line-3 // };line-4' 1: 'line-1' 2: 'line-2; // {' 3: 'line-3 // }' 4: 'line-4' OK -- test 'line-1;line-2\;;line-3 // {;line-4' 1: 'line-1' 2: 'line-2;' 3: 'line-3 // {' 4: 'line-4' OK -- test 'line-1;line-2\;;line-3 // };line-4' 1: 'line-1' 2: 'line-2;' 3: 'line-3 // }' 4: 'line-4' OK Additional Information: The only workaround I found is to add these transformation before the ''foreach()'': string(REPLACE "]" "" _lines "${_lines}") string(REPLACE "[" "" _lines "${_lines}") ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-08 08:51 nmeunier New Issue ====================================================================== From mantis at public.kitware.com Wed Sep 9 08:37:08 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 9 Sep 2015 08:37:08 -0400 Subject: [cmake-developers] [CMake 0015731]: VS_DEPLOYMENT_CONTENT Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15731 ====================================================================== Reported By: Marco Foco Assigned To: ====================================================================== Project: CMake Issue ID: 15731 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-09 08:37 EDT Last Modified: 2015-09-09 08:37 EDT ====================================================================== Summary: VS_DEPLOYMENT_CONTENT Description: Reading the documentation for the property VS_DEPLOYMENT_CONTENT looks like it can be used to mark a file as "Excluded from build": http://www.cmake.org/cmake/help/v3.3/prop_sf/VS_DEPLOYMENT_CONTENT.html "Mark a source file as content for deployment with a Windows Phone or Windows Store application when built with a Visual Studio generator. The value must evaluate to either 1 or 0 and may use generator expressions to make the choice based on the build configuration. The .vcxproj file entry for the source file will be marked either DeploymentContent or ExcludedFromBuild for values 1 and 0, respectively." Actually, this is not working in a plain C++ project. I suspect that the note "with a Windows Phone or Windows Store application" restricts the activity of this flag. The workaround of marking a C++ file as HEADER_FILE_ONLY TRUE is inconvenient, because it does not put a mark in the solution explorer (making very difficult to spot the excluded files). Steps to Reproduce: - add a file - mark it as VS_DEPLOYMENT_CONTENT 0 (or FALSE, tested with both) Load the vcxproj and notice that the file is not marked as "Excluded from build" by right-clicking on the files and selecting "Properties" ("Excluded from build" is actually empty, which defaults to false). Additional Information: Related tickets (same problem, different solution proposed, all unimplemented: http://public.kitware.com/Bug/view.php?id=6314 http://public.kitware.com/Bug/view.php?id=11902 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-09 08:37 Marco Foco New Issue ====================================================================== From brad.king at kitware.com Wed Sep 9 11:00:01 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Sep 2015 11:00:01 -0400 Subject: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module In-Reply-To: References: <1863012101.3782681.1441208121250.JavaMail.root@mail.gatech.edu> <55E717F7.3030902@kitware.com> Message-ID: <55F04971.7020509@kitware.com> On 09/03/2015 05:16 AM, Paul Romano wrote: > Brad- here's a new patch based off of 8ea7611 that uses the new > NAMES_PER_DIR option of find_program as well adds the HDF5_PREFER_PARALLEL Thanks. Please unset() the _NAMES variables when finished so that they are not exposed publicly. Also please extend the module documentation to mention HDF5_PREFER_PARALLEL. Thanks, -Brad From brad.king at kitware.com Wed Sep 9 10:59:54 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Sep 2015 10:59:54 -0400 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: References: <55E4B396.9090609@kitware.com> <55E714E1.10505@kitware.com> Message-ID: <55F0496A.1040205@kitware.com> On 09/03/2015 03:19 PM, Gilles Khouzam wrote: > Perhaps the default selection (at least for Store apps since that's > the one that requires the flag) should be the newest SDK less than > the version of the host System. Yes, I think that makes sense. Thanks, -Brad From brad.king at kitware.com Wed Sep 9 11:00:07 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Sep 2015 11:00:07 -0400 Subject: [cmake-developers] [CMake] Visual Studio - Ninja Generator In-Reply-To: <053901d0e5b6$6c47ae70$44d70b50$@motionview3d.com> References: <55E48101.2010502@gmail.com> <053901d0e5b6$6c47ae70$44d70b50$@motionview3d.com> Message-ID: <55F04977.6040101@kitware.com> On 09/02/2015 03:34 PM, James Johnston wrote: > useful if the Visual Studio generators in CMake were refactored somewhat Even without the C# motivation I think factoring out a "MSBuild" generator infrastructure internally will be useful. Currently we call it "VS 10" because it happened to be the first version to use MSBuild project files. Are you proposing to have some kind of internal object model for the MSBuild project files to separate their construction from the actual generation? > it would be useful to have Visual Studio available as an "Extra" CMake > generator. For example, specification of "Visual Studio 2015 - Ninja" This functionality sounds reasonable but the name of the extra/generator pair looks funny when spelled out that way. We should consider having another way to specify the extra generator. -Brad From brad.king at kitware.com Wed Sep 9 11:00:23 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Sep 2015 11:00:23 -0400 Subject: [cmake-developers] [PATCH] Don't generate erroneous outputs with -noproxy. In-Reply-To: <201509042133.t84LXbKF028144@guitar.compbio.ucsf.edu> References: <201509042133.t84LXbKF028144@guitar.compbio.ucsf.edu> Message-ID: <55F04987.6000406@kitware.com> On 09/04/2015 05:33 PM, Ben Webb wrote: > Modules/UseSWIG.cmake | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) Applied, thanks: FindSWIG: Do not generate erroneous outputs with -noproxy http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=96a8890c -Brad From brad.king at kitware.com Wed Sep 9 11:00:32 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Sep 2015 11:00:32 -0400 Subject: [cmake-developers] Improvements for GHS MULTI Generator In-Reply-To: References: Message-ID: <55F04990.6080301@kitware.com> On 09/06/2015 01:43 AM, Geoffrey Viola wrote: > Attached is a patch for some minor improvements for the GHS MULTI generator. Thanks. The commit message mentions a few different changes. I tried to split the changes into individual commits: GHS: Find latest 'int' directory http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=63591b94 GHS: Tell MULTI to delete .elf.ael file http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fbe0de92 GHS: Fix generated file path slashes and quoting for 6.1.6 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=04de9007 Please check that this breakdown is correct. For future changes please try to send them as patch series broken down like this. (The only reason I did so much squashing of the original GHS support was because it was brand new.) Thanks, -Brad From brad.king at kitware.com Wed Sep 9 11:01:16 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Sep 2015 11:01:16 -0400 Subject: [cmake-developers] New Nightly Build Server In-Reply-To: References: Message-ID: <55F049BC.3040008@kitware.com> On 09/07/2015 10:36 PM, Geoffrey Viola wrote: > I setup a new server to run the nightly ctest test suite. > It's named "builder.asi" Thanks. I've added it to the "Nightly Expected" section of the dashboard. -Brad From brad.king at kitware.com Wed Sep 9 11:01:23 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Sep 2015 11:01:23 -0400 Subject: [cmake-developers] [PATCH 0/3] FindwxWidgets improvements In-Reply-To: <1441557338-25895-1-git-send-email-Simon.Richter@hogyros.de> References: <1441557338-25895-1-git-send-email-Simon.Richter@hogyros.de> Message-ID: <55F049C3.4040407@kitware.com> On 09/06/2015 12:35 PM, Simon Richter wrote: > three small improvements for FindwxWidgets.cmake. I've already sent these > in May, and I've incorporated all but one of the comments I've got so far. Thanks. I've applied and merged to 'next' for testing: FindwxWidgets: allow specifying required version http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6089fde5 FindwxWidgets: Expect wxWidgets 3.1 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8122fbd0 FindwxWidgets: Add wxWidgets webview component http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=15aacb68 -Brad From brad.king at kitware.com Wed Sep 9 11:01:59 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Sep 2015 11:01:59 -0400 Subject: [cmake-developers] find_program HINTS no longer preferred over PATH (was: HINTS not correctly handled in find_program) In-Reply-To: <2A8C1310-D3AA-404A-88A3-5298D04A35AC@sap.com> References: <55E6F28E.1080706@kitware.com> <7F62CA7F-33C7-4D39-BA2C-D3D5669973B1@sap.com> <55E71955.1070603@kitware.com> <2A8C1310-D3AA-404A-88A3-5298D04A35AC@sap.com> Message-ID: <55F049E7.7080903@kitware.com> On 09/03/2015 03:51 AM, CHEVRIER, Marc wrote: > 1. Build phase. Under find_program.BUG/build, use CMakeLists.txt to prepare runtime part > 2. Test phase. Under find_program.BUG/runtime, use CMakeLists.txt to show the bug. Thanks, Marc. Chuck, this was regressed by your changes in CMake 3.2: Merge topic 'refactor-search-path-construction' http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dd89506c Please revise the logic to preserve the documented behavior: http://www.cmake.org/cmake/help/v3.3/command/find_program.html HINTS should be preferred before ENV{PATH}. Please also add appropriate test cases (e.g. Tests/RunCMake/find_program) and also check the behavior for other find_* commands. Thanks, -Brad From brad.king at kitware.com Wed Sep 9 11:02:12 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Sep 2015 11:02:12 -0400 Subject: [cmake-developers] use-generator-target topic regressed buildsystem properties Message-ID: <55F049F4.5050703@kitware.com> Steve, The topic merged here: Merge topic 'use-generator-target' http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6e5953e9 regressed handling of the buildsystem-aware properties. I fixed some of the problems and added test cases. Please see these commits: cmTarget: Fix buildsystem property empty value set and append operations http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cf74fc24 cmTarget: Fix memory leak when SOURCES property is cleared http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=407ff47e Tests: Cover set_property for buildsystem target properties http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b9856862 However, additional problems remain. I've attached updates to the test suite that demonstrate the failures. The problem is distinguishing an appended empty value from the empty sentinel values used in cmState. As shown by the USER_PROP test cases added above and in the attached patch, the behavior for non-buildsystem properties is to never append empty values. That was changed at some point in the past for buildsystem property values when we started recording internal data structures to store them. One possible fix to the problems is to avoid allowing empty values to be appended at all as is done for non-buildsystem properties. However, we still need to support setting a property to exactly the empty string. Please take a look. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Tests-Cover-set_property-for-buildsystem-directory-p.patch Type: text/x-diff Size: 5364 bytes Desc: not available URL: From brad.king at kitware.com Wed Sep 9 11:06:03 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Sep 2015 11:06:03 -0400 Subject: [cmake-developers] CMake 3.4 feature freeze on 2015-10-01 Message-ID: <55F04ADB.1000003@kitware.com> Hi Folks, The feature freeze in 'master' for CMake 3.4 will be on Oct 1, 2015. I will announce a freeze in 'next' sometime in the preceding week so that we can get any remaining dashboard trouble cleaned up. Please schedule any planned topics accordingly. Any major or disruptive changes should be completed a few weeks prior to the freeze or delayed until after 'next' re-opens. (Which is basically this week; sorry I neglected to send this announcement earlier.) Thanks, -Brad From hobbes1069 at gmail.com Wed Sep 9 11:46:51 2015 From: hobbes1069 at gmail.com (Richard Shaw) Date: Wed, 9 Sep 2015 10:46:51 -0500 Subject: [cmake-developers] [PATCH 0/3] FindwxWidgets improvements In-Reply-To: <1441557338-25895-1-git-send-email-Simon.Richter@hogyros.de> References: <1441557338-25895-1-git-send-email-Simon.Richter@hogyros.de> Message-ID: On Sun, Sep 6, 2015 at 11:35 AM, Simon Richter wrote: > Hi, > > three small improvements for FindwxWidgets.cmake. I've already sent these > in May, and I've incorporated all but one of the comments I've got so far. > > The last remaining issue, ignoring wx-config with the wrong version if a > specific version was requested, is difficult to implement as the version > mismatch is detected in FPHSA, where it is too late to go back to look for > another version. > > Other than that, I think these are worthwhile additions. Thanks for the updates! I was trying to find some time to review but looks like Brad already took care of it. I don't suppose you'd want to help me maintain the module in a more official capacity? I took it because it was unmaintained and I needed some specific changes but I'm hardly qualified and I only use it on Linux. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Sep 9 11:49:25 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Sep 2015 11:49:25 -0400 Subject: [cmake-developers] [PATCH 0/3] FindwxWidgets improvements In-Reply-To: References: <1441557338-25895-1-git-send-email-Simon.Richter@hogyros.de> Message-ID: <55F05505.9050606@kitware.com> On 09/09/2015 11:46 AM, Richard Shaw wrote: > I don't suppose you'd want to help me maintain the module in a more > official capacity? I took it because it was unmaintained and I > needed some specific changes but I'm hardly qualified and I only > use it on Linux. Simon, FYI Richard is talking about this maintainer role: http://www.cmake.org/Wiki/CMake:Module_Maintainers Thanks, -Brad From chuck.atkins at kitware.com Wed Sep 9 11:50:00 2015 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 9 Sep 2015 11:50:00 -0400 Subject: [cmake-developers] find_program HINTS no longer preferred over PATH (was: HINTS not correctly handled in find_program) In-Reply-To: <55F049E7.7080903@kitware.com> References: <55E6F28E.1080706@kitware.com> <7F62CA7F-33C7-4D39-BA2C-D3D5669973B1@sap.com> <55E71955.1070603@kitware.com> <2A8C1310-D3AA-404A-88A3-5298D04A35AC@sap.com> <55F049E7.7080903@kitware.com> Message-ID: >From what I can tell, the search order is still preserved as expected. [chuck.atkins at hal9000 testdir]$ cat TestFindProgram.cmake set(CMAKE_PREFIX_PATH "/FOODIR_CMAKE_PREFIX_PATH1;/FOODIR_CMAKE_PREFIX_PATH2" CACHE STRING "" FORCE) set(CMAKE_PROGRAM_PATH "/FOODIR_CMAKE_PROGRAM_PATH1;/FOODIR_CMAKE_PROGRAM_PATH2" CACHE STRING "" FORCE) set(CMAKE_APPBUNDLE_PATH "/FOODIR_CMAKE_APPBUNDLE_PATH1;/FOODIR_CMAKE_APPBUNDLE_PATH2" CACHE STRING "" FORCE) set(ENV{CMAKE_PREFIX_PATH} "/FOODIR_ENV_CMAKE_PREFIX_PATH1:/FOODIR_ENV_CMAKE_PREFIX_PATH2" ) set(ENV{CMAKE_PROGRAM_PATH} "/FOODIR_ENV_CMAKE_PROGRAM_PATH1:/FOODIR_ENV_CMAKE_PROGRAM_PATH2" ) set(ENV{CMAKE_APPBUNDLE_PATH} "/FOODIR_ENV_CMAKE_APPBUNDLE_PATH1:/FOODIR_ENV_CMAKE_APPBUNDLE_PATH2" ) set(ENV{PATH} "/FOODIR_ENV_PATH1:/FOODIR_ENV_PATH2") set(CMAKE_SYSTEM_PREFIX_PATH "/FOODIR_CMAKE_SYSTEM_PREFIX_PATH1;/FOODIR_CMAKE_SYSTEM_PREFIX_PATH2" CACHE STRING "" FORCE) set(CMAKE_SYSTEM_PROGRAM_PATH "/FOODIR_CMAKE_SYSTEM_PROGRAM_PATH1;/FOODIR_CMAKE_SYSTEM_PROGRAM_PATH2" CACHE STRING "" FORCE) set(CMAKE_SYSTEM_APPBUNDLE_PATH "/FOODIR_CMAKE_SYSTEM_APPBUNDLE_PATH1;/FOODIR_CMAKE_SYSTEM_APPBUNDLE_PATH2" CACHE STRING "" FORCE) find_program(FOO foo.bin HINTS /FOODIR_FP_HINTS1 /FOODIR_FP_HINTS2 PATHS /FOODIR_FP_PATHS1 /FOODIR_FP_PATHS2) [chuck.atkins at hal9000 testdir]$ By setting each possible location to FOODIR_LOCATIONNAME1 and FOODIR_LOCATIONMAME2, strace make sit easy to see whats searched for in what order: [chuck.atkins at hal9000 testdir]$ strace cmake -P TestFindProgram.cmake 2>&1 | sed -n 's|^[^"]*"\([^"]*foo.bin\)".*|\1|p' foo.bin /FOODIR_CMAKE_PREFIX_PATH1/bin/foo.bin /FOODIR_CMAKE_PREFIX_PATH1/sbin/foo.bin /FOODIR_CMAKE_PREFIX_PATH1/foo.bin /FOODIR_CMAKE_PREFIX_PATH2/bin/foo.bin /FOODIR_CMAKE_PREFIX_PATH2/sbin/foo.bin /FOODIR_CMAKE_PREFIX_PATH2/foo.bin /FOODIR_CMAKE_PROGRAM_PATH1/foo.bin /FOODIR_CMAKE_PROGRAM_PATH2/foo.bin /FOODIR_CMAKE_APPBUNDLE_PATH1/foo.bin /FOODIR_CMAKE_APPBUNDLE_PATH2/foo.bin /FOODIR_ENV_CMAKE_PREFIX_PATH1/bin/foo.bin /FOODIR_ENV_CMAKE_PREFIX_PATH1/sbin/foo.bin /FOODIR_ENV_CMAKE_PREFIX_PATH1/foo.bin /FOODIR_ENV_CMAKE_PREFIX_PATH2/bin/foo.bin /FOODIR_ENV_CMAKE_PREFIX_PATH2/sbin/foo.bin /FOODIR_ENV_CMAKE_PREFIX_PATH2/foo.bin /FOODIR_ENV_CMAKE_PROGRAM_PATH1/foo.bin /FOODIR_ENV_CMAKE_PROGRAM_PATH2/foo.bin /FOODIR_ENV_CMAKE_APPBUNDLE_PATH1/foo.bin /FOODIR_ENV_CMAKE_APPBUNDLE_PATH2/foo.bin /FOODIR_FP_HINTS1/foo.bin /FOODIR_FP_HINTS2/foo.bin /FOODIR_ENV_PATH1/foo.bin /FOODIR_ENV_PATH2/foo.bin /FOODIR_CMAKE_SYSTEM_PREFIX_PATH1/bin/foo.bin /FOODIR_CMAKE_SYSTEM_PREFIX_PATH1/sbin/foo.bin /FOODIR_CMAKE_SYSTEM_PREFIX_PATH1/foo.bin /FOODIR_CMAKE_SYSTEM_PREFIX_PATH2/bin/foo.bin /FOODIR_CMAKE_SYSTEM_PREFIX_PATH2/sbin/foo.bin /FOODIR_CMAKE_SYSTEM_PREFIX_PATH2/foo.bin /FOODIR_CMAKE_SYSTEM_PROGRAM_PATH1/foo.bin /FOODIR_CMAKE_SYSTEM_PROGRAM_PATH2/foo.bin /FOODIR_CMAKE_SYSTEM_APPBUNDLE_PATH1/foo.bin /FOODIR_CMAKE_SYSTEM_APPBUNDLE_PATH2/foo.bin /FOODIR_FP_PATHS1/foo.bin /FOODIR_FP_PATHS2/foo.bin [chuck.atkins at hal9000 testdir]$ >From this, it looks like the find_program(... HINTS ...) are still searched before ENV{PATH}: /FOODIR_FP_HINTS1/foo.bin /FOODIR_FP_HINTS2/foo.bin /FOODIR_ENV_PATH1/foo.bin /FOODIR_ENV_PATH2/foo.bin - Chuck On Wed, Sep 9, 2015 at 11:01 AM, Brad King wrote: > On 09/03/2015 03:51 AM, CHEVRIER, Marc wrote: > > 1. Build phase. Under find_program.BUG/build, use CMakeLists.txt to > prepare runtime part > > 2. Test phase. Under find_program.BUG/runtime, use CMakeLists.txt to > show the bug. > > Thanks, Marc. > > Chuck, this was regressed by your changes in CMake 3.2: > > Merge topic 'refactor-search-path-construction' > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dd89506c > > Please revise the logic to preserve the documented behavior: > > http://www.cmake.org/cmake/help/v3.3/command/find_program.html > > HINTS should be preferred before ENV{PATH}. Please also add > appropriate test cases (e.g. Tests/RunCMake/find_program) and > also check the behavior for other find_* commands. > > Thanks, > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Goulet at autodesk.com Wed Sep 9 12:21:47 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Wed, 9 Sep 2015 16:21:47 +0000 Subject: [cmake-developers] Generator expressions for install destination Message-ID: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> Hi, Here's the patch to add generator expressions to the install command DESTINATION option. Let me know if that's good to go. >@@ -216,6 +216,7 @@ void cmScriptGenerator::GenerateScriptActionsPerConfig(std::ostream& os, > i != this->ConfigurationTypes->end(); ++i) > { > const char* config = i->c_str(); >+ this->ConfigurationName = config; > if(this->GeneratesForConfig(config)) > { > // Generate a per-configuration block. > >This should not be needed if things are factored correctly. >Everything in that block already passes "config" through as a parameter. None of the places where I use GetDestination, except in cmInstallTargetGenerator, receives a config in parameter. An ideally, the ConfigurationName member should not even exist, but that will force all places to pass the config as a parameter. Imho it's better to keep refactoring in a separate patch. -Robert Goulet -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: install-dest-genex.patch Type: application/octet-stream Size: 23885 bytes Desc: install-dest-genex.patch URL: From konstantin at podsvirov.pro Wed Sep 9 14:12:50 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 09 Sep 2015 21:12:50 +0300 Subject: [cmake-developers] [ANNOUNCE] DaD's House! (Beta) Message-ID: <1448651441822370@web21h.yandex.ru> Hi, Dear Developers! Want to advertise a development environment that I am developing. The emergence of this environment would be impossible without two fundamental technologies incorporated in it. Firstly is CMake, which you can use to build very much! Secondly - this is a new set of tools for creating cross-platform installers for desktop QtIFW. Not without my contribution to their ligament - CPack IFW generator. I am developing this project for about one year and I want to share my results, and in return get valuable feedback from users. I started with Windows, which sometimes are lacking in a good open solutions. But the technology can be extended to other desktops. Project status I appreciate Betta, but quite stable and very functional. Official website of the project: http://dad.podsvirov.pro If the project is gaining popularity, then I'll accept links to new mirrors for removing the load from my server. rsync//download.podsvirov.pro Main module - main :-) I write it in a list for developers that would first obtain a qualified appraisal. Looking forward to your answers, questions and suggestions. Happy programming! -- Regards, Konstantin Podsvirov From brad.king at kitware.com Wed Sep 9 14:20:01 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Sep 2015 14:20:01 -0400 Subject: [cmake-developers] find_program HINTS no longer preferred over PATH In-Reply-To: References: <55E6F28E.1080706@kitware.com> <7F62CA7F-33C7-4D39-BA2C-D3D5669973B1@sap.com> <55E71955.1070603@kitware.com> <2A8C1310-D3AA-404A-88A3-5298D04A35AC@sap.com> <55F049E7.7080903@kitware.com> Message-ID: <55F07851.7070006@kitware.com> On 09/09/2015 11:50 AM, Chuck Atkins wrote: > From what I can tell, the search order is still preserved as expected. The example Marc attached earlier shows that the problem is when ENV{PATH} contains one of the *same* values that is one of the HINTS. The fact that a path appears in ENV{PATH} somehow causes it to be dropped from the list of HINTS or otherwise ordered after the other hints. -Brad From mantis at public.kitware.com Wed Sep 9 15:27:21 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 9 Sep 2015 15:27:21 -0400 Subject: [cmake-developers] [CMake 0015732]: Consider showing platform-specific signal value in exception cases Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15732 ====================================================================== Reported By: Zach Mullen Assigned To: ====================================================================== Project: CMake Issue ID: 15732 Category: CTest Reproducibility: N/A Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-09 15:27 EDT Last Modified: 2015-09-09 15:27 EDT ====================================================================== Summary: Consider showing platform-specific signal value in exception cases Description: We occasionally see tests terminate via signals, and CTest simply reports e.g. 4/123 Test http://www.cmake.org/Bug/view.php?id=30: server_api_describe ..........................................................***Exception: Other It would help with debugging if instead of simply "Exception: Other", it also included the platform-specific signal value, e.g. "Exception: Other (9)" or "Exception: Other (SIGKILL)". ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-09 15:27 Zach Mullen New Issue ====================================================================== From domen.vrankar at gmail.com Wed Sep 9 16:31:16 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Wed, 9 Sep 2015 22:31:16 +0200 Subject: [cmake-developers] [PATCH] CPack: don't mangle CMake-special characters when applying default settings In-Reply-To: <1441310409-1172-1-git-send-email-dpb@corrigendum.ru> References: <1441310409-1172-1-git-send-email-dpb@corrigendum.ru> Message-ID: 2015-09-03 22:00 GMT+02:00 ????? ???????? : > By using a function to do it instead of a macro. Deprecate the old macro, > but keep it for backwards compatibility. Remove existing workarounds for this > problem and add a test. Applied with minor changes to next for testing: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=2a7772f Thanks, Domen From Gilles.Khouzam at microsoft.com Wed Sep 9 17:48:54 2015 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Wed, 9 Sep 2015 21:48:54 +0000 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: <55F0496A.1040205@kitware.com> References: <55E4B396.9090609@kitware.com> <55E714E1.10505@kitware.com> <55F0496A.1040205@kitware.com> Message-ID: Thanks Brad. As I've been writing this code, I was looking for the build number and came across the code in cmGlobalGenerator that sets the CMAKE_HOST_SYSTEM_VERSION. Even though GetVersionEx is deprecated, it is the right way to get the system version, loading ntdll and getting RtlGetVersion is not a good practice as those are private APIs that could change. On newer systems (Windows 8 and above) by default the version returned doesn't go beyond Windows 8 Build 9200, but you can apply a manifest to the executable that will let the API give you the correct information and this is a more correct way of handling this. I don't know if there's another reason for the code to be as it is, but I think it would be a better practice to opt into the proper GetVersionEx behavior by adding a manifest than by calling GetProcAddress on an internal API. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Wednesday, September 9, 2015 08:00 To: Gilles Khouzam Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/03/2015 03:19 PM, Gilles Khouzam wrote: > Perhaps the default selection (at least for Store apps since that's > the one that requires the flag) should be the newest SDK less than the > version of the host System. Yes, I think that makes sense. Thanks, -Brad From Geoffrey.Viola at asirobots.com Wed Sep 9 23:54:28 2015 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Thu, 10 Sep 2015 03:54:28 +0000 Subject: [cmake-developers] Improvements for GHS MULTI Generator In-Reply-To: <55F04990.6080301@kitware.com> References: <55F04990.6080301@kitware.com> Message-ID: > Please check that this breakdown is correct Nice job. It is correct. > For future changes please try to send them as patch series broken down like this. (The only reason I did so much squashing of the original GHS support was because it was brand new.) That's good to know Geoffrey Viola SOFTWARE ENGINEER asirobots.com -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Wednesday, September 09, 2015 9:01 AM To: Geoffrey Viola Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] Improvements for GHS MULTI Generator On 09/06/2015 01:43 AM, Geoffrey Viola wrote: > Attached is a patch for some minor improvements for the GHS MULTI generator. Thanks. The commit message mentions a few different changes. I tried to split the changes into individual commits: GHS: Find latest 'int' directory http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=63591b94 GHS: Tell MULTI to delete .elf.ael file http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fbe0de92 GHS: Fix generated file path slashes and quoting for 6.1.6 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=04de9007 Please check that this breakdown is correct. For future changes please try to send them as patch series broken down like this. (The only reason I did so much squashing of the original GHS support was because it was brand new.) Thanks, -Brad This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. From pem.list at gmail.com Thu Sep 10 01:09:45 2015 From: pem.list at gmail.com (Peter List) Date: Thu, 10 Sep 2015 01:09:45 -0400 Subject: [cmake-developers] cmake xcode ios Build Phases > New Copy Files Phase? Message-ID: I use cmake to generate an iOS xcode project for "ios-cmake-master". Then I have to can manually add my "shaders" folder to xcode > cmd+4 > Build Phases > + New Copy Files Phase > Destination = Resources, + to add my "shaders" folder. This allows me to have XCode copy my GLSL "shaders" folder (or other files) into the iOS simulator when I run my project. So my question is... How do I tell CMake to generate my .xcodeproj file with this Build Phase? I shouldn't need to manually edit my .xcodeproj file... thank you for any leads -------------- next part -------------- An HTML attachment was scrubbed... URL: From pem.list at gmail.com Thu Sep 10 01:20:23 2015 From: pem.list at gmail.com (Peter List) Date: Thu, 10 Sep 2015 01:20:23 -0400 Subject: [cmake-developers] cmake xcode ios Build Phases > New Copy Files Phase? In-Reply-To: References: Message-ID: Actually I guess I found the answer here... https://stackoverflow.com/questions/30430968/add-xcode-build-phase-via-cmake On Thu, Sep 10, 2015 at 1:09 AM, Peter List wrote: > I use cmake to generate an iOS xcode project for "ios-cmake-master". Then > I have to can manually add my "shaders" folder to xcode > cmd+4 > Build > Phases > + New Copy Files Phase > Destination = Resources, + to add my > "shaders" folder. This allows me to have XCode copy my GLSL "shaders" > folder (or other files) into the iOS simulator when I run my project. > > So my question is... How do I tell CMake to generate my .xcodeproj file > with this Build Phase? I shouldn't need to manually edit my .xcodeproj > file... > > thank you for any leads > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pem.list at gmail.com Thu Sep 10 01:45:28 2015 From: pem.list at gmail.com (Peter List) Date: Thu, 10 Sep 2015 01:45:28 -0400 Subject: [cmake-developers] cmake xcode ios Build Phases > New Copy Files Phase? In-Reply-To: References: Message-ID: In case it helps someone else, here's what I have: # after link, add exe file(GLOB SRC_LIST shaders/* main.cpp) if(${IsIOS}) set_source_files_properties(shaders PROPERTIES MACOSX_PACKAGE_LOCATION Resources) add_executable(${PROJECT_NAME} MACOSX_BUNDLE ${SRC_LIST} shaders) else() add_executable(${PROJECT_NAME} ${SRC_LIST}) endif() It's a bit weird because I have both "shaders/*" and "shaders". However, "shaders/*" is required for Qt Creator to see my GLSL shader files, while "shaders" is required for XCode iOS's Copy Bundle Resource. Oh I guess "Copy Bundle Resource" is not the same as "Copy Files"... But I got something that works, and I'll have to look into the difference between those as a separate issue... On Thu, Sep 10, 2015 at 1:20 AM, Peter List wrote: > Actually I guess I found the answer here... > > > https://stackoverflow.com/questions/30430968/add-xcode-build-phase-via-cmake > > > On Thu, Sep 10, 2015 at 1:09 AM, Peter List wrote: > >> I use cmake to generate an iOS xcode project for "ios-cmake-master". >> Then I have to can manually add my "shaders" folder to xcode > cmd+4 > >> Build Phases > + New Copy Files Phase > Destination = Resources, + to add >> my "shaders" folder. This allows me to have XCode copy my GLSL "shaders" >> folder (or other files) into the iOS simulator when I run my project. >> >> So my question is... How do I tell CMake to generate my .xcodeproj file >> with this Build Phase? I shouldn't need to manually edit my .xcodeproj >> file... >> >> thank you for any leads >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Thu Sep 10 04:12:40 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 10 Sep 2015 04:12:40 -0400 Subject: [cmake-developers] [CMake 0015733]: Linker EntryPoint inconsistency Message-ID: <39e9037f66b5f39663f7397d03c274e4@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15733 ====================================================================== Reported By: M. Schneider Assigned To: ====================================================================== Project: CMake Issue ID: 15733 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-10 04:12 EDT Last Modified: 2015-09-10 04:12 EDT ====================================================================== Summary: Linker EntryPoint inconsistency Description: Inconsistency occurs for Windows CE when creating a project for building an executable using Unicode. This causes build errors for builds using VS generator. Because of portability reason to standard c code, console executables on CE use mainACRTStartup as entry point. For Ninja Generator this linker flag is set properly (defined in Windows-MSVC.cmake line 39ff, applied in cmMakefileExecutableTargetGenerator.cxx 199ff) depending on system name - using CMAKE_CREATE_CONSOLE_EXE variable. If VS2012 project is set as generator entry point is set to mainWCRTStartup (cmVisualStudio10TargetGenerator.cxx line 2396ff). >From my point of view all generators should create same flags although VS build can be fixed using SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES LINK_FLAGS "/ENTRY:mainACRTStartup") for WinCE in corresponding CMakeLists.txt. An idea is instead of using a separate logic for determining entry point, stick to your CMAKE_CREATE_CONSOLE_EXE/CMAKE_CREATE_WIN32_EXE variables. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-10 04:12 M. Schneider New Issue ====================================================================== From roman.wueger at gmx.at Thu Sep 10 05:40:17 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Thu, 10 Sep 2015 11:40:17 +0200 Subject: [cmake-developers] CTest threshold exceeds 1024 bytes In-Reply-To: <55E4A8A5.2020909@kitware.com> References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> <55AE4EC3.8050607@kitware.com> <015401d0c402$ea609040$bf21b0c0$@gmx.at> <55AFB35D.4000004@kitware.com> <55B653C4.7090205@kitware.com> <724C2DD1-4024-47E3-91C2-DC086107735C@gmx.at> <55D5F2AB.1000600@kitware.com> <55E4A8A5.2020909@kitware.com> Message-ID: Hi Brad, I fail on implementing the test cases, I'm not familiar with testing this way in general. How can we finish this change? Best regards Roman > Am 31.08.2015 um 21:19 schrieb Brad King : > >> On 08/31/2015 07:36 AM, "Roman W?ger" wrote: >> Attached you will find the corrected patch. > > Thanks. I've attached a revised version. I renamed the options > and added release notes. I also started the test case. Please > try completing the test and getting it to pass from there. > > BTW, I noticed that there is actually a way to set these values > already. It just is not documented. Try this: > > $ git grep CTEST_CUSTOM_MAXIMUM_.*_TEST_OUTPUT_SIZE > > to see the options. They can be set in ctest scripts but not > on the command line. > > -Brad > > <0001-CTest-learned-to-limit-the-output-of-passed-and-fail.patch> From mantis at public.kitware.com Thu Sep 10 06:50:17 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 10 Sep 2015 06:50:17 -0400 Subject: [cmake-developers] [CMake 0015735]: Non-ascii characters in POST_BUILD commands truncated by CMake (if Ninja generator used) on Linux Message-ID: <54ea0d12b80d05b7ac4fced460c1c93a@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15735 ====================================================================== Reported By: Pavel Solodovnikov Assigned To: ====================================================================== Project: CMake Issue ID: 15735 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2015-09-10 06:50 EDT Last Modified: 2015-09-10 06:50 EDT ====================================================================== Summary: Non-ascii characters in POST_BUILD commands truncated by CMake (if Ninja generator used) on Linux Description: CMake doesn't handle backslash escaped strings properly in POST_BUILD commands added via "add_custom_command" if provided commands end with non-ascii characters. Here is a simple example that represents the issue: I have a trivial CMakeLists.txt with one library target: cmake_minimum_required(VERSION 2.8.11) project(example) add_library(ex abc.cpp) add_custom_command(TARGET ex POST_BUILD COMMAND cmd1 "?????? ? ?????????") For example, I want to execute post build command "cmd1" and pass a parameter "?????? ? ?????????" that contains russian characters. If Ninja generator is specified, CMake generates ill-formed "build.ninja" file. The point of interest in produced build.ninja file looks like that: build libex.a: CXX_STATIC_LIBRARY_LINKER CMakeFiles/ex.dir/abc.cpp.o POST_BUILD = cd /mnt/sources/work/example && cmd1 ??????\ ?\ PRE_LINK = : TARGET_PDB = ex.a.dbg The last word in passed parameter "?????? ? ?????????" had been truncated by CMake up to the first encountered space so I can't execute my post build commands properly, since the argument string is corrupted now. After debugging CMake a little, I've discovered that the source of this error is in function "cmSystemTools::TrimWhitespace" (cmSystemTools.cxx), which doesn't take into account the fact that std::string individual characters are of 'char' type which is (in most circumstances) signed by default. Hence there are errors in conditions: while(start != s.end() && *start <= ' ') ++start; and while(*stop <= ' ') --stop; If *stop doesn't fit into 0-127 range(ascii table) as in my example with russian letters, *stop appears to be less than 0, so condition to trim characters is true and it silently chops the last word out of my string until it encounters a space char. In our projects we use such post-build commands very widely (for example to copy produced binaries to a specific directory which have a cyrillic name) so this issue is somewhat crucial for us. I've attached a patch (patch.diff inside uploaded archive) that resolves this issue. It simply adds conversion of *start and *stop explicitly to unsigned char. Steps to Reproduce: 1) Extract attached example.tar 2) Run "cmake -G "Ninja" ." inside extracted dir. 3) Examine produced build.ninja file. Additional Information: Affected platform is Linux, Windows uses double quote escaping and the issue does not arise. This bug persists in CMake releases from 2.8.11 up to the latest 3.3.1 (at least this is what I've observed while looking into sources). ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-10 06:50 Pavel SolodovnikovNew Issue 2015-09-10 06:50 Pavel SolodovnikovFile Added: example.zip ====================================================================== From konstantin at podsvirov.pro Thu Sep 10 09:02:23 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 10 Sep 2015 16:02:23 +0300 Subject: [cmake-developers] [ANNOUNCE] DaD's House! (Beta) In-Reply-To: <1448651441822370@web21h.yandex.ru> References: <1448651441822370@web21h.yandex.ru> Message-ID: <1137391441890143@web29h.yandex.ru> The first 100 views! The interest is there (though not great), but where are the questions and suggestions? 09.09.2015, 21:12, "Konstantin Podsvirov" : > Hi, Dear Developers! > > Want to advertise a development environment that I am developing. > The emergence of this environment would be impossible without two fundamental technologies incorporated in it. > > Firstly is CMake, which you can use to build very much! > Secondly - this is a new set of tools for creating cross-platform installers for desktop QtIFW. > > Not without my contribution to their ligament - CPack IFW generator. > > I am developing this project for about one year and I want to share my results, and in return get valuable feedback from users. > > I started with Windows, which sometimes are lacking in a good open solutions. But the technology can be extended to other desktops. > > Project status I appreciate Betta, but quite stable and very functional. > > Official website of the project: > > http://dad.podsvirov.pro > > If the project is gaining popularity, then I'll accept links to new mirrors for removing the load from my server. > > rsync//download.podsvirov.pro > > Main module - main :-) > > I write it in a list for developers that would first obtain a qualified appraisal. > > Looking forward to your answers, questions and suggestions. > > Happy programming! > > -- > Regards, > Konstantin Podsvirov Regards, Konstantin Podsvirov -------------- next part -------------- A non-text attachment was scrubbed... Name: CMakeAndQtDevelopmentLists_2015.09.09-10.png Type: image/png Size: 94069 bytes Desc: not available URL: From konstantin at podsvirov.pro Thu Sep 10 09:19:05 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 10 Sep 2015 16:19:05 +0300 Subject: [cmake-developers] Fwd: [Development] [ANNOUNCE] DaD's House! (Beta) In-Reply-To: <2256851441891098@web5m.yandex.ru> Message-ID: <2260791441891145@web5m.yandex.ru> 10.09.2015, 16:06, "Curtis Mitch" : > ?What is it, really? > > ?Personally I read the email and had no idea, and it didn't make me want to follow the link to find out. By clicking on the link, you will be able to get the installer is the same as the QtSDK and a few clicks to get the binaries, libraries linking and headers of any of the participating modules. This is a quick start for the development of the project on the basis of submitted modules: * Curses * ZLib * LibPNG * Jpeg * Libxml2 * LibTIFF * Perl * OpenSSL * LibSSH2 * cURL * PCRE * PROJ * Expat * FreeType * SQLite * GEOS * GDAL * Boost * Qt * QtIFW * CMake * KDSoap * OSG * osgEarth * osgQtQuick * PostgreSQL * The Apache.Apr * The Apache.AprUtil * The Apache.Httpd * Protobuf * gRPC * MapServer Now this is only for Windows (MSVC2013) but can be extended. There is a notion of stability, as in Debian: stable, testing, unstable. Stable modules were assembled about a year ago. Testing is very fresh. Unstable installers can now not be considered. > ?> ----- Original Message----- >> ?From: development-bounces+mitch.curtis=theqtcompany.com at qt-project.org >> ?[mailto:development-bounces+mitch.curtis=theqtcompany.com at qt-project.org] >> ?On Behalf Of Konstantin Podsvirov >> ?Sent: Thursday, 10 September 2015 3:02 PM >> ?To: CMake Developers ; development at qt >> ?project.org >> ?Subject: Re: [Development] [ANNOUNCE] Dad's House! (Beta) >> >> ?The first 100 views! >> ?The interest is there (though not great), but where are the questions and >> ?suggestions? >> >> ?09.09.2015, 21:12, "Konstantin Podsvirov" : >> ?> Hi, Dear Developers! >> ?> >> ?> Want to advertise a development environment that I am developing. >> ?> ... >> ?> Happy programming! Regards, Konstantin Podsvirov From brad.king at kitware.com Thu Sep 10 09:39:29 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Sep 2015 09:39:29 -0400 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: References: <55E4B396.9090609@kitware.com> <55E714E1.10505@kitware.com> <55F0496A.1040205@kitware.com> Message-ID: <55F18811.8000400@kitware.com> On 09/09/2015 05:48 PM, Gilles Khouzam wrote: > Even though GetVersionEx is deprecated, > it is the right way to get the system version, loading ntdll and > getting RtlGetVersion is not a good practice as those are private > APIs that could change. The change was contributed recently: Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8.1 (#15674) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d4736d53 for this issue: http://www.cmake.org/Bug/view.php?id=15674 I've re-opened the issue. I would really like to know why MS deprecated GetVersionEx. The Version Helper APIs are only good for checking >= level, not getting the actual version. Why not add the helpers and leave GetVersionEx available too? Why do we need to add a manifest just to get the OS version? What is a library author supposed to do when s/he cannot control the application that will link the library? FYI, the GetVersionEx documentation page: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85%29.aspx has a community-mentioned recommendation to use RtlGetVersion. Thanks, -Brad From brad.king at kitware.com Thu Sep 10 09:40:09 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Sep 2015 09:40:09 -0400 Subject: [cmake-developers] CTest threshold exceeds 1024 bytes In-Reply-To: References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> <55AE4EC3.8050607@kitware.com> <015401d0c402$ea609040$bf21b0c0$@gmx.at> <55AFB35D.4000004@kitware.com> <55B653C4.7090205@kitware.com> <724C2DD1-4024-47E3-91C2-DC086107735C@gmx.at> <55D5F2AB.1000600@kitware.com> <55E4A8A5.2020909@kitware.com> Message-ID: <55F18839.6020709@kitware.com> On 09/10/2015 05:40 AM, Roman W?ger wrote: > I fail on implementing the test cases, I'm not familiar with > testing this way in general. How can we finish this change? We need to have proper testing or the feature will break in the future. You may not even need the new options. Have you tried setting CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE in your ctest script? -Brad From konstantin at podsvirov.pro Thu Sep 10 10:12:59 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 10 Sep 2015 17:12:59 +0300 Subject: [cmake-developers] [Development] [ANNOUNCE] DaD's House! (Beta) In-Reply-To: References: <1448651441822370@web21h.yandex.ru> <1137391441890143@web29h.yandex.ru> <2256851441891098@web5m.yandex.ru> Message-ID: <2819371441894379@web23g.yandex.ru> 10.09.2015, 16:41, "Curtis Mitch" : >> From: Konstantin Podsvirov [mailto:konstantin at podsvirov.pro] >> >> By clicking on the link, you will be able to get the installer is the same >> as the QtSDK and a few clicks to get the binaries, libraries and linking >> headers of any of the participating modules. > > But what am I even clicking the link for? What service does this thing provide? For example, You want to create a very large and useful application which uses a lot of dependencies. And you want to deploy it on the Windows. You go to the site: http://dad.podsvirov.pro Download appropriate to your development environment setup. Quickly and easily install any required dependent modules and receives a development environment, local deployment and testing. When you're finished designing, you can create compatible with this environment the installer to install your application on other machines. Main technologies: * Development languages: C, C++ (Qt, Qml, Quick) and other * Project management: CMake, but can use other * Creating installer based QtIFW (CMake allows you to automate the process of creating an installer). I answered Your question? Regards, Konstantin Podsvirov From roman.wueger at gmx.at Thu Sep 10 10:57:18 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Thu, 10 Sep 2015 16:57:18 +0200 Subject: [cmake-developers] CTest threshold exceeds 1024 bytes In-Reply-To: <55F18839.6020709@kitware.com> References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> <55AE4EC3.8050607@kitware.com> <015401d0c402$ea609040$bf21b0c0$@gmx.at> <55AFB35D.4000004@kitware.com> <55B653C4.7090205@kitware.com> <724C2DD1-4024-47E3-91C2-DC086107735C@gmx.at> <55D5F2AB.1000600@kitware.com> <55E4A8A5.2020909@kitware.com> <55F18839.6020709@kitware.com> Message-ID: <6DB7FFE9-93EF-4C3E-AAE4-16DE069BA98E@gmx.at> I don't know where to set the variables nor where to set the command line parameters. How can I then test that the maximum passed size is 40 bytes and the failed size is 60 for example? Where can I produce such test data (test.xml) with the expected size? Thanks Best Regards Roman > Am 10.09.2015 um 15:40 schrieb Brad King : > >> On 09/10/2015 05:40 AM, Roman W?ger wrote: >> I fail on implementing the test cases, I'm not familiar with >> testing this way in general. How can we finish this change? > > We need to have proper testing or the feature will break in the > future. You may not even need the new options. Have you tried > setting > > CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE > CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE > > in your ctest script? > > -Brad From jchris.fillionr at kitware.com Thu Sep 10 10:59:23 2015 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 10 Sep 2015 10:59:23 -0400 Subject: [cmake-developers] [Development] [ANNOUNCE] DaD's House! (Beta) In-Reply-To: <2819371441894379@web23g.yandex.ru> References: <1448651441822370@web21h.yandex.ru> <1137391441890143@web29h.yandex.ru> <2256851441891098@web5m.yandex.ru> <2819371441894379@web23g.yandex.ru> Message-ID: Hi Konstantin, Thanks for sharing your work with the community. Given the exhaustive list of modules provided within the installers, I can appreciate the effort. That said, as you may know, downloading unsigned binaries to build applications is not an option for a lot of us. Here are few initial suggestions to improve your platform: * transition the website to https * reference the version of each packages/modules bundled in the respective installers * provide the a how to understand the different between stable/testing/unstable * document the convention to integrate the different module in our existing project. For example, for CMake did you write a Config.cmake file with each project [1] ? And similar question for qmake ? Good luck, Jc [1] http://www.cmake.org/cmake/help/git-next/manual/cmake-packages.7.html On Thu, Sep 10, 2015 at 10:12 AM, Konstantin Podsvirov wrote: > 10.09.2015, 16:41, "Curtis Mitch" : >>> From: Konstantin Podsvirov [mailto:konstantin at podsvirov.pro] >>> >>> By clicking on the link, you will be able to get the installer is the same >>> as the QtSDK and a few clicks to get the binaries, libraries and linking >>> headers of any of the participating modules. >> >> But what am I even clicking the link for? What service does this thing provide? > > For example, You want to create a very large and useful application which uses a lot of dependencies. > And you want to deploy it on the Windows. > > You go to the site: > > http://dad.podsvirov.pro > > Download appropriate to your development environment setup. > > Quickly and easily install any required dependent modules and receives a development environment, local deployment and testing. > > When you're finished designing, you can create compatible with this environment the installer to install your application on other machines. > > Main technologies: > * Development languages: C, C++ (Qt, Qml, Quick) and other > * Project management: CMake, but can use other > * Creating installer based QtIFW (CMake allows you to automate the process of creating an installer). > > I answered Your question? > > Regards, > Konstantin Podsvirov > -- > > 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 -- +1 919 869 8849 From brad.king at kitware.com Thu Sep 10 11:02:12 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Sep 2015 11:02:12 -0400 Subject: [cmake-developers] CTest threshold exceeds 1024 bytes In-Reply-To: <6DB7FFE9-93EF-4C3E-AAE4-16DE069BA98E@gmx.at> References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> <55AE4EC3.8050607@kitware.com> <015401d0c402$ea609040$bf21b0c0$@gmx.at> <55AFB35D.4000004@kitware.com> <55B653C4.7090205@kitware.com> <724C2DD1-4024-47E3-91C2-DC086107735C@gmx.at> <55D5F2AB.1000600@kitware.com> <55E4A8A5.2020909@kitware.com> <55F18839.6020709@kitware.com> <6DB7FFE9-93EF-4C3E-AAE4-16DE069BA98E@gmx.at> Message-ID: <55F19B74.6010401@kitware.com> On 09/10/2015 10:57 AM, Roman W?ger wrote: > I don't know where to set the variables nor where to set the command line parameters. > How can I then test that the maximum passed size is 40 bytes and the failed size is 60 for example? > Where can I produce such test data (test.xml) with the expected size? Don't you have a real use case for the feature you've added? Does it produce a Test.xml file? Use that as your case for manual testing. -Brad From brad.king at kitware.com Thu Sep 10 11:06:38 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Sep 2015 11:06:38 -0400 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> Message-ID: <55F19C7E.50704@kitware.com> On 09/09/2015 12:21 PM, Robert Goulet wrote: > Here?s the patch to add generator expressions to the install > command DESTINATION option. Thanks for the update. >>This should not be needed if things are factored correctly. >>Everything in that block already passes "config" through as a parameter. > > None of the places where I use GetDestination, except in > cmInstallTargetGenerator, receives a config in parameter. > An ideally, the ConfigurationName member should not even exist, > but that will force all places to pass the config as a parameter. > Imho it?s better to keep refactoring in a separate patch. I think such a separate refactoring patch should come first. I cannot review the logic with confidence because I don't know what implicitly depends on ConfigurationName being set and whether call paths leading to it set it correctly. Also, take a look at the install(EXPORT) case. I tried using a $ genex in the DESTINATION argument with your patch but it fails trying to create a directory with literal $ in its name (on Windows with a VS generator). Note that the install(EXPORT) command generates some files in the build tree packed away under CMakeFiles/Export and then adds cmake_install.cmake rules to install those. Generation of these files needs to expand the generator expression in time. Thanks, -Brad From roman.wueger at gmx.at Thu Sep 10 11:06:52 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Thu, 10 Sep 2015 17:06:52 +0200 Subject: [cmake-developers] CTest threshold exceeds 1024 bytes In-Reply-To: <55F19B74.6010401@kitware.com> References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> <55AE4EC3.8050607@kitware.com> <015401d0c402$ea609040$bf21b0c0$@gmx.at> <55AFB35D.4000004@kitware.com> <55B653C4.7090205@kitware.com> <724C2DD1-4024-47E3-91C2-DC086107735C@gmx.at> <55D5F2AB.1000600@kitware.com> <55E4A8A5.2020909@kitware.com> <55F18839.6020709@kitware.com> <6DB7FFE9-93EF-4C3E-AAE4-16DE069BA98E@gmx.at> <55F19B74.6010401@kitware.com> Message-ID: <45DDF6B8-89FE-4932-96E4-F71B0770E2A5@gmx.at> I've tested it in the visual studio debugger/ide, not as a test case with ctest. Regards > Am 10.09.2015 um 17:02 schrieb Brad King : > >> On 09/10/2015 10:57 AM, Roman W?ger wrote: >> I don't know where to set the variables nor where to set the command line parameters. >> How can I then test that the maximum passed size is 40 bytes and the failed size is 60 for example? >> Where can I produce such test data (test.xml) with the expected size? > > Don't you have a real use case for the feature you've added? > Does it produce a Test.xml file? Use that as your case for > manual testing. > > -Brad > From roman.wueger at gmx.at Thu Sep 10 11:11:12 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Thu, 10 Sep 2015 17:11:12 +0200 Subject: [cmake-developers] CTest threshold exceeds 1024 bytes In-Reply-To: <45DDF6B8-89FE-4932-96E4-F71B0770E2A5@gmx.at> References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> <55AE4EC3.8050607@kitware.com> <015401d0c402$ea609040$bf21b0c0$@gmx.at> <55AFB35D.4000004@kitware.com> <55B653C4.7090205@kitware.com> <724C2DD1-4024-47E3-91C2-DC086107735C@gmx.at> <55D5F2AB.1000600@kitware.com> <55E4A8A5.2020909@kitware.com> <55F18839.6020709@kitware.com> <6DB7FFE9-93EF-4C3E-AAE4-16DE069BA98E@gmx.at> <55F19B74.6010401@kitware.com> <45DDF6B8-89FE-4932-96E4-F71B0770E2A5@gmx.at> Message-ID: <897B93ED-5B09-4B21-B1D5-05CBC65BB4F6@gmx.at> I know what you mean, sure I have tested it on a developer machine but not as part of a "ctest unit test". I've tested it on a real world example. My problem is to add a "ctest unit test case". > Am 10.09.2015 um 17:06 schrieb Roman W?ger : > > I've tested it in the visual studio debugger/ide, not as a test case with ctest. > > Regards > >>> Am 10.09.2015 um 17:02 schrieb Brad King : >>> >>> On 09/10/2015 10:57 AM, Roman W?ger wrote: >>> I don't know where to set the variables nor where to set the command line parameters. >>> How can I then test that the maximum passed size is 40 bytes and the failed size is 60 for example? >>> Where can I produce such test data (test.xml) with the expected size? >> >> Don't you have a real use case for the feature you've added? >> Does it produce a Test.xml file? Use that as your case for >> manual testing. >> >> -Brad > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers From brad.king at kitware.com Thu Sep 10 11:13:56 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Sep 2015 11:13:56 -0400 Subject: [cmake-developers] CTest threshold exceeds 1024 bytes In-Reply-To: <897B93ED-5B09-4B21-B1D5-05CBC65BB4F6@gmx.at> References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> <55AE4EC3.8050607@kitware.com> <015401d0c402$ea609040$bf21b0c0$@gmx.at> <55AFB35D.4000004@kitware.com> <55B653C4.7090205@kitware.com> <724C2DD1-4024-47E3-91C2-DC086107735C@gmx.at> <55D5F2AB.1000600@kitware.com> <55E4A8A5.2020909@kitware.com> <55F18839.6020709@kitware.com> <6DB7FFE9-93EF-4C3E-AAE4-16DE069BA98E@gmx.at> <55F19B74.6010401@kitware.com> <45DDF6B8-89FE-4932-96E4-F71B0770E2A5@gmx.at> <897B93ED-5B09-4B21-B1D5-05CBC65BB4F6@gmx.at> Message-ID: <55F19E34.5030309@kitware.com> On 09/10/2015 11:11 AM, Roman W?ger wrote: > I've tested it on a real world example. > > My problem is to add a "ctest unit test case". The patch I last sent earlier in this thread adds a unit test that produces and reads the Test.xml file. I left a comment: # TODO: actually check the content as a placeholder for you to take over with the actual check. At that point the "test_xml" variable holds the content to be checked. -Brad From mantis at public.kitware.com Thu Sep 10 13:46:51 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 10 Sep 2015 13:46:51 -0400 Subject: [cmake-developers] [CMake 0015736]: FeatureTesting unreliable Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15736 ====================================================================== Reported By: Felix Geyer Assigned To: ====================================================================== Project: CMake Issue ID: 15736 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-10 13:46 EDT Last Modified: 2015-09-10 13:46 EDT ====================================================================== Summary: FeatureTesting unreliable Description: The CompileFeatures test fails in Debian on the architecture alpha. My guess is that it's a general problem and other architectures just got lucky. The problem seems to be that Modules/Internal/FeatureTesting.cmake doesn't add a terminator (\0 or \n for example) at the start of const char features. As a result a printable character can appear in the binary right before "${lang}_FEATURE:". So when cmake extracts strings from the binary it reads "kC_FEATURE:1c_function_prototypes\n". The extra "k" at the start confuses the module as it expects "C_FEATURE". This code in Modules/Internal/FeatureTesting.cmake might be supposed to add a null character at the start: const char features[] = {\"\"\n") However if I'm not mistaken C just concats string literals that are space separated -> it's a noop. Replacing that empty string literal with "\0" fixes the problem. Original bug report with an analysis of the problem: https://bugs.debian.org/789807 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-10 13:46 Felix Geyer New Issue ====================================================================== From konstantin at podsvirov.pro Thu Sep 10 14:09:04 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 10 Sep 2015 21:09:04 +0300 Subject: [cmake-developers] [Development] [ANNOUNCE] DaD's House! (Beta) In-Reply-To: References: <1448651441822370@web21h.yandex.ru> <1137391441890143@web29h.yandex.ru> <2256851441891098@web5m.yandex.ru> <2819371441894379@web23g.yandex.ru> Message-ID: <2890901441908544@web7o.yandex.ru> Hi, Jean-Christophe Fillion-Robin (the short name?)! Thanks for Your reply. You gave a lot of valuable advice. 10.09.2015, 17:59, "Jean-Christophe Fillion-Robin" : > Hi Konstantin, > > Thanks for sharing your work with the community. I'm glad to be helpful. Thank You for giving the community such a useful tool like CMake. > Given the exhaustive list of modules provided within the installers, I > can appreciate the effort. I agree, thanks for the rating. It really is now a lot of work. But now better order and it was good. Early in the development of their projects I was trying to find ABI compatible binaries for dependent modules. And pretty soon I realized that this is not always possible. Then I began to study dependent projects and try to build them yourself. Then for each project I reinvent the wheel on adding dependencies during development and deployment. Meanwhile I already owned a nice CMake and he helped me a lot. Routine work became more and more. I tried a few different frames to create the installers - they were all completely different and I didn't like. When QtIFW, then I read its documentation and stasis realized that his need to make friends with CMake (or Vice versa). This was the prerequisite for the appearance of Dad's project. It's just tie a big story, which I hope some will live with me together. > That said, as you may know, downloading unsigned binaries to build > applications is not an option for a lot of us. Yes, I understand that. The trust of our users is very important. But as one cartoon character: I'm not a magician - I'm just learning. I know how well to build projects of their own and others :-) To sign application I haven't learned. We are talking about signing themselves installers or applications within modules? > Here are few initial suggestions to improve your platform: > > * transition the website to https It's all about the confidence of users, as mentioned above. I need to get the certificate. Understandable comment. Will try to organize. > * reference the version of each packages/modules bundled in the > respective installers I thought about it. You are not the first who comes to me! The list of available module and versions can be seen by running the particular setup on the feature selection page, but that's not enough. Of course, users want to see it before downloading the installer. The proposal was adopted. I'll think how to do it. > * provide the a how to understand the different between > stable/testing/unstable For a quick start, I refer everyone to the website of the Debian community http://debian.org I will try to add a description on the website. > * document the convention to integrate the different module in our > existing project. For example, for CMake, did you write a > Config.cmake file with each project [1] ? And similar question > for qmake ? I plan to have a section on the website with more detailed information for each module. Now on the page with the list of modules I have provided a link to the native source of information. The need to create a CMake configuration for modules is controversial. Each project is independent and most of them are managed by family CMake scripts. Some provide package configurations to import. Some can be found with Find modules distributed by CMake. Presents the installers are just transferral these projects a local directory of the user. Further, their use is no different, say from download from the original site. > Good luck, > Jc Thanks for valuable advice. I'm doing a project in my spare time. And I will try to improve it and continue to share with the community. Now I'm building modules in an automated way. Not always the case goes smoothly. Some modules require minor tweaks. The real CI is still far. But I hope with time I'll come to that. I apologize for linguistic errors. English is not my native language. > [1] http://www.cmake.org/cmake/help/git-next/manual/cmake-packages.7.html > > On Thu, Sep 10, 2015 at 10:12 AM, Konstantin Podsvirov > wrote: >> 10.09.2015, 16:41, "Curtis Mitch" : >>>> From: Konstantin Podsvirov [mailto:konstantin at podsvirov.pro] >>>> >>>> By clicking on the link, you will be able to get the installer is the same >>>> as the QtSDK and a few clicks to get the binaries, libraries and linking >>>> headers of any of the participating modules. >>> >>> But what am I even clicking the link for? What service does this thing provide? >> >> For example, You want to create a very large and useful application which uses a lot of dependencies. >> And you want to deploy it on the Windows. >> >> You go to the site: >> >> http://dad.podsvirov.pro >> >> Download appropriate to your development environment setup. >> >> Quickly and easily install any required dependent modules and receives a development environment, local deployment and testing. >> >> When you're finished designing, you can create compatible with this environment the installer to install your application on other machines. >> >> Main technologies: >> * Development languages: C, C++ (Qt, Qml, Quick) and other >> * Project management: CMake, but can use other >> * Creating installer based QtIFW (CMake allows you to automate the process of creating an installer). >> >> I answered Your question? >> >> Regards, >> Konstantin Podsvirov Regards, Konstantin Podsvirov From Gilles.Khouzam at microsoft.com Thu Sep 10 14:37:33 2015 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Thu, 10 Sep 2015 18:37:33 +0000 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: <55F18811.8000400@kitware.com> References: <55E4B396.9090609@kitware.com> <55E714E1.10505@kitware.com> <55F0496A.1040205@kitware.com> <55F18811.8000400@kitware.com> Message-ID: Brad, >From my understanding GetVersionEx was causing a nightmare of app compatibility issues where developers would make the wrong comparison or assumption based on the version and applications would break on new releases. I don't know that deprecating the API and making it require a manifest was a better solution, but it does require more intentional work on the developer before just using the API. For the usage that CMake is using it is benign and doesn't look like it would cause compatibility issues. Here's the updated patch for Windows 10 support. 1. Added support for Windows Universal applications as CMAKE_SYSTEM_NAME=WindowsStore and CMAKE_SYSTEM_VERSION=10.0 2. Added support for manifest files, when specifying a manifest as a source file, it will be added to the tag of the section in the vcxproj file (VisualStudio 10 generator only). Multiple manifests could be added. 3. Added a manifest to the CMake executables to enable proper version API support on Windows 8 and above. The file is Source\cmake.version.manifest. 4. Added a detection mechanism to figure out which Windows 10 SDK is installed and can be used on the machine. This follows the detection logic that VS 2015 uses. The SDK selected will be the latest SDK that is less or equal to the build of the HOST. This change requires the manifest. 5. Added Windows 10 Universal tests in VSWinStorePhone 6. Added a 2 new target properties: VS_TARGET_PLATFORM_VERSION and VS_TARGET_PLATFORM_MIN_VERSION, these set the and tags in the vcxproj file. If VS_TARGET_PLATFORM_VERSION is not set for a target and is required, a default is set a CMAKE_VS_TARGET_PLATFORM_VERSION based on the lastest usable Windows 10 SDK. 7. Added a new target property VS_TOOL_OVERRIDE to enable adding new file types to VS without requiring to teach CMake how to handle them. This property, set on a source file will override the default tool assigned in Visual Studio. This enables support for RESW files for example without teaching CMake how to handle them. 8. Added support for Windows 10 extensions with 3 new properties: VS_DESKTOP_EXTENSIONS_VERSION, VS_MOBILE_EXTENSIONS_VERSION and VS_IOT_EXTENSIONS_VERSION. These specify the version of the different extensions and whether they are used. When an extension is used, an SDK reference is added for that extension. 9. Added a new property: VS_IOT_STARTUP_TASK to specify if the target has a startup task for and IOT project. I realize that there are a lot of changes in here, but the combination of them are all required for proper Windows 10 support. I can split it up in multiple patches if that makes it easier. #2 and #3 could be a different patch that Windows 10 support depends on. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Thursday, September 10, 2015 06:39 To: Gilles Khouzam Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/09/2015 05:48 PM, Gilles Khouzam wrote: > Even though GetVersionEx is deprecated, it is the right way to get the > system version, loading ntdll and getting RtlGetVersion is not a good > practice as those are private APIs that could change. The change was contributed recently: Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8.1 (#15674) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d4736d53 for this issue: http://www.cmake.org/Bug/view.php?id=15674 I've re-opened the issue. I would really like to know why MS deprecated GetVersionEx. The Version Helper APIs are only good for checking >= level, not getting the actual version. Why not add the helpers and leave GetVersionEx available too? Why do we need to add a manifest just to get the OS version? What is a library author supposed to do when s/he cannot control the application that will link the library? FYI, the GetVersionEx documentation page: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85%29.aspx has a community-mentioned recommendation to use RtlGetVersion. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: Windows10.patch Type: application/octet-stream Size: 49289 bytes Desc: Windows10.patch URL: From pem.list at gmail.com Thu Sep 10 15:00:27 2015 From: pem.list at gmail.com (Peter List) Date: Thu, 10 Sep 2015 15:00:27 -0400 Subject: [cmake-developers] cmake xcode ios Build Phases > New Copy Files Phase? In-Reply-To: References: Message-ID: I added an extra line for Mac OS X. So for iOS, the MACOSX_PACKAGE_LOCATION line adds a "Copy Bundle Resource". For OSX, the "TARGET ALL" line copies the shader folder to the build folder. Linux & Windows will probably do the same thing as OSX, and probably Emscripten too. Android will probably need a separate conditional. if(${IsIOS}) set_source_files_properties(shaders PROPERTIES MACOSX_PACKAGE_LOCATION Resources) add_executable(${PROJECT_NAME} MACOSX_BUNDLE ${SRC_LIST} shaders) else() add_custom_target(TARGET ALL COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_SOURCE_DIR}/shaders ${PROJECT_BINARY_DIR}/shaders) add_executable(${PROJECT_NAME} ${SRC_LIST}) endif() On Thu, Sep 10, 2015 at 1:45 AM, Peter List wrote: > In case it helps someone else, here's what I have: > > # after link, add exe > file(GLOB SRC_LIST shaders/* main.cpp) > if(${IsIOS}) > set_source_files_properties(shaders PROPERTIES MACOSX_PACKAGE_LOCATION > Resources) > add_executable(${PROJECT_NAME} MACOSX_BUNDLE ${SRC_LIST} shaders) > else() > add_executable(${PROJECT_NAME} ${SRC_LIST}) > endif() > > It's a bit weird because I have both "shaders/*" and "shaders". However, > "shaders/*" is required for Qt Creator to see my GLSL shader files, while > "shaders" is required for XCode iOS's Copy Bundle Resource. > > Oh I guess "Copy Bundle Resource" is not the same as "Copy Files"... But > I got something that works, and I'll have to look into the difference > between those as a separate issue... > > > > > On Thu, Sep 10, 2015 at 1:20 AM, Peter List wrote: > >> Actually I guess I found the answer here... >> >> >> https://stackoverflow.com/questions/30430968/add-xcode-build-phase-via-cmake >> >> >> On Thu, Sep 10, 2015 at 1:09 AM, Peter List wrote: >> >>> I use cmake to generate an iOS xcode project for "ios-cmake-master". >>> Then I have to can manually add my "shaders" folder to xcode > cmd+4 > >>> Build Phases > + New Copy Files Phase > Destination = Resources, + to add >>> my "shaders" folder. This allows me to have XCode copy my GLSL "shaders" >>> folder (or other files) into the iOS simulator when I run my project. >>> >>> So my question is... How do I tell CMake to generate my .xcodeproj file >>> with this Build Phase? I shouldn't need to manually edit my .xcodeproj >>> file... >>> >>> thank you for any leads >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Sep 10 15:04:08 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Sep 2015 15:04:08 -0400 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: References: <55E4B396.9090609@kitware.com> <55E714E1.10505@kitware.com> <55F0496A.1040205@kitware.com> <55F18811.8000400@kitware.com> Message-ID: <55F1D428.4030707@kitware.com> On 09/10/2015 02:37 PM, Gilles Khouzam wrote: > I don't know that deprecating the API and making it require a > manifest was a better solution, but it does require more > intentional work on the developer before just using the API. The API should not be deprecated if there is any use case for which no replacement is available. The manifest approach does raise the bar, but it also makes no sense for library code that wants to know the Windows version, and still requires use of a deprecated API. MS should have just provided the version helper APIs and updated the GetVersionEx docs to refer to them as preferred. > Added support for manifest files...(VisualStudio 10 generator only) We need it to be supported on all generators. Otherwise when one builds CMake with another generator (like our release binaries) it will not be able to detect the proper version of Windows. The Makefile and Ninja generators already have some support for running the manifest tool while linking a binary. How might one detect Windows 10 in a .cmd (.bat) script? Perhaps we can query something externally instead of using GetVersionEx. Of course having custom manifest support will be nice for apps anyway. > I can split it up in multiple patches if that makes it easier. Yes, please. That makes review and future reading of history easier because we see a commit message associated with each corresponding set of changes. Please order the patches so that no existing functionality breaks at any step and everything compiles. Thanks, -Brad From brad.king at kitware.com Thu Sep 10 15:08:06 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Sep 2015 15:08:06 -0400 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: <55F1D428.4030707@kitware.com> References: <55E4B396.9090609@kitware.com> <55E714E1.10505@kitware.com> <55F0496A.1040205@kitware.com> <55F18811.8000400@kitware.com> <55F1D428.4030707@kitware.com> Message-ID: <55F1D516.802@kitware.com> On 09/10/2015 03:04 PM, Brad King wrote: > On 09/10/2015 02:37 PM, Gilles Khouzam wrote: >> I can split it up in multiple patches if that makes it easier. > > Yes, please. That makes review and future reading of history easier > because we see a commit message associated with each corresponding > set of changes. > > Please order the patches so that no existing functionality breaks at > any step and everything compiles. Also please produce the patches with "git format-patch" so that commit messages and authorship info comes with each one. Thanks, -Brad From steveire at gmail.com Thu Sep 10 16:03:36 2015 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 10 Sep 2015 22:03:36 +0200 Subject: [cmake-developers] use-generator-target topic regressed buildsystem properties References: <55F049F4.5050703@kitware.com> Message-ID: Brad King wrote: > Steve, > > The topic merged here: > > Merge topic 'use-generator-target' > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6e5953e9 > > regressed handling of the buildsystem-aware properties. > I fixed some of the problems and added test cases. Thanks for those! > However, additional problems remain. I've attached updates > to the test suite that demonstrate the failures. The problem > is distinguishing an appended empty value from the empty > sentinel values used in cmState. > > As shown by the USER_PROP test cases added above and in the > attached patch, the behavior for non-buildsystem properties > is to never append empty values. That was changed at some > point in the past for buildsystem property values when we > started recording internal data structures to store them. Yes, that is likely a bug introduced in the last few years. Those should behave the same. > One possible fix to the problems is to avoid allowing empty > values to be appended at all as is done for non-buildsystem > properties. I'm sure that's possible. Is it acceptable to fix it? Another possible fix is to store a vector of sentinal positions for each buildsystem property. I can do either over the next few days. Thanks, Steve. From brad.king at kitware.com Thu Sep 10 16:12:07 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Sep 2015 16:12:07 -0400 Subject: [cmake-developers] use-generator-target topic regressed buildsystem properties In-Reply-To: References: <55F049F4.5050703@kitware.com> Message-ID: <55F1E417.2070108@kitware.com> On 09/10/2015 04:03 PM, Stephen Kelly wrote: >> One possible fix to the problems is to avoid allowing empty >> values to be appended at all as is done for non-buildsystem >> properties. > > I'm sure that's possible. Is it acceptable to fix it? Yes. The inconsistency with non-buildsystem properties is a worthwhile fix anyway. Empty entries in buildsystem properties have no semantic meaning (except perhaps the property value being exactly the empty string as against unset), so there should be no compatibility problem. Please look at fixing that and reference in the commit message when it first changed behavior. This will of course involve updating the expected output in the test cases I added. Then the new tests for directory properties I attached at the start of this thread can be added too. > Another possible fix is to store a vector of sentinal positions for each > buildsystem property. This could be done in addition to the above fixes, but may not be necessary unless needed to support empty property values. Thanks, -Brad P.S. Please refrain from further refactoring until post-3.4 development opens. I'd like to get existing regressions fixed without risking new ones in the weeks leading up to the freeze. From neundorf at kde.org Thu Sep 10 16:11:49 2015 From: neundorf at kde.org (Alexander Neundorf) Date: Thu, 10 Sep 2015 22:11:49 +0200 Subject: [cmake-developers] [ANNOUNCE] DaD's House! (Beta) In-Reply-To: <1137391441890143@web29h.yandex.ru> References: <1448651441822370@web21h.yandex.ru> <1137391441890143@web29h.yandex.ru> Message-ID: <3214828.b5thp3pFS1@tuxedo.neundorf.net> On Thursday, September 10, 2015 16:02:23 Konstantin Podsvirov wrote: > The first 100 views! > The interest is there (though not great), but where are the questions and > suggestions? the web page is quite short on details... It's not an IDE, is it a set of scripts ? Alex From konstantin at podsvirov.pro Thu Sep 10 16:31:50 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 10 Sep 2015 23:31:50 +0300 Subject: [cmake-developers] [ANNOUNCE] DaD's House! (Beta) Message-ID: <284481441917110@web8h.yandex.ru> An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Sep 10 16:41:41 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Sep 2015 16:41:41 -0400 Subject: [cmake-developers] refactor-progress topic regressed Makefile progress In-Reply-To: References: <55E467C4.1080704@kitware.com> Message-ID: <55F1EB05.1040704@kitware.com> On 09/01/2015 12:54 PM, Stephen Kelly wrote: > I made the attached patch to make > cmState::GetBuildsystemDirectoryParent always return the last snapshot > for a directory, which will make sense anyway when properties are > versioned. Does that make sense for all the other callers of GetBuildsystemDirectoryParent too? When you construct the final commit for this please explain in the commit message. Also please link to the commit that introduced the problem and explain why things happened to work before for everything else. Thanks, -Brad From Gilles.Khouzam at microsoft.com Thu Sep 10 19:24:37 2015 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Thu, 10 Sep 2015 23:24:37 +0000 Subject: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version Message-ID: This patch fixes the issue where on Windows 8 and above, by default the system version returned is always Windows 8. More info on this can be found on http://blogs.msdn.com/b/cjacks/archive/2009/03/27/manifesting-for-compatibility-on-windows-7.aspx In order for GetVersionEx to work properly, a manifest must be embedded in the exe telling it to ignore the new behavior and give the proper version. This patch adds support to specify manifests and teaches CMake how to embed them using Visual Studio. This patch adds a simple version manifest Source\cmake.version.manifest to the CMake executables. This removes the use of RtlGetVersion and properly uses GetVersionEx which will now return the proper operating system version for all operating systems until Windows 10. This patch also fixes a potential buffer overrun and improper call of GetVersionEx in SystemTools.cxx where GetVersionExW is called with a OSVERSIONINFOEXA struct causing a failure since the size is improper for the API. Fixing this, GetVersionEx should never fail anymore. Update the OSVersionAndName for new versions of Windows released after Windows 7. This change will require a double compile of CMake (I'm not sure if this is what the dashboards are doing) to have the functionality enabled, since the first step will build a new CMake that will know how to embed a manifest. The second compile with the version of CMake that knows how to embed a manifest, will then embed the manifest in CMake enabling this feature. Thanks ~Gilles -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Issue15674.patch Type: application/octet-stream Size: 15614 bytes Desc: Issue15674.patch URL: From Gilles.Khouzam at microsoft.com Thu Sep 10 21:31:10 2015 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Fri, 11 Sep 2015 01:31:10 +0000 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: <55F1D516.802@kitware.com> References: <55E4B396.9090609@kitware.com> <55E714E1.10505@kitware.com> <55F0496A.1040205@kitware.com> <55F18811.8000400@kitware.com> <55F1D428.4030707@kitware.com> <55F1D516.802@kitware.com> Message-ID: Here is the patch for Windows 10 Support which would be issue 15686. This is dependent on the patch for issue 15674 which is the version detection change. >From the commit message: This change adds support for Windows 10 Universal Applications. A Windows 10 Universal Application can be targeted by setting: CMAKE_SYSTEM_NAME=WindowsStore and CMAKE_SYSTEM_VERSION=10.0 There are no WindowsPhone apps, universal apps target both phone and store. New Properties Added: VS_TARGET_PLATFORM_VERSION: Target property. Specifies that the SDK being used to compile the project. For Windows 10 RTM, that will be 10.0.10240.0. For Store apps, this property is required by Visual Studio. If the property is not specified, the system will be queried for the available Windows 10 SDKs installed and the most recent but less than or equal version than the host system version will be set as a default (in CMAKE_VS_TARGET_PLATFORM_VERSION) and used. VS_TARGET_PLATFORM_MIN_VERSION: Target Property. Specifies the minimum version of the OS that the project can target. VS_DESKTOP_EXTENSIONS_VERSION, VS_MOBILE_EXTENSIONS_VERSIONS, VS_IOT_EXTENSIONS_VERSION: Target property. When specifying these properties a reference to the version of the SDK specified will be added to the project allowing to target the extended functionality in a universal project. VS_IOT_STARTUP_TASK: Target property. Specifies that the target should be built as an IOT continuous background task. VS_TOOL_OVERRIDE: Source property. For common files, allows to modify the tool that gets applied to the source file. For example, when adding a .RESW file to the project, since CMake doesn't know how to handle them, it will assign a None Tool to the file. This allows to override the default and specify a new tool to handle. This change requires the change for issue 0015674 for determining the version of the OS. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Thursday, September 10, 2015 12:08 To: Gilles Khouzam Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/10/2015 03:04 PM, Brad King wrote: > On 09/10/2015 02:37 PM, Gilles Khouzam wrote: >> I can split it up in multiple patches if that makes it easier. > > Yes, please. That makes review and future reading of history easier > because we see a commit message associated with each corresponding set > of changes. > > Please order the patches so that no existing functionality breaks at > any step and everything compiles. Also please produce the patches with "git format-patch" so that commit messages and authorship info comes with each one. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: Issue15686.patch Type: application/octet-stream Size: 43772 bytes Desc: Issue15686.patch URL: From biddisco at cscs.ch Fri Sep 11 08:38:52 2015 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Fri, 11 Sep 2015 12:38:52 +0000 Subject: [cmake-developers] Odd behaviour in VS14 (Visual studio 2015) Message-ID: <50320452A334BD42A5EC72BAD21450993C7FD9C4@MBX110.d.ethz.ch> Using cmake 3.3.1 I have been having problems with projects in VS14 and it appears to be caused by the generation of paths used by/in the IDE D:\Code\hvtkm\vtkm\vtkm/worklet/GaussianSplatter.h whereas it used to always be D:\Code\hvtkm\vtkm\vtkm\worklet\GaussianSplatter.h Note the forwardslash instead of backslash in the latest IDE The result is that when you click on an error, the window opens up a 'new' copy of the file and changes you make in it are not always picked up, syntax highlighting, debug watches/vars don't work and I've lost quite a bit of work by having 'N' copies of the file open and saved one without realising another was open multiple times with changes in. I will submit a bug report, but before I do, has anyone else noticed this (I'm afraid I don't follow the list very thoroughly and my quick check on mantis revealed nothing). I suspect I'm doing something wrong, so though I'd ask before creating an issue... thanks JB -- John Biddiscombe, email:biddisco @.at.@ cscs.ch http://www.cscs.ch/ CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07 Via Trevano 131, 6900 Lugano, Switzerland | Fax: +41 (91) 610.82.82 -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffi.enficiaud at mines-paris.org Fri Sep 11 10:19:31 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Fri, 11 Sep 2015 16:19:31 +0200 Subject: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive Message-ID: Hi Brad and Domen, This is a follow up of the following thread http://public.kitware.com/pipermail/cmake-developers/2015-August/026125.html I have made the following changes in order to: - support the UID/GID/UNAME/GNAME and permission on tar files at creation time - using directly libarchive in CPackDeb - removing completely the need of fakeroot Please review the patches (mainly 2, the other one is just a typo fix). Or if you prefer I can just create a topic. The patches are based on master and are quite orthogonal. Is it on time for 3.4 freeze? Thanks! Raffi -------------- next part -------------- From 2f12e427c4ffe238fbf79d7c317c90b4d9c3131f Mon Sep 17 00:00:00 2001 From: Raffi Enficiaud Date: Tue, 8 Sep 2015 23:09:01 +0200 Subject: [PATCH 1/3] Various typo fixes RunCMake.CPack: Making the error message somehow more readable --- Source/cmGeneratedFileStream.h | 4 ++-- Tests/RunCMake/CPack/DEB/Helpers.cmake | 2 +- Tests/RunCMake/CPack/README.txt | 4 ++-- Tests/RunCMake/CPack/VerifyResult.cmake | 7 ++++--- 4 files changed, 9 insertions(+), 8 deletions(-) diff --git a/Source/cmGeneratedFileStream.h b/Source/cmGeneratedFileStream.h index 2aa6beb..8df3e1a 100644 --- a/Source/cmGeneratedFileStream.h +++ b/Source/cmGeneratedFileStream.h @@ -56,10 +56,10 @@ protected: // Whether the real file stream was valid when it was closed. bool Okay; - // Whether the destionation file is compressed + // Whether the destination file is compressed bool Compress; - // Whether the destionation file is compressed + // Whether the destination file is compressed bool CompressExtraExtension; }; diff --git a/Tests/RunCMake/CPack/DEB/Helpers.cmake b/Tests/RunCMake/CPack/DEB/Helpers.cmake index a204a3c..b6f113b 100644 --- a/Tests/RunCMake/CPack/DEB/Helpers.cmake +++ b/Tests/RunCMake/CPack/DEB/Helpers.cmake @@ -14,7 +14,7 @@ function(verifyDebControl FILE PREFIX VERIFY_FILES) ERROR_VARIABLE err_) if(err_) - message(FATAL_ERROR "Debian controll verification failed for file: " + message(FATAL_ERROR "Debian control verification failed for file: " "'${FILE}'; error output: '${err_}'") endif() diff --git a/Tests/RunCMake/CPack/README.txt b/Tests/RunCMake/CPack/README.txt index 365c737..ea68304 100644 --- a/Tests/RunCMake/CPack/README.txt +++ b/Tests/RunCMake/CPack/README.txt @@ -32,14 +32,14 @@ different types of packages. This script is placed into CPack test root directory even if it will be used for only one of the generators. If test will be used for multiple generators but some of them require some -generator speciffic commands then those commands should be added to a separate +generator specific commands then those commands should be added to a separate file that should be located in '/-specifics.cmake' in CPack test root directory. CPack execution phase: ---------------------- -Only exececutes CPack for content that was generated during CMake execution +Only executes CPack for content that was generated during CMake execution phase. Verification of generated files: diff --git a/Tests/RunCMake/CPack/VerifyResult.cmake b/Tests/RunCMake/CPack/VerifyResult.cmake index 96efa9e..6eab531 100644 --- a/Tests/RunCMake/CPack/VerifyResult.cmake +++ b/Tests/RunCMake/CPack/VerifyResult.cmake @@ -28,8 +28,9 @@ if(NOT EXPECTED_FILES_COUNT EQUAL 0) if(NOT expected_content_list) message(FATAL_ERROR - "Unexpected file content for file No. '${file_no_}'!" - " Content: '${PACKAGE_CONTENT}'" + "Unexpected file content for file No. '${file_no_}'!\n" + " Content: '${PACKAGE_CONTENT}'\n\n" + " Expected: '${EXPECTED_FILE_CONTENT_${file_no_}}'" "${output_error_message}") endif() else() @@ -56,7 +57,7 @@ if(NOT EXPECTED_FILES_COUNT EQUAL 0) "${output_error_message}") endif() - # sanity check that we didn't accidentaly list wrong files with our regular + # sanity check that we didn't accidentally list wrong files with our regular # expressions foreach(expected_ IN LISTS allFoundFiles_) list(FIND foundFiles_ "${expected_}" found_) -- 2.0.1 -------------- next part -------------- From ba086d51479b7d5d11652d3647e5f4775d0a4f7d Mon Sep 17 00:00:00 2001 From: Raffi Enficiaud Date: Fri, 11 Sep 2015 16:00:28 +0200 Subject: [PATCH 2/3] cmArchiveWrite: user/group and permissions - support for UID/GID and UNAME/GNAME - support for permission and permission mask - support for non-recursive folder adding --- Source/cmArchiveWrite.cxx | 45 ++++++++++++++++++++++++--- Source/cmArchiveWrite.h | 77 +++++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 115 insertions(+), 7 deletions(-) diff --git a/Source/cmArchiveWrite.cxx b/Source/cmArchiveWrite.cxx index 9f56324..a8fc85d 100644 --- a/Source/cmArchiveWrite.cxx +++ b/Source/cmArchiveWrite.cxx @@ -84,7 +84,11 @@ cmArchiveWrite::cmArchiveWrite( Archive(archive_write_new()), Disk(archive_read_disk_new()), Verbose(false), - Format(format) + Format(format), + uid(-1), + gid(-1), + permissions(-1), + permissionsMask(-1) { switch (c) { @@ -181,7 +185,10 @@ cmArchiveWrite::~cmArchiveWrite() } //---------------------------------------------------------------------------- -bool cmArchiveWrite::Add(std::string path, size_t skip, const char* prefix) +bool cmArchiveWrite::Add(std::string path, + size_t skip, + const char* prefix, + bool recursive) { if(this->Okay()) { @@ -189,20 +196,21 @@ bool cmArchiveWrite::Add(std::string path, size_t skip, const char* prefix) { path.erase(path.size()-1); } - this->AddPath(path.c_str(), skip, prefix); + this->AddPath(path.c_str(), skip, prefix, recursive); } return this->Okay(); } //---------------------------------------------------------------------------- bool cmArchiveWrite::AddPath(const char* path, - size_t skip, const char* prefix) + size_t skip, const char* prefix, + bool recursive) { if(!this->AddFile(path, skip, prefix)) { return false; } - if(!cmSystemTools::FileIsDirectory(path) || + if((!cmSystemTools::FileIsDirectory(path) || !recursive) || cmSystemTools::FileIsSymlink(path)) { return true; @@ -278,6 +286,33 @@ bool cmArchiveWrite::AddFile(const char* file, } archive_entry_set_mtime(e, t, 0); } + + // manages the uid/guid of the entry (if any) + if (this->uid > -1 && this->gid > -1) + { + archive_entry_set_uid(e, this->uid); + archive_entry_set_gid(e, this->gid); + } + + if (this->uname.size() && this->gname.size()) + { + archive_entry_set_uname(e, this->uname.c_str()); + archive_entry_set_gname(e, this->gname.c_str()); + } + + + // manages the permissions + if (this->permissions > -1) + { + archive_entry_set_perm(e, this->permissions); + } + + if (this->permissionsMask > -1) + { + mode_t perm = archive_entry_filetype(e); + archive_entry_set_perm(e, perm & this->permissionsMask ); + } + // Clear acl and xattr fields not useful for distribution. archive_entry_acl_clear(e); archive_entry_xattr_clear(e); diff --git a/Source/cmArchiveWrite.h b/Source/cmArchiveWrite.h index e6f515d..353dfe8 100644 --- a/Source/cmArchiveWrite.h +++ b/Source/cmArchiveWrite.h @@ -52,7 +52,10 @@ public: * skip. The remaining part of the input path is appended to the * "prefix" value to construct the final name in the archive. */ - bool Add(std::string path, size_t skip = 0, const char* prefix = 0); + bool Add(std::string path, + size_t skip = 0, + const char* prefix = 0, + bool recursive = true); /** Returns true if there has been no error. */ operator safe_bool() const @@ -69,9 +72,61 @@ public: void SetVerbose(bool v) { this->Verbose = v; } void SetMTime(std::string const& t) { this->MTime = t; } + + + //! Sets the permissions of the added files/folders + //! @note set to -1 to use the default permissions + long int SetPermissions(long int permissions_) + { + std::swap(this->permissions, permissions_); + return permissions_; + } + + //! Sets the permissions mask of the files/folders + //! + //! The permissions will be copied from the existing file + //! or folder. The mask will then be applied to unset + //! some of them + long int SetPermissionsMask(long int permissionsMask_) + { + std::swap(this->permissionsMask, permissionsMask_); + return permissionsMask_; + } + + //! Sets the UID to be used in the tar file + //! @return the previous UID + //! @note set to -1 to disable the UID overriding + long int SetUID( long int uid_ ) + { + std::swap(this->uid, uid_); + return uid_; + + } + + std::string SetUNAME(std::string uname_) + { + std::swap(this->uname, uname_); + return uname_; + } + + //! Sets the UID to be used in the tar file + //! @return the previous UID + long int SetGID( long int gid_ ) + { + std::swap(this->gid, gid_); + return gid_; + } + + std::string SetGNAME(std::string gname_) + { + std::swap(this->gname, gname_); + return gname_; + } + private: bool Okay() const { return this->Error.empty(); } - bool AddPath(const char* path, size_t skip, const char* prefix); + bool AddPath(const char* path, size_t skip, const char* prefix, + bool recursive = true); bool AddFile(const char* file, size_t skip, const char* prefix); bool AddData(const char* file, size_t size); @@ -87,6 +142,24 @@ private: std::string Format; std::string Error; std::string MTime; + + //! UID of the user in the tar file. Set to -1 + //! to disable overriding + long int uid; + + //! GUID of the user in the tar file + long int gid; + + //! UNAME/GNAME of the user (doies not override UID/GID) + //!@{ + std::string uname; + std::string gname; + //!@} + + + //! Permissions on the files/folders + long int permissions; + long int permissionsMask; }; #endif -- 2.0.1 -------------- next part -------------- From 02d58d1bb81e7bbdee6d0ef9a8674b8d0c914126 Mon Sep 17 00:00:00 2001 From: Raffi Enficiaud Date: Fri, 11 Sep 2015 16:02:35 +0200 Subject: [PATCH 3/3] CPackDeb: use of libarchive and removal of fakeroot - using directly libarchive/cmArchiveWrite for creating intermediate tar files - removing need for fakeroot and managing uname/gname and uid/gid directly from libarchive - managing file permissions directly from libarchive --- Modules/CPackDeb.cmake | 6 - Source/CPack/cmCPackDebGenerator.cxx | 274 +++++++++++++++++++++-------------- 2 files changed, 162 insertions(+), 118 deletions(-) diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake index 75e9966..502415a 100644 --- a/Modules/CPackDeb.cmake +++ b/Modules/CPackDeb.cmake @@ -321,11 +321,6 @@ function(cpack_deb_prepare_package_vars) set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS OFF) endif() - find_program(FAKEROOT_EXECUTABLE fakeroot) - if(FAKEROOT_EXECUTABLE) - set(CPACK_DEBIAN_FAKEROOT_EXECUTABLE ${FAKEROOT_EXECUTABLE}) - endif() - set(WDIR "${CPACK_TOPLEVEL_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME}${CPACK_DEB_PACKAGE_COMPONENT_PART_PATH}") # per component automatic discover: some of the component might not have @@ -638,7 +633,6 @@ function(cpack_deb_prepare_package_vars) set(GEN_CPACK_DEBIAN_PACKAGE_MAINTAINER "${CPACK_DEBIAN_PACKAGE_MAINTAINER}" PARENT_SCOPE) set(GEN_CPACK_DEBIAN_PACKAGE_DESCRIPTION "${CPACK_DEBIAN_PACKAGE_DESCRIPTION}" PARENT_SCOPE) set(GEN_CPACK_DEBIAN_PACKAGE_DEPENDS "${CPACK_DEBIAN_PACKAGE_DEPENDS}" PARENT_SCOPE) - set(GEN_CPACK_DEBIAN_FAKEROOT_EXECUTABLE "${CPACK_DEBIAN_FAKEROOT_EXECUTABLE}" PARENT_SCOPE) set(GEN_CPACK_DEBIAN_COMPRESSION_TYPE "${CPACK_DEBIAN_COMPRESSION_TYPE}" PARENT_SCOPE) set(GEN_CPACK_DEBIAN_PACKAGE_RECOMMENDS "${CPACK_DEBIAN_PACKAGE_RECOMMENDS}" PARENT_SCOPE) set(GEN_CPACK_DEBIAN_PACKAGE_SUGGESTS "${CPACK_DEBIAN_PACKAGE_SUGGESTS}" PARENT_SCOPE) diff --git a/Source/CPack/cmCPackDebGenerator.cxx b/Source/CPack/cmCPackDebGenerator.cxx index 5049a3f..06c9c4f 100644 --- a/Source/CPack/cmCPackDebGenerator.cxx +++ b/Source/CPack/cmCPackDebGenerator.cxx @@ -15,6 +15,7 @@ #include "cmMakefile.h" #include "cmGeneratedFileStream.h" #include "cmCPackLog.h" +#include "cmArchiveWrite.h" #include #include @@ -388,9 +389,9 @@ int cmCPackDebGenerator::createDeb() { std::string dirName = this->GetOption("CPACK_TEMPORARY_DIRECTORY"); dirName += '/'; - for (std::vector::const_iterator fileIt = - packageFiles.begin(); - fileIt != packageFiles.end(); ++ fileIt ) + for (std::vector::const_iterator fileIt = + packageFiles.begin(); + fileIt != packageFiles.end(); ++ fileIt ) { totalSize += cmSystemTools::FileLength(*fileIt); } @@ -401,190 +402,239 @@ int cmCPackDebGenerator::createDeb() out << std::endl; } - std::string cmd(this->GetOption("GEN_CPACK_DEBIAN_FAKEROOT_EXECUTABLE")); + const std::string strGenWDIR(this->GetOption("GEN_WDIR")); + + + cmArchiveWrite::Compress tar_compression_type = cmArchiveWrite::CompressGZip; const char* debian_compression_type = this->GetOption("GEN_CPACK_DEBIAN_COMPRESSION_TYPE"); if(!debian_compression_type) - { + { debian_compression_type = "gzip"; - } + } - std::string cmake_tar = " ", compression_modifier = "a", compression_suffix; + std::string compression_suffix; if(!strcmp(debian_compression_type, "lzma")) { compression_suffix = ".lzma"; + tar_compression_type = cmArchiveWrite::CompressLZMA; } else if(!strcmp(debian_compression_type, "xz")) { compression_suffix = ".xz"; + tar_compression_type = cmArchiveWrite::CompressXZ; } else if(!strcmp(debian_compression_type, "bzip2")) { compression_suffix = ".bz2"; - compression_modifier = "j"; - cmake_tar += "\"" + cmSystemTools::GetCMakeCommand() + "\" -E "; + tar_compression_type = cmArchiveWrite::CompressBZip2; } else if(!strcmp(debian_compression_type, "gzip")) { compression_suffix = ".gz"; - compression_modifier = "z"; - cmake_tar += "\"" + cmSystemTools::GetCMakeCommand() + "\" -E "; + tar_compression_type = cmArchiveWrite::CompressGZip; } else if(!strcmp(debian_compression_type, "none")) { compression_suffix = ""; - compression_modifier = ""; - cmake_tar += "\"" + cmSystemTools::GetCMakeCommand() + "\" -E "; + tar_compression_type = cmArchiveWrite::CompressNone; } else { cmCPackLogger(cmCPackLog::LOG_ERROR, "Error unrecognized compression type: " << debian_compression_type << std::endl); } - cmd += cmake_tar + "tar c" + compression_modifier + "f data.tar" - + compression_suffix; - // now add all directories which have to be compressed - // collect all top level install dirs for that - // e.g. /opt/bin/foo, /usr/bin/bar and /usr/bin/baz would give /usr and /opt - size_t topLevelLength = std::string(this->GetOption("GEN_WDIR")).length(); - cmCPackLogger(cmCPackLog::LOG_DEBUG, "WDIR: \"" - << this->GetOption("GEN_WDIR") - << "\", length = " << topLevelLength + std::string filename_data_tar = strGenWDIR + + "/data.tar" + compression_suffix; + + // atomic file generation for data.tar + { + cmGeneratedFileStream fileStream_data_tar; + fileStream_data_tar.Open(filename_data_tar.c_str(), false, true); + if(!fileStream_data_tar) + { + cmCPackLogger(cmCPackLog::LOG_ERROR, + "Error opening the file \"" << filename_data_tar << "\" for writing" << std::endl); - std::set installDirs; + return 0; + } + cmArchiveWrite data_tar(fileStream_data_tar, tar_compression_type, "paxr"); + + // uid/gid should be the one of the root user, and this root user has + // always uid/gid equal to 0. + data_tar.SetUID(0); + data_tar.SetGID(0); + data_tar.SetUNAME("root"); + data_tar.SetGNAME("root"); + data_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH); + + // now add all directories which have to be compressed + // collect all top level install dirs for that + // e.g. /opt/bin/foo, /usr/bin/bar and /usr/bin/baz would + // give /usr and /opt + size_t topLevelLength = strGenWDIR.length(); + cmCPackLogger(cmCPackLog::LOG_DEBUG, "WDIR: \"" + << strGenWDIR + << "\", length = " << topLevelLength + << std::endl); + std::set orderedFiles; + + // we have to reconstruct the parent folders as well + + for (std::vector::const_iterator fileIt = - packageFiles.begin(); - fileIt != packageFiles.end(); ++ fileIt ) + packageFiles.begin(); + fileIt != packageFiles.end(); ++ fileIt ) { - cmCPackLogger(cmCPackLog::LOG_DEBUG, "FILEIT: \"" << *fileIt << "\"" - << std::endl); - std::string::size_type slashPos = fileIt->find('/', topLevelLength+1); - std::string relativeDir = fileIt->substr(topLevelLength, - slashPos - topLevelLength); - cmCPackLogger(cmCPackLog::LOG_DEBUG, "RELATIVEDIR: \"" << relativeDir - << "\"" << std::endl); - if (installDirs.find(relativeDir) == installDirs.end()) + std::string currentPath = *fileIt; + while(currentPath != strGenWDIR) { - installDirs.insert(relativeDir); - cmd += " ."; - cmd += relativeDir; + // the last one IS strGenWDIR, but we do not want this one: + // XXX/application/usr/bin/myprogram with GEN_WDIR=XXX/application + // should not add XXX/application + orderedFiles.insert(currentPath); + currentPath = cmSystemTools::CollapseCombinedPath(currentPath, ".."); } } - std::string output; - int retval = -1; - int res = cmSystemTools::RunSingleCommand(cmd.c_str(), &output, &output, - &retval, this->GetOption("GEN_WDIR"), this->GeneratorVerbose, 0); - if ( !res || retval ) + for (std::set::const_iterator fileIt = + orderedFiles.begin(); + fileIt != orderedFiles.end(); ++ fileIt ) { - std::string tmpFile = this->GetOption("CPACK_TOPLEVEL_DIRECTORY"); - tmpFile += "/Deb.log"; - cmGeneratedFileStream ofs(tmpFile.c_str()); - ofs << "# Run command: " << cmd << std::endl - << "# Working directory: " << toplevel << std::endl - << "# Output:" << std::endl - << output << std::endl; - cmCPackLogger(cmCPackLog::LOG_ERROR, "Problem running tar command: " - << cmd << std::endl - << "Please check " << tmpFile << " for errors" << std::endl); - return 0; + + cmCPackLogger(cmCPackLog::LOG_DEBUG, "FILEIT: \"" << *fileIt << "\"" + << std::endl); + std::string::size_type slashPos = fileIt->find('/', topLevelLength+1); + std::string relativeDir = fileIt->substr(topLevelLength, + slashPos - topLevelLength); + cmCPackLogger(cmCPackLog::LOG_DEBUG, "RELATIVEDIR: \"" << relativeDir + << "\"" << std::endl); + + // do not recurse because the loop will do it + if(!data_tar.Add(*fileIt, topLevelLength, ".", false)) + { + cmCPackLogger(cmCPackLog::LOG_ERROR, + "Problem adding file to tar:" << std::endl + << "#top level directory: " + << strGenWDIR << std::endl + << "#file: " << *fileIt << std::endl + << "#error:" << data_tar.GetError() << std::endl); + return 0; + } + } + } // scope for file generation - std::string md5filename; - md5filename = this->GetOption("GEN_WDIR"); - md5filename += "/md5sums"; - { // the scope is needed for cmGeneratedFileStream + std::string md5filename = strGenWDIR + "/md5sums"; + { + // the scope is needed for cmGeneratedFileStream cmGeneratedFileStream out(md5filename.c_str()); - std::vector::const_iterator fileIt; -// std::string topLevelWithTrailingSlash = toplevel; + std::string topLevelWithTrailingSlash = this->GetOption("CPACK_TEMPORARY_DIRECTORY"); topLevelWithTrailingSlash += '/'; - for ( fileIt = packageFiles.begin(); - fileIt != packageFiles.end(); ++ fileIt ) - { - cmd = "\""; + for (std::vector::const_iterator fileIt = + packageFiles.begin(); + fileIt != packageFiles.end(); ++ fileIt ) + { + std::string cmd = "\""; cmd += cmSystemTools::GetCMakeCommand(); cmd += "\" -E md5sum \""; cmd += *fileIt; cmd += "\""; - //std::string output; - //int retVal = -1; - res = cmSystemTools::RunSingleCommand(cmd.c_str(), &output, &output, + + std::string output; + int retval = -1; + int res = cmSystemTools::RunSingleCommand(cmd.c_str(), &output, &output, &retval, toplevel.c_str(), this->GeneratorVerbose, 0); if ( !res || retval ) - { + { cmCPackLogger(cmCPackLog::LOG_ERROR, "Problem running cmake -E md5sum " << cmd << std::endl); - } + } // debian md5sums entries are like this: // 014f3604694729f3bf19263bac599765 usr/bin/ccmake // thus strip the full path (with the trailing slash) cmSystemTools::ReplaceString(output, topLevelWithTrailingSlash.c_str(), ""); out << output; - } + } // each line contains a eol. // Do not end the md5sum file with yet another (invalid) - } + } - // set md5sum file permissins to RW-R--R-- so that deb lintian doesn't warn - // about it - cmSystemTools::SetPermissions(md5filename.c_str(), - S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); - cmd = this->GetOption("GEN_CPACK_DEBIAN_FAKEROOT_EXECUTABLE"); - cmd += cmake_tar + "tar czf control.tar.gz ./control ./md5sums"; + + std::string filename_control_tar = strGenWDIR + "/control.tar.gz"; + // atomic file generation for control.tar + { + cmGeneratedFileStream fileStream_control_tar; + fileStream_control_tar.Open(filename_control_tar.c_str(), false, true); + if(!fileStream_control_tar) + { + cmCPackLogger(cmCPackLog::LOG_ERROR, + "Error opening the file \"" << filename_control_tar + << "\" for writing" << std::endl); + return 0; + } + cmArchiveWrite control_tar(fileStream_control_tar, + tar_compression_type, + "paxr"); + + // sets permissions and uid/gid for the files + control_tar.SetUID(0); + control_tar.SetGID(0); + control_tar.SetUNAME("root"); + control_tar.SetGNAME("root"); + + // set md5sum file permissins to RW-R--R-- so that deb lintian + // doesn't warn about it + control_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH); + + // adds control and md5sums + if( !control_tar.Add(md5filename, strGenWDIR.length(), ".") + || !control_tar.Add(strGenWDIR + "/control", strGenWDIR.length(), ".")) + { + cmCPackLogger(cmCPackLog::LOG_ERROR, + "Error adding file to tar:" << std::endl + << "#top level directory: " + << strGenWDIR << std::endl + << "#file: \"control\" or \"md5sums\"" << std::endl + << "#error:" << control_tar.GetError() << std::endl); + return 0; + } + const char* controlExtra = this->GetOption("GEN_CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA"); - if( controlExtra ) + if( controlExtra ) { - std::vector controlExtraList; - cmSystemTools::ExpandListArgument(controlExtra, controlExtraList); - for(std::vector::iterator i = - controlExtraList.begin(); i != controlExtraList.end(); ++i) + std::vector controlExtraList; + cmSystemTools::ExpandListArgument(controlExtra, controlExtraList); + for(std::vector::iterator i = controlExtraList.begin(); + i != controlExtraList.end(); ++i) { - std::string filenamename = - cmsys::SystemTools::GetFilenameName(*i); - std::string localcopy = this->GetOption("GEN_WDIR"); - localcopy += "/"; - localcopy += filenamename; - // if we can copy the file, it means it does exist, let's add it: - if( cmsys::SystemTools::CopyFileIfDifferent( - *i, localcopy) ) + std::string filenamename = + cmsys::SystemTools::GetFilenameName(*i); + std::string localcopy = strGenWDIR + "/" + filenamename; + + // if we can copy the file, it means it does exist, let's add it: + if( cmsys::SystemTools::CopyFileIfDifferent(*i, localcopy) ) { - // debian is picky and need relative to ./ path in the tar.* - cmd += " ./"; - cmd += filenamename; + control_tar.Add(localcopy, strGenWDIR.length(), "."); } } } - res = cmSystemTools::RunSingleCommand(cmd.c_str(), &output, &output, - &retval, this->GetOption("GEN_WDIR"), this->GeneratorVerbose, 0); + } - if ( !res || retval ) - { - std::string tmpFile = this->GetOption("CPACK_TOPLEVEL_DIRECTORY"); - tmpFile += "/Deb.log"; - cmGeneratedFileStream ofs(tmpFile.c_str()); - ofs << "# Run command: " << cmd << std::endl - << "# Working directory: " << toplevel << std::endl - << "# Output:" << std::endl - << output << std::endl; - cmCPackLogger(cmCPackLog::LOG_ERROR, "Problem running tar command: " - << cmd << std::endl - << "Please check " << tmpFile << " for errors" << std::endl); - return 0; - } // ar -r your-package-name.deb debian-binary control.tar.* data.tar.* // since debian packages require BSD ar (most Linux distros and even // FreeBSD and NetBSD ship GNU ar) we use a copy of OpenBSD ar here. std::vector arFiles; - std::string topLevelString = this->GetOption("GEN_WDIR"); + std::string topLevelString = this->GetOption("GEN_WDIR"); topLevelString += "/"; arFiles.push_back(topLevelString + "debian-binary"); arFiles.push_back(topLevelString + "control.tar.gz"); arFiles.push_back(topLevelString + "data.tar" + compression_suffix); - std::string outputFileName = this->GetOption("CPACK_TOPLEVEL_DIRECTORY"); - outputFileName += "/"; - outputFileName += this->GetOption("CPACK_OUTPUT_FILE_NAME"); - res = ar_append(outputFileName.c_str(), arFiles); + std::string outputFileName = this->GetOption("CPACK_TOPLEVEL_DIRECTORY"); + outputFileName += "/"; + outputFileName += this->GetOption("CPACK_OUTPUT_FILE_NAME"); + int res = ar_append(outputFileName.c_str(), arFiles); if ( res!=0 ) { std::string tmpFile = this->GetOption("CPACK_TEMPORARY_PACKAGE_FILE_NAME"); -- 2.0.1 From a.bergmeier at dsfishlabs.com Fri Sep 11 10:44:21 2015 From: a.bergmeier at dsfishlabs.com (Andreas Bergmeier) Date: Fri, 11 Sep 2015 14:44:21 +0000 Subject: [cmake-developers] Python extension to FindProtobuf Message-ID: <6B1070FD3B25C348BB7E9CD29C1F16D137E70DCE@flexchange.home.fishlabs.net> Since beneath generating cpp and h files we often also want python bindings to be generated, I would like to have the following extension to FindProtobuf added. This adds protobuf_generate_python function. ________________________________ Diese E-mail enth?lt VERTRAULICHE UND PERS?NLICHE INFORMATIONEN und/oder PRIVILEGIERTE UND VERTRAULICHE MITTEILUNGEN, die ausschlie?lich f?r die angesprochenen Empf?nger bestimmt sind. Ohne ausdr?ckliche schriftliche Zustimmung des Absenders d?rfen diese Informationen und Mitteilungen nicht an irgendeinen Dritten au?erhalb der Organisation des Empf?ngers weitergeleitet oder zur Kenntnis gebracht werden. Wenn Sie diese E-mail versehentlich empfangen haben, teilen Sie dies bitte dem Absender umgehend telefonisch oder durch R?cksendung dieser E-mail mit, und zerst?ren Sie die Mail sowie Ihre evtl. R?ckmail bitte anschlie?end, ohne eine Kopie zu erstellen. Koch Media ?bernimmt keinerlei Verantwortung f?r m?gliche Verluste oder Besch?digungen, resultierend aus virus-infizierten E-mails bzw. Viren in Anh?ngen. This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Koch Media accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Fri Sep 11 11:06:27 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 11 Sep 2015 17:06:27 +0200 Subject: [cmake-developers] Python extension to FindProtobuf In-Reply-To: <6B1070FD3B25C348BB7E9CD29C1F16D137E70DCE@flexchange.home.fishlabs.net> References: <6B1070FD3B25C348BB7E9CD29C1F16D137E70DCE@flexchange.home.fishlabs.net> Message-ID: <1727564.SG6oXUDnmz@caliban.sf-tec.de> Am Freitag, 11. September 2015, 14:44:21 schrieb Andreas Bergmeier: > Since beneath generating cpp and h files we often also want python bindings > to be generated, I would like to have the following extension to > FindProtobuf added. This adds protobuf_generate_python function. Forgot to add patch? > ________________________________ > Diese E-mail enth?lt VERTRAULICHE UND PERS?NLICHE INFORMATIONEN und/oder [?] Argh! 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 a.bergmeier at dsfishlabs.com Fri Sep 11 11:11:42 2015 From: a.bergmeier at dsfishlabs.com (Andreas Bergmeier) Date: Fri, 11 Sep 2015 15:11:42 +0000 Subject: [cmake-developers] Python extension to FindProtobuf In-Reply-To: <1727564.SG6oXUDnmz@caliban.sf-tec.de> References: <6B1070FD3B25C348BB7E9CD29C1F16D137E70DCE@flexchange.home.fishlabs.net> <1727564.SG6oXUDnmz@caliban.sf-tec.de> Message-ID: <6B1070FD3B25C348BB7E9CD29C1F16D137E70DF0@flexchange.home.fishlabs.net> Blindly trusting Outlook D&D was a bad idea ;) Here is the commit. (Sorry the footer is company policy) -----Original Message----- From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Rolf Eike Beer Sent: Freitag, 11. September 2015 17:07 To: cmake-developers at cmake.org Subject: Re: [cmake-developers] Python extension to FindProtobuf Am Freitag, 11. September 2015, 14:44:21 schrieb Andreas Bergmeier: > Since beneath generating cpp and h files we often also want python > bindings to be generated, I would like to have the following extension > to FindProtobuf added. This adds protobuf_generate_python function. Forgot to add patch? > ________________________________ > Diese E-mail enth?lt VERTRAULICHE UND PERS?NLICHE INFORMATIONEN > und/oder [?] Argh! Eike -- ________________________________ Diese E-mail enth?lt VERTRAULICHE UND PERS?NLICHE INFORMATIONEN und/oder PRIVILEGIERTE UND VERTRAULICHE MITTEILUNGEN, die ausschlie?lich f?r die angesprochenen Empf?nger bestimmt sind. Ohne ausdr?ckliche schriftliche Zustimmung des Absenders d?rfen diese Informationen und Mitteilungen nicht an irgendeinen Dritten au?erhalb der Organisation des Empf?ngers weitergeleitet oder zur Kenntnis gebracht werden. Wenn Sie diese E-mail versehentlich empfangen haben, teilen Sie dies bitte dem Absender umgehend telefonisch oder durch R?cksendung dieser E-mail mit, und zerst?ren Sie die Mail sowie Ihre evtl. R?ckmail bitte anschlie?end, ohne eine Kopie zu erstellen. Koch Media ?bernimmt keinerlei Verantwortung f?r m?gliche Verluste oder Besch?digungen, resultierend aus virus-infizierten E-mails bzw. Viren in Anh?ngen. This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Koch Media accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. -------------- next part -------------- A non-text attachment was scrubbed... Name: commit-2c9f168 Type: application/octet-stream Size: 2366 bytes Desc: commit-2c9f168 URL: From brad.king at kitware.com Fri Sep 11 11:36:31 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 11 Sep 2015 11:36:31 -0400 Subject: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version In-Reply-To: References: Message-ID: <55F2F4FF.2060004@kitware.com> On 09/10/2015 07:24 PM, Gilles Khouzam wrote: > This patch fixes the issue where on Windows 8 and above, by > default the system version returned is always Windows 8. > > In order for GetVersionEx to work properly, a manifest must be > embedded in the exe telling it to ignore the new behavior and > give the proper version. Thanks. I've started by extracting the changes to GetVersionEx calls. Yesterday I reverted the recent RtlGetVersion change: Revert "Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8.1" http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4c7744c8 I rebased your patch on that and applied the part that gets the third version component: Windows: Set CMAKE_HOST_SYSTEM_VERSION with three components http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4734df5f I also extracted the KWSys part of the change and applied it upstream: http://review.source.kitware.com/20180 http://review.source.kitware.com/20181 Once those test cleanly they will be integrated into KWSys and then updated in CMake. Then I can rebase everything else on top of that. Thanks, -Brad From JamesJ at motionview3d.com Fri Sep 11 11:45:38 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Fri, 11 Sep 2015 15:45:38 -0000 Subject: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version In-Reply-To: References: Message-ID: <041501d0eca8$e8cdb2c0$ba691840$@motionview3d.com> Well this is quite cool. :) It's been an issue I've wanted to see addressed as well but haven't had the time to look at it. Not because of CMake itself not having a manifest (the improper GetVersionEx detection didn't affect me), but because I need to embed an app manifest in my own programs. I have some ideas while you are on the subject: 1. No documentation files were updated. I wonder if there is a good place in the docs for this? 2. If the user doesn't use the Visual Studio generator, still support embedding the manifest. For example, if I use Ninja generator in conjunction with Visual C++'s link.exe I'd like user-specified manifests to be merged with mt.exe. The second request is currently a big pain point with CMake to get working correctly. Ideally I want to reproduce the VS way of doing things, which is: a. Have link.exe generate default manifest for referencing the CRT side-by-side assemblies. b. Use mt.exe to put it all together in the output. Because CMake already does *some* things with the linker it makes it impossible for me to cleanly specify and use link.exe manifest-related switches myself. For example, it hard-codes usage of link.exe /MANIFESTFILE and the user can't specify their own location. And the locations it does use are undocumented. See Source/cmcmd.cxx and search for vs_link_exe to see what I'm talking about. (For that matter, git grep CMake for vs_link_exe and vs_link_dll to see how those commands end up getting used in the first place). Ultimately for now I wound up with this kludge to get link.exe intermediate manifest AND my own: if(CMAKE_CONFIGURATION_TYPES) # multiple-configuration generator? # WARNING: This magic directory location is an undocumented aspect of the # Visual Studio generator. list(APPEND inputManifests ${CMAKE_CURRENT_BINARY_DIR}/${AAM_TARGET}.dir/$/$.intermediate.manifest ) else() # Can't change /MANIFESTFILE because CMake assumes the default... (see above) list(APPEND inputManifests $.manifest) endif() list(APPEND inputManifests my_own_manifests.manifest) Which is then fed into add_custom_command( POST_BUILD COMMAND mt.exe -manifest ${inputManifests} ). Basically I'm hard-coding the hard-coded /MANIFESTFILE: locations used by various CMake generators, since it doesn't work for me to try to change it. Obviously the situation is not ideal because CMake makes no promises about where it puts the intermediate manifests from the linker. It would be certainly be nice if CMake supported user-provided manifests across most/all Windows generators as first-class support, not just Visual Studio 10. Especially the make-like tools (various Makefile generators, Ninja). :) Best regards, James Johnston ------------------------------------ From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Gilles Khouzam Sent: Thursday, September 10, 2015 23:25 To: Brad King Cc: cmake-developers at cmake.org Subject: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version This patch fixes the issue where on Windows 8 and above, by default the system version returned is always Windows 8. More info on this can be found on http://blogs.msdn.com/b/cjacks/archive/2009/03/27/manifesting-for-compatibil ity-on-windows-7.aspx In order for GetVersionEx to work properly, a manifest must be embedded in the exe telling it to ignore the new behavior and give the proper version. This patch adds support to specify manifests and teaches CMake how to embed them using Visual Studio. This patch adds a simple version manifest Source\cmake.version.manifest to the CMake executables. This removes the use of RtlGetVersion and properly uses GetVersionEx which will now return the proper operating system version for all operating systems until Windows 10. This patch also fixes a potential buffer overrun and improper call of GetVersionEx in SystemTools.cxx where GetVersionExW is called with a OSVERSIONINFOEXA struct causing a failure since the size is improper for the API. Fixing this, GetVersionEx should never fail anymore. Update the OSVersionAndName for new versions of Windows released after Windows 7. This change will require a double compile of CMake (I'm not sure if this is what the dashboards are doing) to have the functionality enabled, since the first step will build a new CMake that will know how to embed a manifest. The second compile with the version of CMake that knows how to embed a manifest, will then embed the manifest in CMake enabling this feature. Thanks ~Gilles From JamesJ at motionview3d.com Fri Sep 11 11:54:22 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Fri, 11 Sep 2015 15:54:22 -0000 Subject: [cmake-developers] [CMake] Visual Studio - Ninja Generator In-Reply-To: <55F04977.6040101@kitware.com> References: <55E48101.2010502@gmail.com> <053901d0e5b6$6c47ae70$44d70b50$@motionview3d.com> <55F04977.6040101@kitware.com> Message-ID: <041601d0ecaa$20dd64c0$62982e40$@motionview3d.com> > -----Original Message----- > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] > On Behalf Of Brad King > Sent: Wednesday, September 09, 2015 15:00 > To: cmake-developers at cmake.org > Subject: Re: [cmake-developers] [CMake] Visual Studio - > Ninja Generator > > On 09/02/2015 03:34 PM, James Johnston wrote: > > useful if the Visual Studio generators in CMake were refactored > > somewhat > > Even without the C# motivation I think factoring out a "MSBuild" generator > infrastructure internally will be useful. Currently we call it "VS 10" > because it happened to be the first version to use MSBuild project files. > Are you proposing to have some kind of internal object model for the > MSBuild project files to separate their construction from the actual > generation? Right, something like that. Another motivation: if somebody ever wanted to write a generator for Embarcadero C++ Builder projects... guess what format the project files are in... MSBuild... this otherwise has nothing to do with VStudio... Again, not something I'm working on right now but just putting some ideas out there. :) > > > it would be useful to have Visual Studio available as an "Extra" CMake > > generator. For example, specification of "Visual Studio 2015 - Ninja" > > This functionality sounds reasonable but the name of the extra/generator > pair looks funny when spelled out that way. We should consider having > another way to specify the extra generator. This name is consistent with the other extra generators: http://www.cmake.org/cmake/help/v3.3/manual/cmake-generators.7.html#id12 "[Extra] generator names have the form - ." But I agree it is just confusing at this point. Maybe this format could be deprecated in favor of a new cmake.exe switch to specify an extra generator. Best regards, James Johnston From paul.k.romano at gmail.com Fri Sep 11 12:08:42 2015 From: paul.k.romano at gmail.com (Paul Romano) Date: Fri, 11 Sep 2015 20:08:42 +0400 Subject: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module In-Reply-To: <55F04971.7020509@kitware.com> References: <1863012101.3782681.1441208121250.JavaMail.root@mail.gatech.edu> <55E717F7.3030902@kitware.com> <55F04971.7020509@kitware.com> Message-ID: As requested, here's a new patch with the _NAMES variables unset()-ed and documentation on the HDF5_PREFER_PARALLEL variable. Best, Paul On Wed, Sep 9, 2015 at 7:00 PM, Brad King wrote: > On 09/03/2015 05:16 AM, Paul Romano wrote: > > Brad- here's a new patch based off of 8ea7611 that uses the new > > NAMES_PER_DIR option of find_program as well adds the > HDF5_PREFER_PARALLEL > > Thanks. Please unset() the _NAMES variables when finished so that > they are not exposed publicly. Also please extend the module > documentation to mention HDF5_PREFER_PARALLEL. > > Thanks, > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindHDF5-Add-NAMES_PER_DIR-and-introduce-HDF5_PREFER.patch Type: text/x-patch Size: 3173 bytes Desc: not available URL: From roman.wueger at gmx.at Fri Sep 11 12:37:55 2015 From: roman.wueger at gmx.at (=?UTF-8?Q?Roman_W=C3=BCger?=) Date: Fri, 11 Sep 2015 18:37:55 +0200 Subject: [cmake-developers] CTest threshold exceeds 1024 bytes In-Reply-To: <55F19E34.5030309@kitware.com> References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> <55AE4EC3.8050607@kitware.com> <015401d0c402$ea609040$bf21b0c0$@gmx.at> <55AFB35D.4000004@kitware.com> <55B653C4.7090205@kitware.com> <724C2DD1-4024-47E3-91C2-DC086107735C@gmx.at> <55D5F2AB.1000600@kitware.com> <55E4A8A5.2020909@kitware.com> <55F18839.6020709@kitware.com> <6DB7FFE9-93EF-4C3E-AAE4-16DE069BA98E@gmx.at> <55F19B74.6010401@kitware.com> <45DDF6B8-89FE-4932-96E4-F71B0770E2A5@gmx.at> <897B93ED-5B09-4B21-B1D5-05CBC65BB4F6@gmx.at> <55F19E34.5030309@kitware.com> Message-ID: <01ff01d0ecb0$3695f1a0$a3c1d4e0$@gmx.at> Hello Brad, I added the required command line options, but it doesn't produce the expected output. It works in a normal environment, but not in the "CTest test case". Could you have a look at it? Best Regards Roman > -----Urspr?ngliche Nachricht----- > Von: Brad King [mailto:brad.king at kitware.com] > Gesendet: Donnerstag, 10. September 2015 17:14 > An: Roman W?ger > Cc: cmake-developers at cmake.org > Betreff: Re: [cmake-developers] CTest threshold exceeds 1024 bytes > > On 09/10/2015 11:11 AM, Roman W?ger wrote: > > I've tested it on a real world example. > > > > My problem is to add a "ctest unit test case". > > The patch I last sent earlier in this thread adds a unit test that produces and > reads the Test.xml file. I left a comment: > > # TODO: actually check the content > > as a placeholder for you to take over with the actual check. > At that point the "test_xml" variable holds the content to be checked. > > -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CTest-learned-to-limit-the-output-of-passed-and-fail.patch Type: application/octet-stream Size: 6657 bytes Desc: not available URL: From mantis at public.kitware.com Fri Sep 11 13:16:47 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 11 Sep 2015 13:16:47 -0400 Subject: [cmake-developers] [CMake 0015737]: Use of redhat-hardened-ld breaks CMake's Fortran compiler library detection for gfortran Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15737 ====================================================================== Reported By: Orion Poplawski Assigned To: ====================================================================== Project: CMake Issue ID: 15737 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2015-09-11 13:16 EDT Last Modified: 2015-09-11 13:16 EDT ====================================================================== Summary: Use of redhat-hardened-ld breaks CMake's Fortran compiler library detection for gfortran Description: Fedora is now compiling everything with hardened build options. However this is breaking CMake's fortran compiler information detection because it incorrectly picks the wrong link line: Detecting Fortran compiler ABI info compiled with the following output: Change Dir: /home/orion/fedora/psi4/psi4public-1881450f30d3bd2ac91dbc4fc6a4eaa5c9f03ae5/objdir-x86_64-redhat-linux-gnu/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/gmake" "cmTC_41086/fast" /usr/bin/gmake -f CMakeFiles/cmTC_41086.dir/build.make CMakeFiles/cmTC_41086.dir/build gmake[1]: Entering directory '/home/orion/fedora/psi4/psi4public-1881450f30d3bd2ac91dbc4fc6a4eaa5c9f03ae5/objdir-x86_64-redhat-linux-gnu/CMakeFiles/CMakeTmp' Building Fortran object CMakeFiles/cmTC_41086.dir/CMakeFortranCompilerABI.F.o /usr/bin/gfortran -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -I/usr/lib64/gfortran/modules -c /usr/share/cmake/Modules/CMakeFortranCompilerABI.F -o CMakeFiles/cmTC_41086.dir/CMakeFortranCompilerABI.F.o Linking Fortran executable cmTC_41086 /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_41086.dir/link.txt --verbose=1 /usr/bin/gfortran -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -v -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -I/usr/lib64/gfortran/modules CMakeFiles/cmTC_41086.dir/CMakeFortranCompilerABI.F.o -o cmTC_41086 -rdynamic Driving: /usr/bin/gfortran -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -v -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -I/usr/lib64/gfortran/modules CMakeFiles/cmTC_41086.dir/CMakeFortranCompilerABI.F.o -o cmTC_41086 -rdynamic -l gfortran -l m -shared-libgcc Using built-in specs. Reading specs from /usr/lib/rpm/redhat/redhat-hardened-ld Reading specs from /usr/lib/rpm/redhat/redhat-hardened-cc1 COLLECT_GCC=/usr/bin/gfortran COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC) Reading specs from /usr/lib/gcc/x86_64-redhat-linux/5.1.1/libgfortran.spec rename spec lib to liborig COLLECT_GCC_OPTIONS='-specs=/usr/lib/rpm/redhat/redhat-hardened-ld' '-v' '-O2' '-g' '-pipe' '-Wall' '-Werror=format-security' '-fexceptions' '-fstack-protector-strong' '--param' 'ssp-buffer-size=4' '-grecord-gcc-switches' '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' '-m64' '-mtune=generic' '-I' '/usr/lib64/gfortran/modules' '-o' 'cmTC_41086' '-rdynamic' '-shared-libgcc' '-march=x86-64' '-pie' COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/:/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/5.1.1/:/usr/lib/gcc/x86_64-redhat-linux/ LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/5.1.1/:/usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-specs=/usr/lib/rpm/redhat/redhat-hardened-ld' '-v' '-O2' '-g' '-pipe' '-Wall' '-Werror=format-security' '-fexceptions' '-fstack-protector-strong' '--param' 'ssp-buffer-size=4' '-grecord-gcc-switches' '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' '-m64' '-mtune=generic' '-I' '/usr/lib64/gfortran/modules' '-o' 'cmTC_41086' '-rdynamic' '-shared-libgcc' '-march=x86-64' '-pie' /usr/libexec/gcc/x86_64-redhat-linux/5.1.1/collect2 -plugin /usr/libexec/gcc/x86_64-redhat-linux/5.1.1/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper -plugin-opt=-fresolution=/tmp/ccNzxFD8.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lquadmath -plugin-opt=-pass-through=-lm -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -export-dynamic -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z now -pie -o cmTC_41086 /usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/Scrt1.o /usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/5.1.1/crtbeginS.o -L/usr/lib/gcc/x86_64-redhat-linux/5.1.1 -L/usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../.. -z relro CMakeFiles/cmTC_41086.dir/CMakeFortranCompilerABI.F.o -lgfortran -lm -lgcc_s -lgcc -lquadmath -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-redhat-linux/5.1.1/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/crtn.o gmake[1]: Leaving directory '/home/orion/fedora/psi4/psi4public-1881450f30d3bd2ac91dbc4fc6a4eaa5c9f03ae5/objdir-x86_64-redhat-linux-gnu/CMakeFiles/CMakeTmp' Parsed Fortran implicit link information from above output: link line regex: [^( *|.*[/\])(ld|([^/\]+-)?ld|collect2)[^/\]*( |$)] ignore line: [Change Dir: /home/orion/fedora/psi4/psi4public-1881450f30d3bd2ac91dbc4fc6a4eaa5c9f03ae5/objdir-x86_64-redhat-linux-gnu/CMakeFiles/CMakeTmp] ignore line: [] ignore line: [Run Build Command:"/usr/bin/gmake" "cmTC_41086/fast"] ignore line: [/usr/bin/gmake -f CMakeFiles/cmTC_41086.dir/build.make CMakeFiles/cmTC_41086.dir/build] ignore line: [gmake[1]: Entering directory '/home/orion/fedora/psi4/psi4public-1881450f30d3bd2ac91dbc4fc6a4eaa5c9f03ae5/objdir-x86_64-redhat-linux-gnu/CMakeFiles/CMakeTmp'] ignore line: [Building Fortran object CMakeFiles/cmTC_41086.dir/CMakeFortranCompilerABI.F.o] ignore line: [/usr/bin/gfortran -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -I/usr/lib64/gfortran/modules -c /usr/share/cmake/Modules/CMakeFortranCompilerABI.F -o CMakeFiles/cmTC_41086.dir/CMakeFortranCompilerABI.F.o] ignore line: [Linking Fortran executable cmTC_41086] ignore line: [/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_41086.dir/link.txt --verbose=1] ignore line: [/usr/bin/gfortran -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -v -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -I/usr/lib64/gfortran/modules CMakeFiles/cmTC_41086.dir/CMakeFortranCompilerABI.F.o -o cmTC_41086 -rdynamic ] ignore line: [Driving: /usr/bin/gfortran -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -v -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -I/usr/lib64/gfortran/modules CMakeFiles/cmTC_41086.dir/CMakeFortranCompilerABI.F.o -o cmTC_41086 -rdynamic -l gfortran -l m -shared-libgcc] ignore line: [Using built-in specs.] ignore line: [Reading specs from /usr/lib/rpm/redhat/redhat-hardened-ld] ignore line: [Reading specs from /usr/lib/rpm/redhat/redhat-hardened-cc1] ignore line: [COLLECT_GCC=/usr/bin/gfortran] ignore line: [COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper] ignore line: [Target: x86_64-redhat-linux] ignore line: [Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux] ignore line: [Thread model: posix] ignore line: [gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC) ] ignore line: [Reading specs from /usr/lib/gcc/x86_64-redhat-linux/5.1.1/libgfortran.spec] ignore line: [rename spec lib to liborig] link line: [COLLECT_GCC_OPTIONS='-specs=/usr/lib/rpm/redhat/redhat-hardened-ld' '-v' '-O2' '-g' '-pipe' '-Wall' '-Werror=format-security' '-fexceptions' '-fstack-protector-strong' '--param' 'ssp-buffer-size=4' '-grecord-gcc-switches' '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' '-m64' '-mtune=generic' '-I' '/usr/lib64/gfortran/modules' '-o' 'cmTC_41086' '-rdynamic' '-shared-libgcc' '-march=x86-64' '-pie'] arg [COLLECT_GCC_OPTIONS=-specs=/usr/lib/rpm/redhat/redhat-hardened-ld] ==> ignore arg [-v] ==> ignore arg [-O2] ==> ignore arg [-g] ==> ignore arg [-pipe] ==> ignore arg [-Wall] ==> ignore arg [-Werror=format-security] ==> ignore arg [-fexceptions] ==> ignore arg [-fstack-protector-strong] ==> ignore arg [--param] ==> ignore arg [ssp-buffer-size=4] ==> ignore arg [-grecord-gcc-switches] ==> ignore arg [-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1] ==> ignore arg [-m64] ==> ignore arg [-mtune=generic] ==> ignore arg [-I] ==> ignore arg [/usr/lib64/gfortran/modules] ==> ignore arg [-o] ==> ignore arg [cmTC_41086] ==> ignore arg [-rdynamic] ==> ignore arg [-shared-libgcc] ==> ignore arg [-march=x86-64] ==> ignore arg [-pie] ==> ignore implicit libs: [] implicit dirs: [] implicit fwks: [] Steps to Reproduce: Compile with LDFLAGS='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' Additional Information: https://bugzilla.redhat.com/show_bug.cgi?id=1260490 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-11 13:16 Orion PoplawskiNew Issue ====================================================================== From brad.king at kitware.com Fri Sep 11 13:58:21 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 11 Sep 2015 13:58:21 -0400 Subject: [cmake-developers] CTest threshold exceeds 1024 bytes In-Reply-To: <01ff01d0ecb0$3695f1a0$a3c1d4e0$@gmx.at> References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> <55AE4EC3.8050607@kitware.com> <015401d0c402$ea609040$bf21b0c0$@gmx.at> <55AFB35D.4000004@kitware.com> <55B653C4.7090205@kitware.com> <724C2DD1-4024-47E3-91C2-DC086107735C@gmx.at> <55D5F2AB.1000600@kitware.com> <55E4A8A5.2020909@kitware.com> <55F18839.6020709@kitware.com> <6DB7FFE9-93EF-4C3E-AAE4-16DE069BA98E@gmx.at> <55F19B74.6010401@kitware.com> <45DDF6B8-89FE-4932-96E4-F71B0770E2A5@gmx.at> <897B93ED-5B09-4B21-B1D5-05CBC65BB4F6@gmx.at> <55F19E34.5030309@kitware.com> <01ff01d0ecb0$3695f1a0$a3c1d4e0$@gmx.at> Message-ID: <55F3163D.4090303@kitware.com> On 09/11/2015 12:37 PM, Roman W?ger wrote: > It works in a normal environment, but not in the "CTest test case". > Could you have a look at it? No, sorry. You're implementing this feature so it is up to you to debug and get it working. -Brad From brad.king at kitware.com Fri Sep 11 14:09:44 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 11 Sep 2015 14:09:44 -0400 Subject: [cmake-developers] CMake user-provided manifest files (was: Windows: Correctly determine Windows version) In-Reply-To: <041501d0eca8$e8cdb2c0$ba691840$@motionview3d.com> References: <041501d0eca8$e8cdb2c0$ba691840$@motionview3d.com> Message-ID: <55F318E8.8060603@kitware.com> On 09/11/2015 11:45 AM, James Johnston wrote: > The second request is currently a big pain point with CMake to get working > correctly. Ideally I want to reproduce the VS way of doing things, which > is: > > a. Have link.exe generate default manifest for referencing the CRT > side-by-side assemblies. > b. Use mt.exe to put it all together in the output. > > See Source/cmcmd.cxx and search for vs_link_exe to see what I'm talking about. [snip] > It would be certainly be nice if CMake supported user-provided manifests > across most/all Windows generators as first-class support, not just Visual > Studio 10. Especially the make-like tools (various Makefile generators, > Ninja). :) I would be very happy to get rid of the vs_link_exe and vs_link_dll code. The source is full of comments about why it is there (incremental linking). If someone can get an alternative approach working that also supports user-provided .manifest files I would be happy to review it. Actually I think this should be done before the Windows 10 support can be integrated. We need to make sure that when a .manifest file is added to the list of sources for an exe or dll target that we can properly honor it in all generators. Otherwise adding support for non-VS generators later will be a behavior change. Also we need to make sure the semantics of specifying manifest sources works everywhere. -Brad From brad.king at kitware.com Fri Sep 11 14:15:01 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 11 Sep 2015 14:15:01 -0400 Subject: [cmake-developers] Odd behaviour in VS14 (Visual studio 2015) In-Reply-To: <50320452A334BD42A5EC72BAD21450993C7FD9C4@MBX110.d.ethz.ch> References: <50320452A334BD42A5EC72BAD21450993C7FD9C4@MBX110.d.ethz.ch> Message-ID: <55F31A25.7020904@kitware.com> On 09/11/2015 08:38 AM, Biddiscombe, John A. wrote: > I have been having problems with projects in VS14 and it appears > to be caused by the generation of paths used by/in the IDE > > D:\Code\hvtkm\vtkm\vtkm/worklet/GaussianSplatter.h > > whereas it used to always be > > D:\Code\hvtkm\vtkm\vtkm\worklet\GaussianSplatter.h Please provide a minimal test project that shows this behavior. Also please show a snippet of the .vcxproj content that has such slashes. Thanks, -Brad From brad.king at kitware.com Fri Sep 11 14:29:05 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 11 Sep 2015 14:29:05 -0400 Subject: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module In-Reply-To: References: <1863012101.3782681.1441208121250.JavaMail.root@mail.gatech.edu> <55E717F7.3030902@kitware.com> <55F04971.7020509@kitware.com> Message-ID: <55F31D71.9060506@kitware.com> On 09/11/2015 12:08 PM, Paul Romano wrote: > As requested, here's a new patch with the _NAMES variables unset()-ed > and documentation on the HDF5_PREFER_PARALLEL variable. Thanks. Applied and merged to 'next' for testing: FindHDF5: Add NAMES_PER_DIR and introduce HDF5_PREFER_PARALLEL http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fd26a19a I modified the wording of the documentation slightly. Please check it. -Brad From brad.king at kitware.com Fri Sep 11 14:33:18 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 11 Sep 2015 14:33:18 -0400 Subject: [cmake-developers] Python extension to FindProtobuf In-Reply-To: <6B1070FD3B25C348BB7E9CD29C1F16D137E70DF0@flexchange.home.fishlabs.net> References: <6B1070FD3B25C348BB7E9CD29C1F16D137E70DCE@flexchange.home.fishlabs.net> <1727564.SG6oXUDnmz@caliban.sf-tec.de> <6B1070FD3B25C348BB7E9CD29C1F16D137E70DF0@flexchange.home.fishlabs.net> Message-ID: <55F31E6E.4010508@kitware.com> On 09/11/2015 11:11 AM, Andreas Bergmeier wrote: > Here is the commit. Thanks. Please revise the patch to also update the documentation of the module to mention the new API. > + list(APPEND ${SRCS} "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.py") > + add_custom_command( > + OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.py" > + COMMAND ${PROTOBUF_PROTOC_EXECUTABLE} > + ARGS --python_out ${CMAKE_CURRENT_BINARY_DIR} ${_protobuf_include_path} ${ABS_FIL} The ARGS option can be dropped. It is silently ignored anyway. The arguments after it will be collected by COMMAND already. > + DEPENDS ${ABS_FIL} ${PROTOBUF_PROTOC_EXECUTABLE} > + COMMENT "Running Python protocol buffer compiler on ${FIL}" > + VERBATIM ) > + endforeach() > + > + set_source_files_properties(${${SRCS}} PROPERTIES GENERATED TRUE) We do not need to explicitly set the GENERATED property. That convention has been outdated for years. The add_custom_command call automatically sets this on the OUTPUT. Thanks, -Brad From brad.king at kitware.com Fri Sep 11 15:02:56 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 11 Sep 2015 15:02:56 -0400 Subject: [cmake-developers] CMake user-provided manifest files In-Reply-To: <55F318E8.8060603@kitware.com> References: <041501d0eca8$e8cdb2c0$ba691840$@motionview3d.com> <55F318E8.8060603@kitware.com> Message-ID: <55F32560.90608@kitware.com> On 09/11/2015 02:09 PM, Brad King wrote: > I would be very happy to get rid of the vs_link_exe and vs_link_dll code. > The source is full of comments about why it is there (incremental linking). > If someone can get an alternative approach working that also supports > user-provided .manifest files I would be happy to review it. There is documentation here about what those are doing: https://msdn.microsoft.com/en-us/library/ms235591.aspx http://blogs.msdn.com/b/zakramer/archive/2006/05/22/603558.aspx IIRC vs_link_{exe,dll} is needed to implement these steps due to all the conditions that decide which parts are needed. MSBuild must have something similar in its own build rules to achieve incremental linking with embedded manifests. Perhaps vs_link_{exe,dll} can be updated to handle user-provided manifest files. > Actually I think this should be done before the Windows 10 support can > be integrated. We need to make sure that when a .manifest file is added > to the list of sources for an exe or dll target that we can properly > honor it in all generators. Otherwise adding support for non-VS generators > later will be a behavior change. Also we need to make sure the semantics > of specifying manifest sources works everywhere. This needs to be resolved for proper Windows 10 support to be integrated since that needs user-provided manifest files to work. -Brad From domen.vrankar at gmail.com Fri Sep 11 15:34:24 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Fri, 11 Sep 2015 21:34:24 +0200 Subject: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive In-Reply-To: References: Message-ID: > I have made the following changes in order to: > - support the UID/GID/UNAME/GNAME and permission on tar files at creation > time > - using directly libarchive in CPackDeb > - removing completely the need of fakeroot Applied to next for testing: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=2e9af45 I've fixed permission mask code in patch 2 and 3. Please confirm that it works OK in your environment. I've also removed permission mask setting for directories and files as I am not certain that it belongs there - it wasn't there before and user can always change permissions with install command. Issue with default permissions being 775 is system default related and occurs only with directories that are automatically created - directories created with install command get permission 755 which is acceptable for deb packages. I believe that this inconsistency should be fixed elsewhere by adding possibility to set global default directory permissions. > Is it on time for 3.4 freeze? Feature freeze was announced for Oct, 1 so it should make it in 3.4 Regards, Domen From raffi.enficiaud at mines-paris.org Fri Sep 11 17:25:16 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Fri, 11 Sep 2015 23:25:16 +0200 Subject: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive In-Reply-To: References: Message-ID: Le 11/09/15 21:34, Domen Vrankar a ?crit : >> I have made the following changes in order to: >> - support the UID/GID/UNAME/GNAME and permission on tar files at creation >> time >> - using directly libarchive in CPackDeb >> - removing completely the need of fakeroot > > Applied to next for testing: > http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=2e9af45 Many thanks, Domen! > > I've fixed permission mask code in patch 2 and 3. Please confirm that > it works OK in your environment. Should do, I will monitor the test this week end. > > I've also removed permission mask setting for directories and files as > I am not certain that it belongs there - it wasn't there before and > user can always change permissions with install command. Issue with > default permissions being 775 is system default related and occurs > only with directories that are automatically created - directories > created with install command get permission 755 which is acceptable > for deb packages. > I believe that this inconsistency should be fixed elsewhere by adding > possibility to set global default directory permissions. > You're right, files in data.tar.xx should not have their permission changed from the install command, and having uid/gid root/root should not be any different from the behaviour we have now with fakeroot. So I am perfectly fine with your changes, thank you! >> Is it on time for 3.4 freeze? > > Feature freeze was announced for Oct, 1 so it should make it in 3.4 Good! Cheers, Raffi From biddisco at cscs.ch Fri Sep 11 18:21:49 2015 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Fri, 11 Sep 2015 22:21:49 +0000 Subject: [cmake-developers] Odd behaviour in VS14 (Visual studio 2015) In-Reply-To: <55F31A25.7020904@kitware.com> References: <50320452A334BD42A5EC72BAD21450993C7FD9C4@MBX110.d.ethz.ch> <55F31A25.7020904@kitware.com> Message-ID: Brad, I had a look at the .vcxproj files and there is no trace of odd paths in there. I realise now that I have #include statements of the kind #include And clearly it is VS that is appending these unixy paths to the (correct) cmake generated path prefix for the project etc. It appears to be a VS problem rather than a cmake one. I will investigate elsewhere. Thanks for the suggestion and sorry for the noise. JB On 11/09/15 20:15, "Brad King" wrote: >On 09/11/2015 08:38 AM, Biddiscombe, John A. wrote: >> I have been having problems with projects in VS14 and it appears >> to be caused by the generation of paths used by/in the IDE >> >> D:\Code\hvtkm\vtkm\vtkm/worklet/GaussianSplatter.h >> >> whereas it used to always be >> >> D:\Code\hvtkm\vtkm\vtkm\worklet\GaussianSplatter.h > >Please provide a minimal test project that shows this behavior. >Also please show a snippet of the .vcxproj content that has >such slashes. > >Thanks, >-Brad > From joerg at britannica.bec.de Sat Sep 12 11:03:20 2015 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Sat, 12 Sep 2015 17:03:20 +0200 Subject: [cmake-developers] Portability patches / bug fixes Message-ID: <20150912150320.GB306@britannica.bec.de> Hi all, attached are three patches for cmake. The first two should be trivial and self-explaining. The third is a more involved change for ccmake. At the moment, the form widget logic uses internal variables of the ncurses implementation of form.h. There is at least one other implementation which works different (in NetBSD). It seems to work as intended with both ncurses and NetBSD's libform. Joerg -------------- next part -------------- >From ab83e103438b284335baec76037a8b69a6394a30 Mon Sep 17 00:00:00 2001 From: Joerg Sonnenberger Date: Sat, 12 Sep 2015 16:34:12 +0200 Subject: [PATCH 1/3] In C99 mode, Solaris variants may already define isfinite, so check for the existance first. --- Utilities/cmjsoncpp/src/lib_json/json_writer.cpp | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Utilities/cmjsoncpp/src/lib_json/json_writer.cpp b/Utilities/cmjsoncpp/src/lib_json/json_writer.cpp index b64cdb0..e3f4e53 100644 --- a/Utilities/cmjsoncpp/src/lib_json/json_writer.cpp +++ b/Utilities/cmjsoncpp/src/lib_json/json_writer.cpp @@ -24,7 +24,9 @@ // Solaris #if defined(__sun) # include -# define isfinite finite +# if !defined(isfinite) +# define isfinite finite +# endif #endif // AIX -- 1.9.1 -------------- next part -------------- >From 10eb3b7fbee75a3a97f732e314fba193f64931e1 Mon Sep 17 00:00:00 2001 From: Joerg Sonnenberger Date: Sat, 12 Sep 2015 16:35:36 +0200 Subject: [PATCH 2/3] printw takes a format string as first argument, so don't pass variable strings to it directly. --- Source/CursesDialog/cmCursesLongMessageForm.cxx | 6 +++--- Source/CursesDialog/cmCursesMainForm.cxx | 15 +++++++-------- Source/CursesDialog/cmCursesStringWidget.cxx | 11 +++++------ 3 files changed, 15 insertions(+), 17 deletions(-) diff --git a/Source/CursesDialog/cmCursesLongMessageForm.cxx b/Source/CursesDialog/cmCursesLongMessageForm.cxx index 67e4aab..2e5e322 100644 --- a/Source/CursesDialog/cmCursesLongMessageForm.cxx +++ b/Source/CursesDialog/cmCursesLongMessageForm.cxx @@ -82,10 +82,10 @@ void cmCursesLongMessageForm::UpdateStatusBar() curses_move(y-4,0); attron(A_STANDOUT); - printw(bar); + printw("%s", bar); attroff(A_STANDOUT); curses_move(y-3,0); - printw(version); + printw("%s", version); pos_form_cursor(this->Form); } @@ -102,7 +102,7 @@ void cmCursesLongMessageForm::PrintKeys() sprintf(firstLine, "Press [e] to exit help"); curses_move(y-2,0); - printw(firstLine); + printw("%s", firstLine); pos_form_cursor(this->Form); } diff --git a/Source/CursesDialog/cmCursesMainForm.cxx b/Source/CursesDialog/cmCursesMainForm.cxx index be17a9f..d3a84d3 100644 --- a/Source/CursesDialog/cmCursesMainForm.cxx +++ b/Source/CursesDialog/cmCursesMainForm.cxx @@ -456,19 +456,19 @@ void cmCursesMainForm::PrintKeys(int process /* = 0 */) { strcpy(fmt, " "); } - printw(fmt); + printw("%s", fmt); curses_move(y-3,0); - printw(firstLine); + printw("%s", firstLine); curses_move(y-2,0); - printw(secondLine); + printw("%s", secondLine); curses_move(y-1,0); - printw(thirdLine); + printw("%s", thirdLine); if (cw) { sprintf(firstLine, "Page %d of %d", cw->GetPage(), this->NumberOfPages); curses_move(0,65-static_cast(strlen(firstLine))-1); - printw(firstLine); + printw("%s", firstLine); } // } @@ -614,11 +614,10 @@ void cmCursesMainForm::UpdateStatusBar(const char* message) // Now print both lines curses_move(y-5,0); attron(A_STANDOUT); - char format[] = "%s"; - printw(format, bar); + printw("%s", bar); attroff(A_STANDOUT); curses_move(y-4,0); - printw(version); + printw("%s", version); pos_form_cursor(this->Form); } diff --git a/Source/CursesDialog/cmCursesStringWidget.cxx b/Source/CursesDialog/cmCursesStringWidget.cxx index acf262f..1fe0945 100644 --- a/Source/CursesDialog/cmCursesStringWidget.cxx +++ b/Source/CursesDialog/cmCursesStringWidget.cxx @@ -229,17 +229,16 @@ bool cmCursesStringWidget::PrintKeys() } firstLine[511] = '\0'; curses_move(y-4,0); - printw(firstLine); + printw("%s", firstLine); curses_move(y-3,0); - printw(firstLine); + printw("%s", firstLine); curses_move(y-2,0); - printw(firstLine); + printw("%s", firstLine); curses_move(y-1,0); - printw(firstLine); + printw("%s", firstLine); - sprintf(firstLine, "Editing option, press [enter] to leave edit."); curses_move(y-3,0); - printw(firstLine); + printw("Editing option, press [enter] to leave edit."); return true; } else -- 1.9.1 -------------- next part -------------- >From a0479b89439b8de5e1c900a9e9482ebf5638c23e Mon Sep 17 00:00:00 2001 From: Joerg Sonnenberger Date: Sat, 12 Sep 2015 16:37:35 +0200 Subject: [PATCH 3/3] curcol is an implementation detail of ncurses, other form implementation may not have it. The switch-to-previous-field logic only exists for overloaded requests of REQ_DEL_PREV, so no need to check for REQ_DEL_CHAR. For REQ_DEL_PREV, check if the field changed and if it did, change it back. --- Source/CursesDialog/cmCursesStringWidget.cxx | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/Source/CursesDialog/cmCursesStringWidget.cxx b/Source/CursesDialog/cmCursesStringWidget.cxx index 1fe0945..8be2aa0 100644 --- a/Source/CursesDialog/cmCursesStringWidget.cxx +++ b/Source/CursesDialog/cmCursesStringWidget.cxx @@ -168,17 +168,16 @@ bool cmCursesStringWidget::HandleInput(int& key, cmCursesMainForm* fm, else if ( key == 127 || key == KEY_BACKSPACE ) { - if ( form->curcol > 0 ) - { + FIELD *cur = current_field(form); form_driver(form, REQ_DEL_PREV); - } + if (current_field(form) != cur) + { + set_current_field(form, cur); + } } else if ( key == ctrl('d') ||key == KEY_DC ) { - if ( form->curcol >= 0 ) - { - form_driver(form, REQ_DEL_CHAR); - } + form_driver(form, REQ_DEL_CHAR); } else { -- 1.9.1 From mantis at public.kitware.com Sat Sep 12 12:37:11 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 12 Sep 2015 12:37:11 -0400 Subject: [cmake-developers] [CMake 0015738]: printw() should use format string Message-ID: <98ebd81a3c168287ded7c014367b6acc@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15738 ====================================================================== Reported By: Thomas Klausner Assigned To: ====================================================================== Project: CMake Issue ID: 15738 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-12 12:37 EDT Last Modified: 2015-09-12 12:37 EDT ====================================================================== Summary: printw() should use format string Description: Multiple files (in Source/CursesDialog/*.cxx) use the printw() function without a format string, i.e. printw(some_variable); This is unsafe; if some_variable contains "%s" or similar, you have problems. Please use the printw("%s", some_variable); idiom instead. Steps to Reproduce: Code inspection. Additional Information: The attached patch fixes this issue. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-12 12:37 Thomas KlausnerNew Issue 2015-09-12 12:37 Thomas KlausnerFile Added: printw.diff ====================================================================== From mantis at public.kitware.com Sat Sep 12 12:40:22 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 12 Sep 2015 12:40:22 -0400 Subject: [cmake-developers] [CMake 0015739]: NetBSD: curses compatibility Message-ID: <9a2b947101d7ecd77100780c26e9af5d@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15739 ====================================================================== Reported By: Thomas Klausner Assigned To: ====================================================================== Project: CMake Issue ID: 15739 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-12 12:40 EDT Last Modified: 2015-09-12 12:40 EDT ====================================================================== Summary: NetBSD: curses compatibility Description: cmake uses ncurses internals to handle a borderline case. This fails to build with NetBSD's curses. Steps to Reproduce: Build on NetBSD with the native curses library. Additional Information: The attached patch doesn't use implemention-details of ncurses to see if the overloading behavior of REQ_DEL_PREV is active, just undos any damage it may have done. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-12 12:40 Thomas KlausnerNew Issue 2015-09-12 12:40 Thomas KlausnerFile Added: patch-Source_CursesDialog_cmCursesStringWidget.cxx ====================================================================== From mantis at public.kitware.com Sat Sep 12 12:45:47 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 12 Sep 2015 12:45:47 -0400 Subject: [cmake-developers] [CMake 0015740]: NetBSD: curses compatibility Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15740 ====================================================================== Reported By: Thomas Klausner Assigned To: ====================================================================== Project: CMake Issue ID: 15740 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-12 12:45 EDT Last Modified: 2015-09-12 12:45 EDT ====================================================================== Summary: NetBSD: curses compatibility Description: set_field_buffer on NetBSD, see http://netbsd.gw.com/cgi-bin/man-cgi?set_field_buffer++NetBSD-current, and Solaris, see https://docs.oracle.com/cd/E36784_01/html/E36880/set-field-buffer-3curses.html, has as third argument "char *" while ncurses has "const char *". I don't know if one is more correct than the other. Steps to Reproduce: Build on NetBSD (or presumably on Solaris). Additional Information: The attached patch casts the const away to fix the build on NetBSD. I think this shouldn't cause trouble with ncurses, but let me know if it does. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-12 12:45 Thomas KlausnerNew Issue 2015-09-12 12:45 Thomas KlausnerFile Added: patch-Source_CursesDialog_cmCursesWidget.cxx ====================================================================== From michael.scott250 at gmail.com Sat Sep 12 17:48:48 2015 From: michael.scott250 at gmail.com (Michael Scott) Date: Sat, 12 Sep 2015 22:48:48 +0100 Subject: [cmake-developers] Allow ALIAS of IMPORTED targets Message-ID: <55F49DC0.5090300@gmail.com> Hi, I'm planning on having a look at the CMake issue "Allow ALIAS of IMPORTED targets", 0015569. After reading the thread between yourself and Marc, I wanted to ask a couple of things before I start going further with it. The proposed change would be for the add_library and add_executable commands only right? Having a quick look at the code for those two commands, they specifically check for a combination of ALIAS and IMPORTED and don't allow it. I'm guessing that the required changes to allow both simultaneously wouldn't be to just remove this check, there would be other areas to modify as well right? Cheers, Michael From mantis at public.kitware.com Sun Sep 13 14:14:27 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 13 Sep 2015 14:14:27 -0400 Subject: [cmake-developers] [CMake 0015741]: GCC < 4.9 does not have full C11 support Message-ID: <33b592c880e0650d8991eaab7cd6790b@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15741 ====================================================================== Reported By: Raphael Kubo da Costa Assigned To: ====================================================================== Project: CMake Issue ID: 15741 Category: CMake Reproducibility: N/A Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-13 14:14 EDT Last Modified: 2015-09-13 14:14 EDT ====================================================================== Summary: GCC < 4.9 does not have full C11 support Description: As of version 3.3.1, CMake sets CMAKE_C11_{STANDARD,EXTENSION}_COMPILE_OPTION for GCC >= 4.7, and checks for C11 features for GCC >= 4.6. Additionally, it means CMake itself will be built with -std=gnu11 if GCC >= 4.7 is used. However, GCC only has full C11 support with the 4.9 release (https://gcc.gnu.org/wiki/C11Status). Specifically, support for C11's _Thread_local is only present on GCC >= 4.9. This combination makes CMake fail to build with GCC 4.7 and 4.8 on FreeBSD, as runetype.h uses _Thread_local and the fact that -std=gnu11 is passed makes it not be a typedef or define for something else that would work. In https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066, it was argued that this is GCC's fault for advertising C11 support in 4.7 and 4.8 before it was fully ready. Before sending a patch to GNU-C.cmake, I'd like to check if it makes sense or what the best approach would be. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-13 14:14 Raphael Kubo da CostaNew Issue ====================================================================== From marc.chevrier at sap.com Mon Sep 14 03:02:15 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Mon, 14 Sep 2015 07:02:15 +0000 Subject: [cmake-developers] Allow ALIAS of IMPORTED targets In-Reply-To: <55F49DC0.5090300@gmail.com> References: <55F49DC0.5090300@gmail.com> Message-ID: <60C63565-4414-410A-8D3B-2943340D8DFC@sap.com> Hi Michael, If this feature can be supported for libraries and executables, it will be perfect for me. Thank you. Marc On 12/09/15 23:48, "cmake-developers on behalf of Michael Scott" wrote: >Hi, > >I'm planning on having a look at the CMake issue "Allow ALIAS of >IMPORTED targets", 0015569. After reading the thread between yourself >and Marc, I wanted to ask a couple of things before I start going >further with it. > >The proposed change would be for the add_library and add_executable >commands only right? > >Having a quick look at the code for those two commands, they >specifically check for a combination of ALIAS and IMPORTED and don't >allow it. I'm guessing that the required changes to allow both >simultaneously wouldn't be to just remove this check, there would be >other areas to modify as well right? > >Cheers, >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 marc.chevrier at sap.com Mon Sep 14 03:05:02 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Mon, 14 Sep 2015 07:05:02 +0000 Subject: [cmake-developers] find_program HINTS no longer preferred over PATH In-Reply-To: <55F07851.7070006@kitware.com> References: <55E6F28E.1080706@kitware.com> <7F62CA7F-33C7-4D39-BA2C-D3D5669973B1@sap.com> <55E71955.1070603@kitware.com> <2A8C1310-D3AA-404A-88A3-5298D04A35AC@sap.com> <55F049E7.7080903@kitware.com> <55F07851.7070006@kitware.com> Message-ID: Any news on this subject? I think it is a critical bug because behaviour is broken. So I cannot rely on find_executable anymore to get the expected program! Marc On 09/09/15 20:20, "Brad King" wrote: >On 09/09/2015 11:50 AM, Chuck Atkins wrote: >> From what I can tell, the search order is still preserved as expected. > >The example Marc attached earlier shows that the problem is when >ENV{PATH} contains one of the *same* values that is one of the HINTS. >The fact that a path appears in ENV{PATH} somehow causes it to be >dropped from the list of HINTS or otherwise ordered after the other >hints. > >-Brad > From a.bergmeier at dsfishlabs.com Mon Sep 14 03:42:59 2015 From: a.bergmeier at dsfishlabs.com (Andreas Bergmeier) Date: Mon, 14 Sep 2015 07:42:59 +0000 Subject: [cmake-developers] Python extension to FindProtobuf In-Reply-To: <55F31E6E.4010508@kitware.com> References: <6B1070FD3B25C348BB7E9CD29C1F16D137E70DCE@flexchange.home.fishlabs.net> <1727564.SG6oXUDnmz@caliban.sf-tec.de> <6B1070FD3B25C348BB7E9CD29C1F16D137E70DF0@flexchange.home.fishlabs.net> <55F31E6E.4010508@kitware.com> Message-ID: <6B1070FD3B25C348BB7E9CD29C1F16D137E7BC63@flexchange.home.fishlabs.net> I now added documentation, removed ARGS and GENERATED property. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Freitag, 11. September 2015 20:33 To: Andreas Bergmeier Cc: Rolf Eike Beer; cmake-developers at cmake.org Subject: Re: [cmake-developers] Python extension to FindProtobuf On 09/11/2015 11:11 AM, Andreas Bergmeier wrote: > Here is the commit. Thanks. Please revise the patch to also update the documentation of the module to mention the new API. > + list(APPEND ${SRCS} "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.py") > + add_custom_command( > + OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.py" > + COMMAND ${PROTOBUF_PROTOC_EXECUTABLE} > + ARGS --python_out ${CMAKE_CURRENT_BINARY_DIR} > + ${_protobuf_include_path} ${ABS_FIL} The ARGS option can be dropped. It is silently ignored anyway. The arguments after it will be collected by COMMAND already. > + DEPENDS ${ABS_FIL} ${PROTOBUF_PROTOC_EXECUTABLE} > + COMMENT "Running Python protocol buffer compiler on ${FIL}" > + VERBATIM ) > + endforeach() > + > + set_source_files_properties(${${SRCS}} PROPERTIES GENERATED TRUE) We do not need to explicitly set the GENERATED property. That convention has been outdated for years. The add_custom_command call automatically sets this on the OUTPUT. Thanks, -Brad ________________________________ Diese E-mail enth?lt VERTRAULICHE UND PERS?NLICHE INFORMATIONEN und/oder PRIVILEGIERTE UND VERTRAULICHE MITTEILUNGEN, die ausschlie?lich f?r die angesprochenen Empf?nger bestimmt sind. Ohne ausdr?ckliche schriftliche Zustimmung des Absenders d?rfen diese Informationen und Mitteilungen nicht an irgendeinen Dritten au?erhalb der Organisation des Empf?ngers weitergeleitet oder zur Kenntnis gebracht werden. Wenn Sie diese E-mail versehentlich empfangen haben, teilen Sie dies bitte dem Absender umgehend telefonisch oder durch R?cksendung dieser E-mail mit, und zerst?ren Sie die Mail sowie Ihre evtl. R?ckmail bitte anschlie?end, ohne eine Kopie zu erstellen. Koch Media ?bernimmt keinerlei Verantwortung f?r m?gliche Verluste oder Besch?digungen, resultierend aus virus-infizierten E-mails bzw. Viren in Anh?ngen. This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Koch Media accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. -------------- next part -------------- A non-text attachment was scrubbed... Name: commit-226ffb3 Type: application/octet-stream Size: 3608 bytes Desc: commit-226ffb3 URL: From raffi.enficiaud at mines-paris.org Mon Sep 14 05:51:34 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Mon, 14 Sep 2015 11:51:34 +0200 Subject: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive In-Reply-To: References: Message-ID: Hi Brad and Domen and others, I just realized that the permissions for the extra control files should be set in a different way than for the md5sum checksum file. Please find attached the patch correcting this and the corresponding test that fires the problem. Best, Raffi PS.: I want to push it directly to stage/cpack-deb-fakeroot-removal but I have a permission issue. Le 11/09/15 21:34, Domen Vrankar a ?crit : >> I have made the following changes in order to: >> - support the UID/GID/UNAME/GNAME and permission on tar files at creation >> time >> - using directly libarchive in CPackDeb >> - removing completely the need of fakeroot > > Applied to next for testing: > http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=2e9af45 > > I've fixed permission mask code in patch 2 and 3. Please confirm that > it works OK in your environment. > > I've also removed permission mask setting for directories and files as > I am not certain that it belongs there - it wasn't there before and > user can always change permissions with install command. Issue with > default permissions being 775 is system default related and occurs > only with directories that are automatically created - directories > created with install command get permission 755 which is acceptable > for deb packages. > I believe that this inconsistency should be fixed elsewhere by adding > possibility to set global default directory permissions. > >> Is it on time for 3.4 freeze? > > Feature freeze was announced for Oct, 1 so it should make it in 3.4 > > Regards, > Domen > From raffi.enficiaud at mines-paris.org Mon Sep 14 08:52:59 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Mon, 14 Sep 2015 14:52:59 +0200 Subject: [cmake-developers] [CPackDeb] use of internal md5sum function Message-ID: Hi Brad and Domen and others, Please find attached a patch on CPackDeb - which calls the internal function for md5sum computation - which prevents the hash of the symlinks I believe this fixes the issue (partially or totally) https://public.kitware.com/Bug/view.php?id=13386 It is based on my previous patch. Thanks, Raffi -------------- next part -------------- From 780a58a38d0445d1b4b58363b734a262a07a879e Mon Sep 17 00:00:00 2001 From: Raffi Enficiaud Date: Mon, 14 Sep 2015 14:45:12 +0200 Subject: [PATCH] CPackDeb: preventing md5sum on symlinks - Direct call to cmSystemTools::ComputeFileMD5 - Avoiding hashing symlinks - Tests --- Source/CPack/cmCPackDebGenerator.cxx | 42 ++++++++++++---------- Tests/CPackComponentsDEB/CMakeLists.txt | 20 +++++++++++ ...yResult-components-lintian-dpkgdeb-checks.cmake | 34 ++++++++++++++++++ .../CPackComponentsDEB/RunCPackVerifyResult.cmake | 12 +++++-- 4 files changed, 86 insertions(+), 22 deletions(-) diff --git a/Source/CPack/cmCPackDebGenerator.cxx b/Source/CPack/cmCPackDebGenerator.cxx index 981d86d..090c076 100644 --- a/Source/CPack/cmCPackDebGenerator.cxx +++ b/Source/CPack/cmCPackDebGenerator.cxx @@ -526,27 +526,31 @@ int cmCPackDebGenerator::createDeb() packageFiles.begin(); fileIt != packageFiles.end(); ++ fileIt ) { - std::string cmd = "\""; - cmd += cmSystemTools::GetCMakeCommand(); - cmd += "\" -E md5sum \""; - cmd += *fileIt; - cmd += "\""; - - std::string output; - int retval = -1; - int res = cmSystemTools::RunSingleCommand(cmd.c_str(), &output, &output, - &retval, toplevel.c_str(), this->GeneratorVerbose, 0); - if ( !res || retval ) + + // hash only regular files + if( cmSystemTools::FileIsDirectory(*fileIt) + || cmSystemTools::FileIsSymlink(*fileIt)) { - cmCPackLogger(cmCPackLog::LOG_ERROR, "Problem running cmake -E md5sum " - << cmd << std::endl); + continue; } - // debian md5sums entries are like this: - // 014f3604694729f3bf19263bac599765 usr/bin/ccmake - // thus strip the full path (with the trailing slash) - cmSystemTools::ReplaceString(output, - topLevelWithTrailingSlash.c_str(), ""); - out << output; + + char md5sum[33]; + if(!cmSystemTools::ComputeFileMD5(*fileIt, md5sum)) + { + cmCPackLogger(cmCPackLog::LOG_ERROR, "Problem computing the md5 of " + << *fileIt << std::endl); + } + + md5sum[32] = 0; + + std::string output(md5sum); + output += " " + *fileIt + "\n"; + // debian md5sums entries are like this: + // 014f3604694729f3bf19263bac599765 usr/bin/ccmake + // thus strip the full path (with the trailing slash) + cmSystemTools::ReplaceString(output, + topLevelWithTrailingSlash.c_str(), ""); + out << output; } // each line contains a eol. // Do not end the md5sum file with yet another (invalid) diff --git a/Tests/CPackComponentsDEB/CMakeLists.txt b/Tests/CPackComponentsDEB/CMakeLists.txt index c25e33a..8ed81ac 100644 --- a/Tests/CPackComponentsDEB/CMakeLists.txt +++ b/Tests/CPackComponentsDEB/CMakeLists.txt @@ -93,6 +93,26 @@ if(CHMOD_PROG) "${CMAKE_CURRENT_BINARY_DIR}/preinst;${CMAKE_CURRENT_BINARY_DIR}/prerm") endif() +# creates a symbolic link and a directory. Those should not be hashed. +# warning: relocation of the symlink is not supported (symlinks with relative +# paths) +execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink mylibapp symtest) +install(FILES ${CPackComponentsDEB_BINARY_DIR}/symtest + DESTINATION bin + COMPONENT applications) + +if(EXISTS "./dirtest") + execute_process(COMMAND ${CMAKE_COMMAND} -E remove_directory ./dirtest) +endif() +execute_process(COMMAND ${CMAKE_COMMAND} -E make_directory ./dirtest) +# BUG: apparently cannot add an empty directory +execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ../mylibapp ./dirtest/symtest) +# NOTE: we should not add the trailing "/" to dirtest +install(DIRECTORY ${CPackComponentsDEB_BINARY_DIR}/dirtest + DESTINATION bin/ + COMPONENT applications) + + # We may use the CPack specific config file in order # to tailor CPack behavior on a CPack generator specific way diff --git a/Tests/CPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake b/Tests/CPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake index 5460b1a..c2b2417 100644 --- a/Tests/CPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake +++ b/Tests/CPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake @@ -42,6 +42,13 @@ if(LINTIAN_EXECUTABLE) ERROR_REGEX_STRINGS "${STRINGS_TO_AVOID}") set(lintian_output_errors_all "${lintian_output_errors_all}${lintian_output_errors}") + + set(STRINGS_TO_AVOID "E:([^\r\n]*)md5sums-lists-nonexistent-file") + lintian_check_specific_errors(lintian_output_errors + FILENAME "${_f}" + ERROR_REGEX_STRINGS "${STRINGS_TO_AVOID}") + + set(lintian_output_errors_all "${lintian_output_errors_all}${lintian_output_errors}") endforeach() if(NOT "${lintian_output_errors_all}" STREQUAL "") @@ -68,6 +75,33 @@ if(DPKGDEB_EXECUTABLE) set(dpkgdeb_output_errors_all "${dpkgdeb_output_errors_all}" "dpkg-deb: ${_f}: Incorrect value for Maintainer: ${dpkgentry} != None\n") endif() + + dpkgdeb_return_specific_metaentry(dpkg_package_name + DPKGDEB_OUTPUT "${dpkg_output}" + METAENTRY "Package:") + + # specific to the component "applications" + if("${dpkg_package_name}" STREQUAL "mylib-applications") + run_dpkgdeb(dpkg_contents + FILENAME "${_f}" + ACTION "--contents" + ) + + string(FIND "${dpkg_contents}" "bin/symtest" index_symlink) + if(index_symlink EQUAL "-1") + set(dpkgdeb_output_errors_all ${dpkgdeb_output_errors_all} + "dpkg-deb: ${_f}: symlink missing") + endif() + + string(REGEX MATCH "(bin/dirtest/)([^\r\n]*)" index_directory "${dpkg_contents}") + if("${CMAKE_MATCH_1}" STREQUAL "") + set(dpkgdeb_output_errors_all ${dpkgdeb_output_errors_all} + "dpkg-deb: ${_f}: directory 'bin/dirtest/' missing") + endif() + + endif() + + endforeach() if(NOT "${dpkgdeb_output_errors_all}" STREQUAL "") diff --git a/Tests/CPackComponentsDEB/RunCPackVerifyResult.cmake b/Tests/CPackComponentsDEB/RunCPackVerifyResult.cmake index b96669e..bf9f81d 100644 --- a/Tests/CPackComponentsDEB/RunCPackVerifyResult.cmake +++ b/Tests/CPackComponentsDEB/RunCPackVerifyResult.cmake @@ -137,6 +137,8 @@ endfunction() # This function runs dpkg-deb on a .deb and returns its output +# the default behaviour it to run "--info" on the specified Debian package +# ACTION is one of the option accepted by dpkg-deb function(run_dpkgdeb dpkg_deb_output) set(${dpkg_deb_output} "" PARENT_SCOPE) @@ -144,7 +146,7 @@ function(run_dpkgdeb dpkg_deb_output) if(DPKGDEB_EXECUTABLE) set(options "") - set(oneValueArgs "FILENAME") + set(oneValueArgs "FILENAME" "ACTION") set(multiValueArgs "") cmake_parse_arguments(run_dpkgdeb_deb "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN} ) @@ -153,8 +155,12 @@ function(run_dpkgdeb dpkg_deb_output) message(FATAL_ERROR "error: run_dpkgdeb needs FILENAME to be set") endif() - # run lintian - execute_process(COMMAND ${DPKGDEB_EXECUTABLE} -I ${run_dpkgdeb_deb_FILENAME} + if(NOT run_dpkgdeb_deb_ACTION) + set(run_dpkgdeb_deb_ACTION "--info") + endif() + + # run dpkg-deb + execute_process(COMMAND ${DPKGDEB_EXECUTABLE} ${run_dpkgdeb_deb_ACTION} ${run_dpkgdeb_deb_FILENAME} WORKING_DIRECTORY "${CPACK_TEMPORARY_DIRECTORY}" OUTPUT_VARIABLE DPKGDEB_OUTPUT RESULT_VARIABLE DPKGDEB_RESULT -- 1.9.1 From raffi.enficiaud at mines-paris.org Mon Sep 14 08:53:41 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Mon, 14 Sep 2015 14:53:41 +0200 Subject: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive In-Reply-To: References: Message-ID: Le 14/09/15 11:51, Raffi Enficiaud a ?crit : > Hi Brad and Domen and others, > > I just realized that the permissions for the extra control files should > be set in a different way than for the md5sum checksum file. > > Please find attached the patch correcting this and the corresponding > test that fires the problem. > > Best, > Raffi > > It's better with the attachment, sorry. Raffi -------------- next part -------------- >From 45fa572012ae2140a8b81d56c8d4b0b10e30c19f Mon Sep 17 00:00:00 2001 From: Raffi Enficiaud Date: Mon, 14 Sep 2015 11:42:33 +0200 Subject: [PATCH] cpackdeb: reset extra file permissions to their original Adding a note about the file permissions on the extra files. --- Modules/CPackDeb.cmake | 7 ++++++- Source/CPack/cmCPackDebGenerator.cxx | 4 +++- Tests/CPackComponentsDEB/CMakeLists.txt | 14 ++++++++++++++ 3 files changed, 23 insertions(+), 2 deletions(-) diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake index 970a7d0..0ccfee4 100644 --- a/Modules/CPackDeb.cmake +++ b/Modules/CPackDeb.cmake @@ -326,7 +326,12 @@ # # set(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA # "${CMAKE_CURRENT_SOURCE_DIR/prerm;${CMAKE_CURRENT_SOURCE_DIR}/postrm") - +# +# .. note:: +# +# The original permissions of the files will be used in the final +# package. In particular, the scripts should have the proper executable +# flag prior to the generation of the package. #============================================================================= # Copyright 2007-2009 Kitware, Inc. diff --git a/Source/CPack/cmCPackDebGenerator.cxx b/Source/CPack/cmCPackDebGenerator.cxx index dc9fca3..981d86d 100644 --- a/Source/CPack/cmCPackDebGenerator.cxx +++ b/Source/CPack/cmCPackDebGenerator.cxx @@ -576,7 +576,7 @@ int cmCPackDebGenerator::createDeb() control_tar.SetUNAME("root"); control_tar.SetGNAME("root"); - // set md5sum file permissins to RW-R--R-- so that deb lintian + // set md5sum file permissions to RW-R--R-- so that deb lintian // doesn't warn about it control_tar.SetPermissions(S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); @@ -597,6 +597,8 @@ int cmCPackDebGenerator::createDeb() this->GetOption("GEN_CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA"); if( controlExtra ) { + // permissions are now controlled by the original file permissions + control_tar.SetPermissions(-1); std::vector controlExtraList; cmSystemTools::ExpandListArgument(controlExtra, controlExtraList); for(std::vector::iterator i = controlExtraList.begin(); diff --git a/Tests/CPackComponentsDEB/CMakeLists.txt b/Tests/CPackComponentsDEB/CMakeLists.txt index 5c4eeab..c25e33a 100644 --- a/Tests/CPackComponentsDEB/CMakeLists.txt +++ b/Tests/CPackComponentsDEB/CMakeLists.txt @@ -80,6 +80,20 @@ set(CPACK_COMPONENT_HEADERS_DESCRIPTION # depend on the libraries component. set(CPACK_COMPONENT_HEADERS_DEPENDS libraries) +# creates preinst/prerm scripts with specific permissions. Those permissions +# (especially executable) should be in the final archive +find_program(CHMOD_PROG chmod) +if(CHMOD_PROG) + file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/preinst "echo default_preinst") + file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/prerm "echo default_prerm") + execute_process(COMMAND ${CHMOD_PROG} a+x ${CMAKE_CURRENT_BINARY_DIR}/preinst) + execute_process(COMMAND ${CHMOD_PROG} a+x ${CMAKE_CURRENT_BINARY_DIR}/prerm) + + set(CPACK_DEBIAN_APPLICATIONS_PACKAGE_CONTROL_EXTRA + "${CMAKE_CURRENT_BINARY_DIR}/preinst;${CMAKE_CURRENT_BINARY_DIR}/prerm") +endif() + + # We may use the CPack specific config file in order # to tailor CPack behavior on a CPack generator specific way # (Behavior would be different for RPM or TGZ or DEB ...) -- 1.9.1 From raffi.enficiaud at mines-paris.org Mon Sep 14 09:28:37 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Mon, 14 Sep 2015 15:28:37 +0200 Subject: [cmake-developers] [CPackDeb] empty directories in packages Message-ID: Hi Brad and Domen and others, I was looking at this issue http://public.kitware.com/Bug/view.php?id=13009 and apparently it is not possible to install empty directories (I just tested). I believe that it should be possible to do that (even if there are better ways like postinst). What is your opinion? The attached patch addresses this (and adds the corresponding test). It is based on my previous patch "0001-CPackDeb-preventing-md5sum-on-symlinks.patch". Thanks, Raffi -------------- next part -------------- From 96a0b35d408f8c0d9310eb753e95ed5d1f37424e Mon Sep 17 00:00:00 2001 From: Raffi Enficiaud Date: Mon, 14 Sep 2015 15:25:50 +0200 Subject: [PATCH] CPackDeb: enables empty directories in packages --- Source/CPack/cmCPackDebGenerator.cxx | 2 ++ Tests/CPackComponentsDEB/CMakeLists.txt | 3 +-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Source/CPack/cmCPackDebGenerator.cxx b/Source/CPack/cmCPackDebGenerator.cxx index 090c076..3c2189f 100644 --- a/Source/CPack/cmCPackDebGenerator.cxx +++ b/Source/CPack/cmCPackDebGenerator.cxx @@ -95,6 +95,7 @@ int cmCPackDebGenerator::PackageOnePack(std::string initialTopLevel, std::string findExpr(this->GetOption("GEN_WDIR")); findExpr += "/*"; gl.RecurseOn(); + gl.SetRecurseListDirs(true); if ( !gl.FindFiles(findExpr) ) { cmCPackLogger(cmCPackLog::LOG_ERROR, @@ -222,6 +223,7 @@ int cmCPackDebGenerator::PackageComponentsAllInOne() std::string findExpr(this->GetOption("GEN_WDIR")); findExpr += "/*"; gl.RecurseOn(); + gl.SetRecurseListDirs(true); if ( !gl.FindFiles(findExpr) ) { cmCPackLogger(cmCPackLog::LOG_ERROR, diff --git a/Tests/CPackComponentsDEB/CMakeLists.txt b/Tests/CPackComponentsDEB/CMakeLists.txt index 8ed81ac..d4bd9f1 100644 --- a/Tests/CPackComponentsDEB/CMakeLists.txt +++ b/Tests/CPackComponentsDEB/CMakeLists.txt @@ -104,9 +104,8 @@ install(FILES ${CPackComponentsDEB_BINARY_DIR}/symtest if(EXISTS "./dirtest") execute_process(COMMAND ${CMAKE_COMMAND} -E remove_directory ./dirtest) endif() +# NOTE: directory left empty on purpose execute_process(COMMAND ${CMAKE_COMMAND} -E make_directory ./dirtest) -# BUG: apparently cannot add an empty directory -execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ../mylibapp ./dirtest/symtest) # NOTE: we should not add the trailing "/" to dirtest install(DIRECTORY ${CPackComponentsDEB_BINARY_DIR}/dirtest DESTINATION bin/ -- 1.9.1 From mantis at public.kitware.com Mon Sep 14 09:43:35 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 14 Sep 2015 09:43:35 -0400 Subject: [cmake-developers] [CMake 0015742]: string(REGEX MATCH) and string(REGEX MATCHALL) concatenate arguments Message-ID: <25917f5946412f8339cd59502c36c9c4@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15742 ====================================================================== Reported By: Fujii Hironori Assigned To: ====================================================================== Project: CMake Issue ID: 15742 Category: Documentation Reproducibility: N/A Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-14 09:43 EDT Last Modified: 2015-09-14 09:43 EDT ====================================================================== Summary: string(REGEX MATCH) and string(REGEX MATCHALL) concatenate arguments Description: > string(REGEX MATCH "a." out a b c) 'out' becomes "ab". This is a intended behavior. [Cmake] regex error ? in 2.1 http://www.cmake.org/pipermail/cmake/2004-June/005173.html This should be documented. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-14 09:43 Fujii Hironori New Issue ====================================================================== From brad.king at kitware.com Mon Sep 14 09:55:04 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 14 Sep 2015 09:55:04 -0400 Subject: [cmake-developers] Portability patches / bug fixes In-Reply-To: <20150912150320.GB306@britannica.bec.de> References: <20150912150320.GB306@britannica.bec.de> Message-ID: <55F6D1B8.5050504@kitware.com> On 09/12/2015 11:03 AM, Joerg Sonnenberger wrote: > attached are three patches for cmake. The first two should be trivial > and self-explaining. The third is a more involved change for ccmake. Thanks. I've applied the changes: jsoncpp: Fix compilation as C99 on Solaris http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=75644daf ccmake: Pass format string to 'printw' (#15738) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=acd9b4d3 ccmake: Avoid using non-portable 'curcol' field (#15739) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=045a845d The latter two were also submitted to the issue tracker so I added the issue numbers. Another related patch was also submitted there: ccmake: Use more-portable call to set_field_buffer (#15740) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c2128679 -Brad From brad.king at kitware.com Mon Sep 14 10:11:52 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 14 Sep 2015 10:11:52 -0400 Subject: [cmake-developers] Python extension to FindProtobuf In-Reply-To: <6B1070FD3B25C348BB7E9CD29C1F16D137E7BC63@flexchange.home.fishlabs.net> References: <6B1070FD3B25C348BB7E9CD29C1F16D137E70DCE@flexchange.home.fishlabs.net> <1727564.SG6oXUDnmz@caliban.sf-tec.de> <6B1070FD3B25C348BB7E9CD29C1F16D137E70DF0@flexchange.home.fishlabs.net> <55F31E6E.4010508@kitware.com> <6B1070FD3B25C348BB7E9CD29C1F16D137E7BC63@flexchange.home.fishlabs.net> Message-ID: <55F6D5A8.3010601@kitware.com> On 09/14/2015 03:42 AM, Andreas Bergmeier wrote: > I now added documentation, removed ARGS and GENERATED property. Thanks. Applied with minor wording tweaks: FindProtobuf: Add protobuf_generate_python function http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=143579c3 -Brad From brad.king at kitware.com Mon Sep 14 10:51:54 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 14 Sep 2015 10:51:54 -0400 Subject: [cmake-developers] find_program HINTS no longer preferred over PATH In-Reply-To: References: <55E6F28E.1080706@kitware.com> <7F62CA7F-33C7-4D39-BA2C-D3D5669973B1@sap.com> <55E71955.1070603@kitware.com> <2A8C1310-D3AA-404A-88A3-5298D04A35AC@sap.com> <55F049E7.7080903@kitware.com> <55F07851.7070006@kitware.com> Message-ID: <55F6DF0A.8060503@kitware.com> On 09/14/2015 03:05 AM, CHEVRIER, Marc wrote: > Any news on this subject? Chuck has had a fix in 'next' for a few days: find_*: Fix search order when the environment duplicates some HINTS http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec8e5fb3 but the topic is still missing a test case. -Brad From DLRdave at aol.com Mon Sep 14 11:46:49 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 14 Sep 2015 11:46:49 -0400 Subject: [cmake-developers] Listing all targets In-Reply-To: <55ACF7F5.1040702@kitware.com> References: <55A65BDA.4010808@kitware.com> <20150717141401.GB31310@megas.kitware.com> <20150717175424.GA26601@megas.kitware.com> <20150717185536.GA31013@megas.kitware.com> <55ACF7F5.1040702@kitware.com> Message-ID: Finally getting back to this, hopefully can push to next this week, and have this completed in time for the upcoming 3.4 release. I have three questions before attempting my first merge-to-next for testing: (1) I see how I can easily move "COMPONENTS" from cmGetCMakePropertyCommand::InitialPass to cmState::GetGlobalProperty because I can access the global generator from cmState as well... To move "VARIABLES" and "MACROS," though, I need access to the correct cmMakefile in which the cmGetCMakePropertyCommand is running. Do I need to pass the cmMakefile instance as a new parameter to cmState::GetGlobalProperty, or is the correct Makefile instance already available from the context of the cmState? (If so, it's non-obvious to me from code analysis...) Steve, Brad? Any input on this question? (2) I will update the documentation of get_cmake_property to say these are all also available via get_property(GLOBAL ... That's the correct intent, right? All calls to get_cmake_property should have exactly the same content as a corresponding call to get_property(GLOBAL? (3) Is anyone concerned about adding a global property with the somewhat generic name "TARGETS" ? Do we care if any projects out there are already doing a set_property(GLOBAL with the name "TARGETS"? The downside of a project doing so would be that when they try to read the value back with get_property, CMake's implementation will overwrite their set values with the list of all available CMake targets, which may be different than what the project had set into the property. Thanks for any feedback, David C. On Mon, Jul 20, 2015 at 9:30 AM, Brad King wrote: > On 07/17/2015 06:05 PM, David Cole via cmake-developers wrote: >> Attached is a patch file of my first attempt. I can iterate some more >> on this (better testing, add docs, clarify existing docs, address >> anybody's comments, submit to stage) next week. Attached now in case >> anybody wants to try it out over the weekend. > [snip] >>> I think the see also is relevant because it points to another way to >>> get to a whole different set of "properties". Perhaps what they're >>> looking for when they stumble upon get_cmake_property is actually >>> target properties, which are only accessible via get_property. > > get_cmake_property is get_property with the GLOBAL scope, except that > it looks like the special VARIABLES, MACROS, and COMPONENTS properties > are hard-coded into get_cmake_property incorrectly. > > This should all be moved over to cmState::GetGlobalProperty and the > new TARGETS property added there. That method already has special > handling for a few other properties too. > > Also the documentation of get_cmake_property should be updated to > mention "global" properties. > > -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 rakuco at FreeBSD.org Mon Sep 14 12:11:42 2015 From: rakuco at FreeBSD.org (Raphael Kubo da Costa) Date: Mon, 14 Sep 2015 18:11:42 +0200 Subject: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9. Message-ID: <1442247102-47516-1-git-send-email-rakuco@FreeBSD.org> As of version 3.3.1, CMake sets CMAKE_C11_STANDARD_COMPILE_OPTION and CMAKE_C11_EXTENSION_COMPILE_OPTION for GCC >= 4.7, and checks for C11 features for GCC >= 4.6. It also means CMake itself will be built with -std=gnu11 if GCC >= 4.7 is used. However, GCC only has full C11 support with the 4.9 release according to https://gcc.gnu.org/wiki/C11Status. Specifically, support for C11's _Thread_local is only present on GCC >= 4.9. This combination makes CMake fail to build with GCC 4.7 and 4.8 on FreeBSD, as runetype.h uses _Thread_local and the fact that -std=gnu11 is passed makes it not be a typedef or define for something else that would work. Adjust the GCC feature detection code to only consider C11 support to exist on GCC >= 4.9. Bug: http://www.cmake.org/Bug/view.php?id=15741 --- Modules/Compiler/GNU-C-FeatureTests.cmake | 7 +------ Modules/Compiler/GNU-C.cmake | 7 ++----- 2 files changed, 3 insertions(+), 11 deletions(-) diff --git a/Modules/Compiler/GNU-C-FeatureTests.cmake b/Modules/Compiler/GNU-C-FeatureTests.cmake index b3fe33f..c7f5050 100644 --- a/Modules/Compiler/GNU-C-FeatureTests.cmake +++ b/Modules/Compiler/GNU-C-FeatureTests.cmake @@ -1,12 +1,7 @@ set(_cmake_oldestSupported "(__GNUC__ * 100 + __GNUC_MINOR__) >= 404") -# GNU 4.7 correctly sets __STDC_VERSION__ to 201112L, but GNU 4.6 sets it -# to 201000L. As the former is strictly greater than the latter, test only -# for the latter. If in the future CMake learns about a C feature which was -# introduced with GNU 4.7, that should test for the correct version, similar -# to the distinction between __cplusplus and __GXX_EXPERIMENTAL_CXX0X__ tests. -set(GNU46_C11 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 406 && defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201000L") +set(GNU49_C11 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 409 && defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L") set(_cmake_feature_test_c_static_assert "${GNU46_C11}") # Since 4.4 at least: set(GNU44_C99 "(__GNUC__ * 100 + __GNUC_MINOR__) >= 404 && defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L") diff --git a/Modules/Compiler/GNU-C.cmake b/Modules/Compiler/GNU-C.cmake index 031ab73..f1036db 100644 --- a/Modules/Compiler/GNU-C.cmake +++ b/Modules/Compiler/GNU-C.cmake @@ -14,12 +14,9 @@ if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4) set(CMAKE_C99_EXTENSION_COMPILE_OPTION "-std=gnu99") endif() -if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.7) +if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.9) set(CMAKE_C11_STANDARD_COMPILE_OPTION "-std=c11") set(CMAKE_C11_EXTENSION_COMPILE_OPTION "-std=gnu11") -elseif (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.6) - set(CMAKE_C11_STANDARD_COMPILE_OPTION "-std=c1x") - set(CMAKE_C11_EXTENSION_COMPILE_OPTION "-std=gnu1x") endif() if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 5.0) @@ -34,7 +31,7 @@ macro(cmake_record_c_compile_features) endmacro() set(_result 0) - if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.6) + if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.9) _get_gcc_features(${CMAKE_C11_STANDARD_COMPILE_OPTION} CMAKE_C11_COMPILE_FEATURES) endif() if (NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.4) -- 2.5.2 From steveire at gmail.com Mon Sep 14 13:16:24 2015 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 14 Sep 2015 19:16:24 +0200 Subject: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9. References: <1442247102-47516-1-git-send-email-rakuco@FreeBSD.org> Message-ID: Raphael Kubo da Costa wrote: > Adjust the GCC feature detection code to only consider C11 support to > exist on GCC >= 4.9. If you do that you must remove the definition of CMAKE_CXX11_STANDARD_COMPILE_OPTION for GNU < 4.8.1 too. IOW, this patch is not correct, and should not be merged. According to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066 sys/cdefs.h requires that if you use -std=c11, your compiler must have the c_thread_local feature. Therefore, you must not use -std=c11 with GNU < 4.9. So, because of the apparent requirement of the FreeBSD header, if you build cmake with GNU < 4.9, you must configure it with CMake_NO_C_STANDARD=TRUE. Of course, the actual bug is in sys/cdefs.h as comment #2 in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066 describes. The __STDC_VERSION__ macro on its own (just like the __cplusplus macro on its own) is not suitable for feature testing. You must check the compiler vendor and version (or use SD-6 for C++). Comment #3 in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066 seems strange to me, as it assumes that changing Ports packages is sufficient to solving the problem. Should third parties be able to build their code on FreeBSD? If so, then a compiler vendor and version check in sys/cdefs.h is the right thing to do, and I recommend getting that done. So, in summary, there is no bug in CMake, but either your package needs to change (to add CMake_NO_C_STANDARD=TRUE), or sys/cdefs.h needs to change, or both. Thanks, Steve. From brad.king at kitware.com Mon Sep 14 13:28:37 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 14 Sep 2015 13:28:37 -0400 Subject: [cmake-developers] Listing all targets In-Reply-To: References: <55A65BDA.4010808@kitware.com> <20150717141401.GB31310@megas.kitware.com> <20150717175424.GA26601@megas.kitware.com> <20150717185536.GA31013@megas.kitware.com> <55ACF7F5.1040702@kitware.com> Message-ID: <55F703C5.8060901@kitware.com> On 09/14/2015 11:46 AM, David Cole wrote: > (1) I see how I can easily move "COMPONENTS" from > cmGetCMakePropertyCommand::InitialPass to cmState::GetGlobalProperty > because I can access the global generator from cmState as well... Yes. > move "VARIABLES" and "MACROS," though, I need access to the correct > cmMakefile in which the cmGetCMakePropertyCommand is running. Those are actually directory properties and should never have been available through get_cmake_property(). They should already be available through get_property() in the DIRECTORY scope. Please instead deprecate them with a warning. > (2) I will update the documentation of get_cmake_property to say these > are all also available via get_property(GLOBAL ... The command docs already say something along those lines but the wording could be made more consistent with get_property's GLOBAL scope. > All calls to get_cmake_property should have exactly the > same content as a corresponding call to get_property(GLOBAL? The behavior for unset properties differs. > (3) Is anyone concerned about adding a global property with the > somewhat generic name "TARGETS" ? Do we care if any projects out there > are already doing a set_property(GLOBAL with the name "TARGETS"? We could call it CMAKE_ALL_TARGETS. Other name ideas, anyone? Thanks, -Brad From steveire at gmail.com Mon Sep 14 13:34:10 2015 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 14 Sep 2015 19:34:10 +0200 Subject: [cmake-developers] Allow ALIAS of IMPORTED targets References: <55F49DC0.5090300@gmail.com> Message-ID: Michael Scott wrote: > Hi, > > I'm planning on having a look at the CMake issue "Allow ALIAS of > IMPORTED targets", 0015569. After reading the thread between yourself > and Marc, I wanted to ask a couple of things before I start going > further with it. Thanks for working on this. > The proposed change would be for the add_library and add_executable > commands only right? Yes, I guess so. > Having a quick look at the code for those two commands, they > specifically check for a combination of ALIAS and IMPORTED and don't > allow it. I'm guessing that the required changes to allow both > simultaneously wouldn't be to just remove this check, there would be > other areas to modify as well right? Perhaps. Finding that out is the real task :). I don't have all the answers to it. The specific disallowing of ALIAS and IMPORTED together by issuing an error was a way to defer finding those answers while not being required to maintain compatibility with a particular behavior. I didn't want finding those answers to delay getting the ALIAS feature in, because it was useful already as it was. Now, we have time to consider all of the implications of allowing this as part of the design. For example, if an ALIAS can be IMPORTED, does it makes sense that it can be exported with export() and install(EXPORT)? If we have add_library(CoreStatic ${Core_SRCS}) add_library(MyNS::Core ALIAS CoreStatic) and I export both of them with the NAMESPACE 'MyNS::', do I end up with MyNS::MyNS::Core ? Or would the exporting code strip of everything before a '::' in the alias name? Or should exporting ALIAS targets still be disallowed? The two use cases described in http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/52452 seem like they would not benefit from exporting ALIAS targets. A reasonable way forward might be: * Keep the restriction that ALIAS targets may not be exported. * Remove the code disallowing ALIAS IMPORTED targets. * Remove the unit test proving it is not allowed * Add new unit tests that it basically works * Add a unit test for using an ALIAS with try_compile(LINK_LIBRARIES) * (Anything else that comes up along the way) Thanks, Steve. From steveire at gmail.com Mon Sep 14 13:47:23 2015 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 14 Sep 2015 19:47:23 +0200 Subject: [cmake-developers] Listing all targets References: <55A65BDA.4010808@kitware.com> <20150717141401.GB31310@megas.kitware.com> <20150717175424.GA26601@megas.kitware.com> <20150717185536.GA31013@megas.kitware.com> <55ACF7F5.1040702@kitware.com> <55F703C5.8060901@kitware.com> Message-ID: Brad King wrote: > On 09/14/2015 11:46 AM, David Cole wrote: >> (1) I see how I can easily move "COMPONENTS" from >> cmGetCMakePropertyCommand::InitialPass to cmState::GetGlobalProperty >> because I can access the global generator from cmState as well... > > Yes. I assume you're thinking of getting the global generator from the cmake instance? That's not appropriate. The cmState should not know the cmake instance or the global generator. The fact that it currently knows the cmake instance is a temporary evil of the cache stuff not being fully refactored yet. The install components would need to become 'first-class' parts of cmState, in the same way that definitions and properties became first-class (ie, not by making cmState aware of cmMakefile!). That refactoring can be done if you want to give it a shot and see what's needed, but it is a post-3.4 branch. Making the target names available through properties via cmState is also trivial after targets become first-class parts of cmState (cmState::Target like cmState::Directory). That can happen sooner (it's on my plate), but required refactoring is also on hold until after CMake 3.4. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14286/focus=14323 Thanks, Steve. From rakuco at FreeBSD.org Mon Sep 14 13:53:00 2015 From: rakuco at FreeBSD.org (Raphael Kubo da Costa) Date: Mon, 14 Sep 2015 19:53:00 +0200 Subject: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9. References: <1442247102-47516-1-git-send-email-rakuco@FreeBSD.org> Message-ID: <86y4g8lwg3.fsf@FreeBSD.org> Stephen Kelly writes: > Raphael Kubo da Costa wrote: > >> Adjust the GCC feature detection code to only consider C11 support to >> exist on GCC >= 4.9. > > If you do that you must remove the definition of > CMAKE_CXX11_STANDARD_COMPILE_OPTION for GNU < 4.8.1 too. [...] > sys/cdefs.h requires that if you use -std=c11, your compiler must have the > c_thread_local feature. Therefore, you must not use -std=c11 with GNU < 4.9. [...] > Of course, the actual bug is in sys/cdefs.h as comment #2 in > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066 > describes. I don't think comment #2 acknowledges there's a bug in cdefs.h; I see it as more of an acknowledgment that adding an additional check there would help work around/solve the issue. > The __STDC_VERSION__ macro on its own (just like the __cplusplus macro on > its own) is not suitable for feature testing. You must check the compiler > vendor and version (or use SD-6 for C++). [...] > So, in summary, there is no bug in CMake, but either your package needs to > change (to add CMake_NO_C_STANDARD=TRUE), or sys/cdefs.h needs to change, or > both. I see your point, and building with CMake_NO_C_STANDARD=TRUE or CMAKE_C_STANDARD=99 is definitely an option. I wouldn't count on cdefs.h being changed, and even if it was it wouldn't solve the issue on existing systems. Especially if you take into account the CMAKE_CXX11_STANDARD_COMPILE_OPTION argument, one could argue that this is about choosing how strict CMake should be when determining whether a compiler implements a standard: enabling C++11 support only with GCC 4.8 looks limiting and leaves out all the cases where it actually works fine with earlier versions. Is this patch too broad for C11 and GCC, or is it different from the C++11 case? It sounded like Brad was in favor of the former, whereas you'd like the change not to be merged. I am fine with just changing the way CMake is packaged on FreeBSD, but it still leaves it broken with third-party software (even outside FreeBSD in case they use an older GCC and _Thread_local) like you mentioned. From brad.king at kitware.com Mon Sep 14 14:02:43 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 14 Sep 2015 14:02:43 -0400 Subject: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9. In-Reply-To: <86y4g8lwg3.fsf@FreeBSD.org> References: <1442247102-47516-1-git-send-email-rakuco@FreeBSD.org> <86y4g8lwg3.fsf@FreeBSD.org> Message-ID: <55F70BC3.60303@kitware.com> On 09/14/2015 01:53 PM, Raphael Kubo da Costa wrote: > Especially if you take into account the > CMAKE_CXX11_STANDARD_COMPILE_OPTION argument, one could argue that this > is about choosing how strict CMake should be when determining whether a > compiler implements a standard: enabling C++11 support only with GCC 4.8 > looks limiting and leaves out all the cases where it actually works fine > with earlier versions. Is this patch too broad for C11 and GCC, or is it > different from the C++11 case? The idea of these option tables is for CMake to be able to tell the compiler to *nominally* enable support for a given language standard. The extent to which the compiler actually supports it is up to the project to deal with. If we waited for 100% support of a language then many compilers will never get there. In this case CMake itself cannot build with C11 on this compiler/platform combination so we should not try to do so. We already have some checks here: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=CMakeLists.txt;hb=v3.3.1#l39 to decide whether to try using the latest standard or not. One could add a check for the case in question if necessary. > It sounded like Brad was in favor of the former, whereas you'd like the > change not to be merged. Actually I didn't investigate deeply enough before commenting. The mailing list is a much better place for such discussion anyway. -Brad From brad.king at kitware.com Mon Sep 14 14:05:10 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 14 Sep 2015 14:05:10 -0400 Subject: [cmake-developers] find_program HINTS no longer preferred over PATH In-Reply-To: References: <55E6F28E.1080706@kitware.com> <7F62CA7F-33C7-4D39-BA2C-D3D5669973B1@sap.com> <55E71955.1070603@kitware.com> <2A8C1310-D3AA-404A-88A3-5298D04A35AC@sap.com> <55F049E7.7080903@kitware.com> <55F07851.7070006@kitware.com> <55F6DF0A.8060503@kitware.com> Message-ID: <55F70C56.1020403@kitware.com> On 09/14/2015 02:00 PM, Alan W. Irwin wrote: > Because this find regression is against 3.1.3 from what Marc said, may > I assume you are planning to include the fix for this regression in > both future cmake-3.2.x and 3.3.y releases? We may backport it for a possible 3.3.2 but there will be no further upstream 3.2.x releases. -Brad From irwin at beluga.phys.uvic.ca Mon Sep 14 14:00:12 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 14 Sep 2015 11:00:12 -0700 (PDT) Subject: [cmake-developers] find_program HINTS no longer preferred over PATH In-Reply-To: <55F6DF0A.8060503@kitware.com> References: <55E6F28E.1080706@kitware.com> <7F62CA7F-33C7-4D39-BA2C-D3D5669973B1@sap.com> <55E71955.1070603@kitware.com> <2A8C1310-D3AA-404A-88A3-5298D04A35AC@sap.com> <55F049E7.7080903@kitware.com> <55F07851.7070006@kitware.com> <55F6DF0A.8060503@kitware.com> Message-ID: On 2015-09-14 10:51-0400 Brad King wrote: > On 09/14/2015 03:05 AM, CHEVRIER, Marc wrote: >> Any news on this subject? > > Chuck has had a fix in 'next' for a few days: > > find_*: Fix search order when the environment duplicates some HINTS > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec8e5fb3 > > but the topic is still missing a test case. Hi Brad: My judgement is this is a fairly important find regression that is likely to affect most users (like me) who are trying to find some package that is in a non-system location when the same package exists in the standard system location. Therefore, my thanks to Marc for discovering and documenting this issue, and my thanks to Chuck for coming up with a fix for the issue. Because this find regression is against 3.1.3 from what Marc said, may I assume you are planning to include the fix for this regression in both future cmake-3.2.x and 3.3.y releases? 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 rakuco at FreeBSD.org Mon Sep 14 14:29:04 2015 From: rakuco at FreeBSD.org (Raphael Kubo da Costa) Date: Mon, 14 Sep 2015 20:29:04 +0200 Subject: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9. References: <1442247102-47516-1-git-send-email-rakuco@FreeBSD.org> <86y4g8lwg3.fsf@FreeBSD.org> <55F70BC3.60303@kitware.com> Message-ID: <86si6glurz.fsf@FreeBSD.org> Brad King writes: > In this case CMake itself cannot build with C11 on this compiler/platform > combination so we should not try to do so. We already have some checks > here: > > http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=CMakeLists.txt;hb=v3.3.1#l39 > > to decide whether to try using the latest standard or not. One could > add a check for the case in question if necessary. Do you mean checking for FreeBSD and compiler version? I thought it'd be too specific for upstream and was just going to make it be built with a different standard (or no standard) on FreeBSD itself. From brad.king at kitware.com Mon Sep 14 14:38:16 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 14 Sep 2015 14:38:16 -0400 Subject: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9. In-Reply-To: <86si6glurz.fsf@FreeBSD.org> References: <1442247102-47516-1-git-send-email-rakuco@FreeBSD.org> <86y4g8lwg3.fsf@FreeBSD.org> <55F70BC3.60303@kitware.com> <86si6glurz.fsf@FreeBSD.org> Message-ID: <55F71418.4010705@kitware.com> On 09/14/2015 02:29 PM, Raphael Kubo da Costa wrote: > Do you mean checking for FreeBSD and compiler version? I thought it'd be > too specific for upstream and was just going to make it be built with a > different standard (or no standard) on FreeBSD itself. I meant to add a try_compile check with CMAKE_FLAGS -DCMAKE_C_STANDARD=11 using a source file that exercises the problematic code in question. See similar checks here: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/Checks/cm_cxx14_cstdio.cmake;hb=v3.3.1 http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/Checks/cm_cxx11_unordered_map.cmake;hb=v3.3.1 that check if using certain CMAKE_CXX_STANDARD values works for some cases CMake hits with broken C++11 and C++14 platform/compiler combos. This will help CMake build out of the box on FreeBSD with GCC 4.7 without manually adding -DCMake_NO_C_STANDARD=TRUE. -Brad From steveire at gmail.com Mon Sep 14 15:37:13 2015 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 14 Sep 2015 21:37:13 +0200 Subject: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9. References: <1442247102-47516-1-git-send-email-rakuco@FreeBSD.org> <86y4g8lwg3.fsf@FreeBSD.org> Message-ID: Raphael Kubo da Costa wrote: > Stephen Kelly writes: > >> Raphael Kubo da Costa wrote: >> >>> Adjust the GCC feature detection code to only consider C11 support to >>> exist on GCC >= 4.9. >> >> If you do that you must remove the definition of >> CMAKE_CXX11_STANDARD_COMPILE_OPTION for GNU < 4.8.1 too. > [...] >> sys/cdefs.h requires that if you use -std=c11, your compiler must have >> the c_thread_local feature. Therefore, you must not use -std=c11 with GNU >> < 4.9. > [...] >> Of course, the actual bug is in sys/cdefs.h as comment #2 in >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066 >> describes. > > I don't think comment #2 acknowledges there's a bug in cdefs.h; I see it > as more of an acknowledgment that adding an additional check there would > help work around/solve the issue. I do consider it a bug :). Standards are too coarse, features of the compiler are what is relevant: http://www.kdab.com/modern-cmake-with-qt-and-boost/#compile-feature-specification That's also the whole point of SD-6 for C++. The problematic content of the header affects all third party code in and out of the ports system, using cmake or not :). But it doesn't matter that I consider it a bug. I'm not going to fix sys/cdefs.h either :). I can keep my opinions to myself, and people using that combination of toolchain have to deal with it :). > Especially if you take into account the > CMAKE_CXX11_STANDARD_COMPILE_OPTION argument, one could argue that this > is about choosing how strict CMake should be when determining whether a > compiler implements a standard: enabling C++11 support only with GCC 4.8 > looks limiting and leaves out all the cases where it actually works fine > with earlier versions. Conversely, claiming GNU 4.4 supports C++11 doesn't make sense either (because standards are too coarse, features are what is relevant), which is why I consider CMAKE_CXX_STANDARD_REQUIRED to be nonsense. So, yes, I agree with you here :). Thanks, Steve. From brad.king at kitware.com Mon Sep 14 16:16:19 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 14 Sep 2015 16:16:19 -0400 Subject: [cmake-developers] CMake user-provided manifest files In-Reply-To: <55F32560.90608@kitware.com> References: <041501d0eca8$e8cdb2c0$ba691840$@motionview3d.com> <55F318E8.8060603@kitware.com> <55F32560.90608@kitware.com> Message-ID: <55F72B13.8000306@kitware.com> On 09/11/2015 03:02 PM, Brad King wrote: > On 09/11/2015 02:09 PM, Brad King wrote: >> I would be very happy to get rid of the vs_link_exe and vs_link_dll code. > > There is documentation here about what those are doing: > > https://msdn.microsoft.com/en-us/library/ms235591.aspx > http://blogs.msdn.com/b/zakramer/archive/2006/05/22/603558.aspx I just looked back through the implementations of vs_link_{exe,dll} in more detail. For non-incremental linking it just does: link ... /manifest /out:Foo.exe ... mt -manifest Foo.exe.manifest -outputresource:Foo.exe;1 For incremental linking it does: (create empty "embed.manifest" and Foo.rc referencing it) rc Foo.rc -foFoo.res link ... /manifest /manifestfile:tmp.manifest Foo.res mt -manifest tmp.manifest -out:embed.manifest (if "embed.manifest" changed): rc Foo.rc -foFoo.res link ... /manifest /manifestfile:tmp.manifest Foo.res The latter/conditional "rc" and "link" invocations are identical to the first invocations of these tools. In both cases the link tool generates the manifest file and then some steps are taken to embed it in the binary. In both cases there is a "mt" invocation that could be extended to list user-provided manifest files after the linker-generated one. On 09/11/2015 11:45 AM, James Johnston wrote: > Because CMake already does *some* things with the linker it makes it > impossible for me to cleanly specify and use link.exe manifest-related > switches myself. For example, it hard-codes usage of link.exe /MANIFESTFILE > and the user can't specify their own location. And the locations it does > use are undocumented. Is there a use case for doing something with the linker-generated manifest file other than passing it to a "mt" invocation along with (possibly) user-specified manifest files? If not then there is no reason to make the manifest file location public. I think our path forward here is to teach the Makefile and Ninja generators how to add user-specified manifest files to the "mt" invocations as outlined above. Gilles has already posted an implementation for doing this on VS 10+. -Brad From domen.vrankar at gmail.com Mon Sep 14 17:19:20 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Mon, 14 Sep 2015 23:19:20 +0200 Subject: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive In-Reply-To: References: Message-ID: >> I just realized that the permissions for the extra control files should >> be set in a different way than for the md5sum checksum file. >> >> Please find attached the patch correcting this and the corresponding >> test that fires the problem. Thanks, applied the fix: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=68dba7f I've extended RunCMake.CPack_DEB DEB_EXTRA test instead of using your test as I am trying to put new tests there. Thanks, Domen From raffi.enficiaud at mines-paris.org Mon Sep 14 17:29:41 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Mon, 14 Sep 2015 23:29:41 +0200 Subject: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive In-Reply-To: References: Message-ID: Hi Domen, Thank you. However those two test are not mutually exclusive. I think having them on lintian is also a good thing. Best and thanks, Raffi Le 14/09/15 23:19, Domen Vrankar a ?crit : >>> I just realized that the permissions for the extra control files should >>> be set in a different way than for the md5sum checksum file. >>> >>> Please find attached the patch correcting this and the corresponding >>> test that fires the problem. > > Thanks, applied the fix: > http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=68dba7f > > I've extended RunCMake.CPack_DEB DEB_EXTRA test instead of using your > test as I am trying to put new tests there. > > Thanks, > Domen > From domen.vrankar at gmail.com Mon Sep 14 17:34:09 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Mon, 14 Sep 2015 23:34:09 +0200 Subject: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive In-Reply-To: References: Message-ID: > Thank you. However those two test are not mutually exclusive. I think having > them on lintian is also a good thing. I've tried your test change before but lintian test complained that 775 are invalid permissions (should be 755). Is this caused by a different version of lintian or should I just modify your test to use 755 permissions and apply that? Regards, Domen From raffi.enficiaud at mines-paris.org Mon Sep 14 17:49:32 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Mon, 14 Sep 2015 23:49:32 +0200 Subject: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive In-Reply-To: References: Message-ID: Le 14/09/15 23:34, Domen Vrankar a ?crit : >> Thank you. However those two test are not mutually exclusive. I think having >> them on lintian is also a good thing. > > I've tried your test change before but lintian test complained that > 775 are invalid permissions (should be 755). Is this caused by a > different version of lintian or should I just modify your test to use > 755 permissions and apply that? > That's very good that it fails :) I tested on Ubuntu 14.04, maybe Debian distributions are even more strict. Apparently the files that "file(WRITE ...)" created on your system are with 775. I believe the problem lies in the "file(" commands rather than on a different version of lintian. OTOH, I can see from this: https://lintian.debian.org/tags/control-file-has-bad-permissions.html that all files should have at least a permission mask set to ~S_IWGRP & ~S_IWOTH (with "control_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH)"), so that the executable bit is left unchanged and the write bit is cleared for group and others (755 and 644). What do you think? Raffi From tamas.kenez at gmail.com Mon Sep 14 19:09:52 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Tue, 15 Sep 2015 01:09:52 +0200 Subject: [cmake-developers] Allow ALIAS of IMPORTED targets In-Reply-To: References: <55F49DC0.5090300@gmail.com> Message-ID: > For example, if an ALIAS can be IMPORTED, does it makes sense that it can be > exported with export() and install(EXPORT)? Yes: couple of months ago I was adding install(EXPORT) to an existing CMakeList. The name of the library target which I had to export was not correct as export target name but I was not able change the library target name because of backward compatibility. Being able to export an alias would have helped. > and I export both of them with the NAMESPACE 'MyNS::', do I end up with > MyNS::MyNS::Core I guess so, at least that's what I would expect. As far as I know the install(EXPORT) blindly preprends the target name with the namespace string. Tamas On Mon, Sep 14, 2015 at 7:34 PM, Stephen Kelly wrote: > Michael Scott wrote: > > > Hi, > > > > I'm planning on having a look at the CMake issue "Allow ALIAS of > > IMPORTED targets", 0015569. After reading the thread between yourself > > and Marc, I wanted to ask a couple of things before I start going > > further with it. > > Thanks for working on this. > > > The proposed change would be for the add_library and add_executable > > commands only right? > > Yes, I guess so. > > > Having a quick look at the code for those two commands, they > > specifically check for a combination of ALIAS and IMPORTED and don't > > allow it. I'm guessing that the required changes to allow both > > simultaneously wouldn't be to just remove this check, there would be > > other areas to modify as well right? > > Perhaps. Finding that out is the real task :). I don't have all the answers > to it. The specific disallowing of ALIAS and IMPORTED together by issuing > an > error was a way to defer finding those answers while not being required to > maintain compatibility with a particular behavior. I didn't want finding > those answers to delay getting the ALIAS feature in, because it was useful > already as it was. > > Now, we have time to consider all of the implications of allowing this as > part of the design. > > For example, if an ALIAS can be IMPORTED, does it makes sense that it can > be > exported with export() and install(EXPORT)? > > If we have > > add_library(CoreStatic ${Core_SRCS}) > add_library(MyNS::Core ALIAS CoreStatic) > > and I export both of them with the NAMESPACE 'MyNS::', do I end up with > > MyNS::MyNS::Core > > ? > > Or would the exporting code strip of everything before a '::' in the alias > name? > > Or should exporting ALIAS targets still be disallowed? > > The two use cases described in > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/52452 > > seem like they would not benefit from exporting ALIAS targets. > > A reasonable way forward might be: > > * Keep the restriction that ALIAS targets may not be exported. > * Remove the code disallowing ALIAS IMPORTED targets. > * Remove the unit test proving it is not allowed > * Add new unit tests that it basically works > * Add a unit test for using an ALIAS with try_compile(LINK_LIBRARIES) > * (Anything else that comes up along the way) > > 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 domen.vrankar at gmail.com Tue Sep 15 02:43:22 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Tue, 15 Sep 2015 08:43:22 +0200 Subject: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive In-Reply-To: References: Message-ID: 2015-09-14 23:49 GMT+02:00 Raffi Enficiaud : > Le 14/09/15 23:34, Domen Vrankar a ?crit : >>> >>> Thank you. However those two test are not mutually exclusive. I think >>> having >>> them on lintian is also a good thing. >> >> >> I've tried your test change before but lintian test complained that >> 775 are invalid permissions (should be 755). Is this caused by a >> different version of lintian or should I just modify your test to use >> 755 permissions and apply that? >> > > That's very good that it fails :) > > I tested on Ubuntu 14.04, maybe Debian distributions are even more strict. > Apparently the files that "file(WRITE ...)" created on your system are with > 775. I believe the problem lies in the "file(" commands rather than on a > different version of lintian. > > OTOH, I can see from this: > > https://lintian.debian.org/tags/control-file-has-bad-permissions.html > > that all files should have at least a permission mask set to ~S_IWGRP & > ~S_IWOTH (with "control_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH)"), so > that the executable bit is left unchanged and the write bit is cleared for > group and others (755 and 644). > > What do you think? You are correct. I've reinstalled my virtual machine and retested with "control_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH)" and it would seem that there was an issue in my testing environment - before this did not work as expected on my machine. Same goes for default permissions being 664/775 instead of 644/755. I would keep md5 checksum file permissions on 644 with SetPermissions and add SetPermissionsMask from above for the rest of control files. Would you agree? Thanks, Domen From marc.chevrier at sap.com Tue Sep 15 02:57:35 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Tue, 15 Sep 2015 06:57:35 +0000 Subject: [cmake-developers] Allow ALIAS of IMPORTED targets In-Reply-To: References: <55F49DC0.5090300@gmail.com> Message-ID: <8764D1A0-58B4-40B4-968F-D43F4D1394AB@sap.com> I completely agree. Seems reasonable to disallow exporting ALIAS targets. Marc On 14/09/15 19:34, "cmake-developers on behalf of Stephen Kelly" wrote: >Michael Scott wrote: > >> Hi, >> >> I'm planning on having a look at the CMake issue "Allow ALIAS of >> IMPORTED targets", 0015569. After reading the thread between yourself >> and Marc, I wanted to ask a couple of things before I start going >> further with it. > >Thanks for working on this. > >> The proposed change would be for the add_library and add_executable >> commands only right? > >Yes, I guess so. > >> Having a quick look at the code for those two commands, they >> specifically check for a combination of ALIAS and IMPORTED and don't >> allow it. I'm guessing that the required changes to allow both >> simultaneously wouldn't be to just remove this check, there would be >> other areas to modify as well right? > >Perhaps. Finding that out is the real task :). I don't have all the answers >to it. The specific disallowing of ALIAS and IMPORTED together by issuing an >error was a way to defer finding those answers while not being required to >maintain compatibility with a particular behavior. I didn't want finding >those answers to delay getting the ALIAS feature in, because it was useful >already as it was. > >Now, we have time to consider all of the implications of allowing this as >part of the design. > >For example, if an ALIAS can be IMPORTED, does it makes sense that it can be >exported with export() and install(EXPORT)? > >If we have > > add_library(CoreStatic ${Core_SRCS}) > add_library(MyNS::Core ALIAS CoreStatic) > >and I export both of them with the NAMESPACE 'MyNS::', do I end up with > > MyNS::MyNS::Core > >? > >Or would the exporting code strip of everything before a '::' in the alias >name? > >Or should exporting ALIAS targets still be disallowed? > >The two use cases described in > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/52452 > >seem like they would not benefit from exporting ALIAS targets. > >A reasonable way forward might be: > >* Keep the restriction that ALIAS targets may not be exported. >* Remove the code disallowing ALIAS IMPORTED targets. >* Remove the unit test proving it is not allowed >* Add new unit tests that it basically works >* Add a unit test for using an ALIAS with try_compile(LINK_LIBRARIES) >* (Anything else that comes up along the way) > >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 marc.chevrier at sap.com Tue Sep 15 03:42:59 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Tue, 15 Sep 2015 07:42:59 +0000 Subject: [cmake-developers] [CPack][BUG] Fail to package with CPACK_INSTALLED_DIRECTORIES Message-ID: <35211127-F170-4181-AA16-59E46FD0D3DE@sap.com> Hi, To enable to handle various packages as part of the same project and to avoid to execute preinstall target before packaging, I rely on CPack variables CPACK_INSTALLED_DIRECTORIES and CPACK_INSTALL_COMMANDS. Unfortunately, packaging is failing in the following conditions: * Platform Windows (regardless generator: test done with ?Visual Studio? and "Ninja?) * Install command with PERMISSIONS read-only (like OWNER_READ) * PROJECT command with LANGUAGES CXX (specifying LANGUAGES NONE is OK !??) In this case, installed read-only files cannot be copied by CPack. Attached is a CMakeLists.txt showing the problem: * Target package-OK generates the expected package (no read-only permissions) * Target package-KO fails to generate the package (same as previous one except read-only permissions) Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CMakeLists.txt URL: From raffi.enficiaud at mines-paris.org Tue Sep 15 04:11:00 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Tue, 15 Sep 2015 10:11:00 +0200 Subject: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive In-Reply-To: References: Message-ID: Le 15/09/15 08:43, Domen Vrankar a ?crit : > 2015-09-14 23:49 GMT+02:00 Raffi Enficiaud : >> Le 14/09/15 23:34, Domen Vrankar a ?crit : >>>> >>>> Thank you. However those two test are not mutually exclusive. I think >>>> having >>>> them on lintian is also a good thing. >>> >>> >>> I've tried your test change before but lintian test complained that >>> 775 are invalid permissions (should be 755). Is this caused by a >>> different version of lintian or should I just modify your test to use >>> 755 permissions and apply that? >>> >> >> That's very good that it fails :) >> >> I tested on Ubuntu 14.04, maybe Debian distributions are even more strict. >> Apparently the files that "file(WRITE ...)" created on your system are with >> 775. I believe the problem lies in the "file(" commands rather than on a >> different version of lintian. >> >> OTOH, I can see from this: >> >> https://lintian.debian.org/tags/control-file-has-bad-permissions.html >> >> that all files should have at least a permission mask set to ~S_IWGRP & >> ~S_IWOTH (with "control_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH)"), so >> that the executable bit is left unchanged and the write bit is cleared for >> group and others (755 and 644). >> >> What do you think? > > You are correct. I've reinstalled my virtual machine and retested with > "control_tar.SetPermissionsMask(~S_IWGRP & ~S_IWOTH)" and it would > seem that there was an issue in my testing environment - before this > did not work as expected on my machine. Same goes for default > permissions being 664/775 instead of 644/755. > > I would keep md5 checksum file permissions on 644 with SetPermissions > and add SetPermissionsMask from above for the rest of control files. > Would you agree? From this (thanks to lintian now I have the proper link :) ) https://lintian.debian.org/tags/control-file-has-bad-permissions.html https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners all control files: - should be owned by root:root (+ I would say uid/gid 0/0, because root may be mapped) which is the case now - should be 755 or 644, depending if they are executable or not The number of files that should be 755 are limited to (according to linitian) config, postinst, postrm, preinst, and prerm. All others should be 644. So I would say without loss of generality, we can set the permission to 644 except for those config, postinst... files . I can send you a patch based on 76c59007dd3944e23848b7d5912a59a7d3db6398 today (and update the doc accordingly). Is that good for you? Raffi From a.bergmeier at dsfishlabs.com Tue Sep 15 04:39:21 2015 From: a.bergmeier at dsfishlabs.com (Andreas Bergmeier) Date: Tue, 15 Sep 2015 08:39:21 +0000 Subject: [cmake-developers] Python extension to FindProtobuf In-Reply-To: <55F6D5A8.3010601@kitware.com> References: <6B1070FD3B25C348BB7E9CD29C1F16D137E70DCE@flexchange.home.fishlabs.net> <1727564.SG6oXUDnmz@caliban.sf-tec.de> <6B1070FD3B25C348BB7E9CD29C1F16D137E70DF0@flexchange.home.fishlabs.net> <55F31E6E.4010508@kitware.com> <6B1070FD3B25C348BB7E9CD29C1F16D137E7BC63@flexchange.home.fishlabs.net> <55F6D5A8.3010601@kitware.com> Message-ID: <6B1070FD3B25C348BB7E9CD29C1F16D137E7D070@flexchange.home.fishlabs.net> Sorry, found a stashed change, that I missed. With that it works. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Montag, 14. September 2015 16:12 To: Andreas Bergmeier Cc: Rolf Eike Beer; cmake-developers at cmake.org Subject: Re: [cmake-developers] Python extension to FindProtobuf On 09/14/2015 03:42 AM, Andreas Bergmeier wrote: > I now added documentation, removed ARGS and GENERATED property. Thanks. Applied with minor wording tweaks: FindProtobuf: Add protobuf_generate_python function http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=143579c3 -Brad ________________________________ Diese E-mail enth?lt VERTRAULICHE UND PERS?NLICHE INFORMATIONEN und/oder PRIVILEGIERTE UND VERTRAULICHE MITTEILUNGEN, die ausschlie?lich f?r die angesprochenen Empf?nger bestimmt sind. Ohne ausdr?ckliche schriftliche Zustimmung des Absenders d?rfen diese Informationen und Mitteilungen nicht an irgendeinen Dritten au?erhalb der Organisation des Empf?ngers weitergeleitet oder zur Kenntnis gebracht werden. Wenn Sie diese E-mail versehentlich empfangen haben, teilen Sie dies bitte dem Absender umgehend telefonisch oder durch R?cksendung dieser E-mail mit, und zerst?ren Sie die Mail sowie Ihre evtl. R?ckmail bitte anschlie?end, ohne eine Kopie zu erstellen. Koch Media ?bernimmt keinerlei Verantwortung f?r m?gliche Verluste oder Besch?digungen, resultierend aus virus-infizierten E-mails bzw. Viren in Anh?ngen. This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Koch Media accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. -------------- next part -------------- A non-text attachment was scrubbed... Name: commit-ddb5ae6 Type: application/octet-stream Size: 1259 bytes Desc: commit-ddb5ae6 URL: From domen.vrankar at gmail.com Tue Sep 15 05:00:34 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Tue, 15 Sep 2015 11:00:34 +0200 Subject: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive In-Reply-To: References: Message-ID: > From this (thanks to lintian now I have the proper link :) ) > > https://lintian.debian.org/tags/control-file-has-bad-permissions.html > https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners > > all control files: > - should be owned by root:root (+ I would say uid/gid 0/0, because root may > be mapped) which is the case now > - should be 755 or 644, depending if they are executable or not > > The number of files that should be 755 are limited to (according to > linitian) config, postinst, postrm, preinst, and prerm. All others should be > 644. > > So I would say without loss of generality, we can set the permission to 644 > except for those config, postinst... files . I can send you a patch based on > 76c59007dd3944e23848b7d5912a59a7d3db6398 today (and update the doc > accordingly). > > Is that good for you? Sounds good. Those rules are written as guidelines and I'm not certain how often they are broken so could you also add a single variable for toggling between defaults described above and using file permissions as provided? Thanks, Domen From raffi.enficiaud at mines-paris.org Tue Sep 15 08:15:33 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Tue, 15 Sep 2015 14:15:33 +0200 Subject: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive In-Reply-To: References: Message-ID: Le 15/09/15 11:00, Domen Vrankar a ?crit : > > Sounds good. > Those rules are written as guidelines and I'm not certain how often > they are broken so could you also add a single variable for toggling > between defaults described above and using file permissions as > provided? > I think those are not really just "guidelines" if you want ever your source package be published with a cmake toolchain (severity "serious"). Please find attached the "feature" based onto 68dba7f. I added the variable CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION and its component counterpart for controlling strict behaviour on the files added to control.tar.gz . I added a test over lintian again, as I think lintian is the official tool for checking those things. Please note that I was not able to check the produced documentation (although I updated it). I would be happy if you can do it, otherwise I will do tonight. Thanks! Raffi PS.: what about the other patches? -------------- next part -------------- >From 36f273c1e07651060deaea3b576150151ed65818 Mon Sep 17 00:00:00 2001 From: Raffi Enficiaud Date: Tue, 15 Sep 2015 11:26:53 +0200 Subject: [PATCH] fixUp! permissions on control files and strict Debian rules variable --- Modules/CPackDeb.cmake | 30 ++++++++++++++++++++++--- Source/CPack/cmCPackDebGenerator.cxx | 39 ++++++++++++++++++++++++++++++--- Tests/CPackComponentsDEB/CMakeLists.txt | 19 ++++++++++++++++ 3 files changed, 82 insertions(+), 6 deletions(-) diff --git a/Modules/CPackDeb.cmake b/Modules/CPackDeb.cmake index 754df91..43b49f8 100644 --- a/Modules/CPackDeb.cmake +++ b/Modules/CPackDeb.cmake @@ -330,9 +330,30 @@ # .. note:: # # The original permissions of the files will be used in the final -# package. In particular, the scripts should have the proper executable +# package unless the variable +# :variable:`CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION` is set. +# In particular, the scripts should have the proper executable # flag prior to the generation of the package. - +# +# .. variable:: CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION +# CPACK_DEBIAN__PACKAGE_CONTROL_STRICT_PERMISSION +# +# This variable indicates if the Debian policy on control files should be +# strictly followed. +# +# * Mandatory : NO +# * Default : FALSE +# +# Usage:: +# +# set(CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION TRUE) +# +# .. note:: +# +# This overrides the permissions on the original files, following the rules +# set by Debian policy +# https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners +# #============================================================================= # Copyright 2007-2009 Kitware, Inc. @@ -636,7 +657,7 @@ function(cpack_deb_prepare_package_vars) # Are we packaging components ? if(CPACK_DEB_PACKAGE_COMPONENT) # override values with per component version if set - foreach(VAR_NAME_ "PACKAGE_CONTROL_EXTRA") + foreach(VAR_NAME_ "PACKAGE_CONTROL_EXTRA" "PACKAGE_CONTROL_STRICT_PERMISSION") if(CPACK_DEBIAN_${_local_component_name}_${VAR_NAME_}) set(CPACK_DEBIAN_${VAR_NAME_} "${CPACK_DEBIAN_${_local_component_name}_${VAR_NAME_}}") endif() @@ -658,6 +679,7 @@ function(cpack_deb_prepare_package_vars) message("CPackDeb:Debug: CPACK_PACKAGE_FILE_NAME = ${CPACK_PACKAGE_FILE_NAME}") message("CPackDeb:Debug: CPACK_PACKAGE_INSTALL_DIRECTORY = ${CPACK_PACKAGE_INSTALL_DIRECTORY}") message("CPackDeb:Debug: CPACK_TEMPORARY_PACKAGE_FILE_NAME = ${CPACK_TEMPORARY_PACKAGE_FILE_NAME}") + message("CPackDeb:Debug: CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION = ${CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION}") endif() # For debian source packages: @@ -694,6 +716,8 @@ function(cpack_deb_prepare_package_vars) set(GEN_CPACK_DEBIAN_PACKAGE_PROVIDES "${CPACK_DEBIAN_PACKAGE_PROVIDES}" PARENT_SCOPE) set(GEN_CPACK_DEBIAN_PACKAGE_REPLACES "${CPACK_DEBIAN_PACKAGE_REPLACES}" PARENT_SCOPE) set(GEN_CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA "${CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA}" PARENT_SCOPE) + set(GEN_CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION + "${CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION}" PARENT_SCOPE) set(GEN_WDIR "${WDIR}" PARENT_SCOPE) endfunction() diff --git a/Source/CPack/cmCPackDebGenerator.cxx b/Source/CPack/cmCPackDebGenerator.cxx index 981d86d..b497b65 100644 --- a/Source/CPack/cmCPackDebGenerator.cxx +++ b/Source/CPack/cmCPackDebGenerator.cxx @@ -576,9 +576,18 @@ int cmCPackDebGenerator::createDeb() control_tar.SetUNAME("root"); control_tar.SetGNAME("root"); - // set md5sum file permissions to RW-R--R-- so that deb lintian - // doesn't warn about it - control_tar.SetPermissions(S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); + // permissions are set according to +// https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners + // and + // https://lintian.debian.org/tags/control-file-has-bad-permissions.html + const mode_t permission644 = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH; + const mode_t permissionExecute = S_IXUSR | S_IXGRP | S_IXOTH; + const mode_t permission755 = permission644 | permissionExecute; + + // for md5sum and control (that we have generated here), we use 644 + // (RW-R--R--) + // so that deb lintian doesn't warn about it + control_tar.SetPermissions(permission644); // adds control and md5sums if( !control_tar.Add(md5filename, strGenWDIR.length(), ".") @@ -593,12 +602,28 @@ int cmCPackDebGenerator::createDeb() return 0; } + // for the other files, we use + // -either the original permission on the files + // -either a permission strictly defined by the Debian policies const char* controlExtra = this->GetOption("GEN_CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA"); if( controlExtra ) { // permissions are now controlled by the original file permissions + + const bool permissionStrictPolicy = + this->IsSet("GEN_CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION"); + + static const char* strictFiles[] = { + "config", "postinst", "postrm", "preinst", "prerm" + }; + std::set setStrictFiles( + strictFiles, + strictFiles + sizeof(strictFiles)/sizeof(strictFiles[0])); + + // default control_tar.SetPermissions(-1); + std::vector controlExtraList; cmSystemTools::ExpandListArgument(controlExtra, controlExtraList); for(std::vector::iterator i = controlExtraList.begin(); @@ -608,6 +633,14 @@ int cmCPackDebGenerator::createDeb() cmsys::SystemTools::GetFilenameName(*i); std::string localcopy = strGenWDIR + "/" + filenamename; + + if(permissionStrictPolicy) + { + control_tar.SetPermissions(setStrictFiles.count(filenamename) ? + permission755 : permission644); + } + + // if we can copy the file, it means it does exist, let's add it: if( cmsys::SystemTools::CopyFileIfDifferent(*i, localcopy) ) { diff --git a/Tests/CPackComponentsDEB/CMakeLists.txt b/Tests/CPackComponentsDEB/CMakeLists.txt index 5c4eeab..5a5d626 100644 --- a/Tests/CPackComponentsDEB/CMakeLists.txt +++ b/Tests/CPackComponentsDEB/CMakeLists.txt @@ -80,6 +80,25 @@ set(CPACK_COMPONENT_HEADERS_DESCRIPTION # depend on the libraries component. set(CPACK_COMPONENT_HEADERS_DEPENDS libraries) +# creates preinst/prerm scripts with specific permissions. Those permissions +# (especially executable) should be in the final archive +find_program(CHMOD_PROG chmod) +if(CHMOD_PROG) + file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/preinst "echo default_preinst") + file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/prerm "echo default_prerm") + + # Those should have 755 permission normally. We mess it up to see if + # CPACK_DEBIAN_APPLICATIONS_PACKAGE_CONTROL_STRICT_PERMISSION is able to fix + # it. + execute_process(COMMAND ${CHMOD_PROG} 640 ${CMAKE_CURRENT_BINARY_DIR}/preinst) + execute_process(COMMAND ${CHMOD_PROG} 640 ${CMAKE_CURRENT_BINARY_DIR}/prerm) + + set(CPACK_DEBIAN_APPLICATIONS_PACKAGE_CONTROL_EXTRA + "${CMAKE_CURRENT_BINARY_DIR}/preinst;${CMAKE_CURRENT_BINARY_DIR}/prerm") + + set(CPACK_DEBIAN_APPLICATIONS_PACKAGE_CONTROL_STRICT_PERMISSION TRUE) +endif() + # We may use the CPack specific config file in order # to tailor CPack behavior on a CPack generator specific way # (Behavior would be different for RPM or TGZ or DEB ...) -- 2.0.1 From brad.king at kitware.com Tue Sep 15 08:29:49 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 15 Sep 2015 08:29:49 -0400 Subject: [cmake-developers] Python extension to FindProtobuf In-Reply-To: <6B1070FD3B25C348BB7E9CD29C1F16D137E7D070@flexchange.home.fishlabs.net> References: <6B1070FD3B25C348BB7E9CD29C1F16D137E70DCE@flexchange.home.fishlabs.net> <1727564.SG6oXUDnmz@caliban.sf-tec.de> <6B1070FD3B25C348BB7E9CD29C1F16D137E70DF0@flexchange.home.fishlabs.net> <55F31E6E.4010508@kitware.com> <6B1070FD3B25C348BB7E9CD29C1F16D137E7BC63@flexchange.home.fishlabs.net> <55F6D5A8.3010601@kitware.com> <6B1070FD3B25C348BB7E9CD29C1F16D137E7D070@flexchange.home.fishlabs.net> Message-ID: <55F80F3D.30907@kitware.com> On 09/15/2015 04:39 AM, Andreas Bergmeier wrote: > Sorry, found a stashed change, that I missed. With that it works. Okay. I've squashed that in: FindProtobuf: Add protobuf_generate_python function http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2ec97b13 Thanks, -Brad From david.gobbi at gmail.com Tue Sep 15 10:09:28 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 15 Sep 2015 08:09:28 -0600 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks Message-ID: Hi All, I've attached three suggested patches for cmake. The first is trivial, it simply adds Python 3.5 and 3.6 to the search list. The second removes the long-deprecated PYTHON_INCLUDE_PATH as a suggestion for PYTHON_INCLUDE_DIR. The third does two important things: 1) it fixes bugs for searching for specific versions of the libs and headers for framework installs of Python on OS X, and 2) it doesn't search for the include directory until after library has been found, so that it can use the library version to direct the search for the include directory. Any comments on these patches would be appreciated. Cheers, - David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-Python-3.6-3.5-to-the-versions-searched-for.patch Type: application/octet-stream Size: 1361 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Remove-PYTHON_INCLUDE_PATH-as-input-to-FindPythonLib.patch Type: application/octet-stream Size: 1270 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Match-python-include-dir-to-library-version.patch Type: application/octet-stream Size: 4328 bytes Desc: not available URL: From rakuco at FreeBSD.org Tue Sep 15 10:31:12 2015 From: rakuco at FreeBSD.org (Raphael Kubo da Costa) Date: Tue, 15 Sep 2015 16:31:12 +0200 Subject: [cmake-developers] [PATCH] Do not build CMake in C11 mode if _Thread_local support is broken. Message-ID: <1442327472-12533-1-git-send-email-rakuco@FreeBSD.org> Support for C11's _Thread_local was introduced in GCC in the 4.9 series, even though we make the C11 compiler flags available in CMake with GCC >= 4.6. FreeBSD's runetype.h uses _Thread_local, which causes CMake's own build to fail when using GCC < 4.9 and -std=gnu11: /usr/include/runetype.h:92:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'const' extern _Thread_local const _RuneLocale *_ThreadRuneLocale; Add a test for _Thread_local support and only build CMake itself with C11 support if it works. Bug: http://www.cmake.org/Bug/view.php?id=15741 --- CMakeLists.txt | 7 ++++++- Source/Checks/cm_c11_thread_local.c | 2 ++ Source/Checks/cm_c11_thread_local.cmake | 33 +++++++++++++++++++++++++++++++++ 3 files changed, 41 insertions(+), 1 deletion(-) create mode 100644 Source/Checks/cm_c11_thread_local.c create mode 100644 Source/Checks/cm_c11_thread_local.cmake diff --git a/CMakeLists.txt b/CMakeLists.txt index 5e13a7e..94d138c 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -38,7 +38,12 @@ endif() # Use most-recent available language dialects with GNU and Clang if(NOT DEFINED CMAKE_C_STANDARD AND NOT CMake_NO_C_STANDARD) - set(CMAKE_C_STANDARD 11) + include(${CMake_SOURCE_DIR}/Source/Checks/cm_c11_thread_local.cmake) + if(NOT CMake_C11_THREAD_LOCAL_BROKEN) + set(CMAKE_C_STANDARD 11) + else() + set(CMAKE_C_STANDARD 99) + endif() endif() if(NOT DEFINED CMAKE_CXX_STANDARD AND NOT CMake_NO_CXX_STANDARD) include(${CMake_SOURCE_DIR}/Source/Checks/cm_cxx14_cstdio.cmake) diff --git a/Source/Checks/cm_c11_thread_local.c b/Source/Checks/cm_c11_thread_local.c new file mode 100644 index 0000000..ab780f2 --- /dev/null +++ b/Source/Checks/cm_c11_thread_local.c @@ -0,0 +1,2 @@ +_Thread_local int i = 42; +int main(void) { return 0; } diff --git a/Source/Checks/cm_c11_thread_local.cmake b/Source/Checks/cm_c11_thread_local.cmake new file mode 100644 index 0000000..6b8d10b --- /dev/null +++ b/Source/Checks/cm_c11_thread_local.cmake @@ -0,0 +1,33 @@ +set(CMake_C11_THREAD_LOCAL_BROKEN 0) +if(CMAKE_CXX_COMPILER_ID MATCHES "GNU" AND CMAKE_C11_STANDARD_COMPILE_OPTION) + if(NOT DEFINED CMake_C11_THREAD_LOCAL_WORKS) + message(STATUS "Checking if compiler supports C11 _Thread_local") + try_compile(CMake_C11_THREAD_LOCAL_WORKS + ${CMAKE_CURRENT_BINARY_DIR} + ${CMAKE_CURRENT_LIST_DIR}/cm_c11_thread_local.c + CMAKE_FLAGS -DCMAKE_C_STANDARD=11 + OUTPUT_VARIABLE OUTPUT + ) + if(CMake_C11_THREAD_LOCAL_WORKS AND "${OUTPUT}" MATCHES "error: expected '=', ',', ';', 'asm' or '__attribute__' before 'int'") + set_property(CACHE CMake_C11_THREAD_LOCAL_WORKS PROPERTY VALUE 0) + endif() + if(CMake_C11_THREAD_LOCAL_WORKS) + message(STATUS "Checking if compiler supports C11 _Thread_local - yes") + file(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeOutput.log + "Determining if compiler supports C11 _Thread_local passed with the following output:\n" + "${OUTPUT}\n" + "\n" + ) + else() + message(STATUS "Checking if compiler supports C11 _Thread_local - no") + file(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeError.log + "Determining if compiler supports C11 _Thread_local failed with the following output:\n" + "${OUTPUT}\n" + "\n" + ) + endif() + endif() + if(NOT CMake_C11_THREAD_LOCAL_WORKS) + set(CMake_C11_THREAD_LOCAL_BROKEN 1) + endif() +endif() -- 2.5.2 From mantis at public.kitware.com Tue Sep 15 11:15:38 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 15 Sep 2015 11:15:38 -0400 Subject: [cmake-developers] [CMake 0015743]: get_filename_component turns real path to ABSOLUTE path Message-ID: <5d58a7e28d9d363899b6057d056b638a@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15743 ====================================================================== Reported By: Andreas Schuh Assigned To: ====================================================================== Project: CMake Issue ID: 15743 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-15 11:15 EDT Last Modified: 2015-09-15 11:15 EDT ====================================================================== Summary: get_filename_component turns real path to ABSOLUTE path Description: I encountered a very strange behaviour of the get_filename_component using the ABSOLUTE subcommand. The given input path was before turned into a real path with symbolic links resolved using the REALPATH subcommand. Calling get_filename_component with ABSOLUTE on this real path I would have expected an unchanged path. Instead, ABSOLUTE returns a path with symbolic links again! Note that both the source and build directory are located in different symlinked directory paths. Looking at the C++ code of the get_filename_component command revealed some strange call to SystemTools::CheckTranslationPath in SystemTools::CollapseFullPath which implements the ABSOLUTE subcommand. There is also a commented line beforehand with a comment expecting to break something by doing so... the call to SystemTools::AddTranslationPath. The issue affects also previous releases (tried 3.2.2 and 2.8.12.2). IMHO I find it extremely strange that get_filename_component needs such translation table (without having digged deeper to fully understand its purpose). Cleaning a path or splitting it into parts should be a purely string based operation without actual file system information. Steps to Reproduce: 1. Create directory hierarchy with symlinks similar to my scenario: Real source directory: /vol/medic01/users/as12312/Code/CMakeGetFileNameComponentIssue Real build directory: /vol/biomedic/users/as12312/build/merapi/cmake-get_filename_component-issue Symbolic links: /homes/as12312/Code -> /vol/medic01/users/as12312/Code /homes/as12312/opt -> /vol/biomedic/users/as12312 2. Copy attached CMakeLists.txt to the source directory 3. Change into the symlinked build directory and use the symbolic link to the source directory as argument to CMake cd /homes/as12312/opt/build/merapi/cmake-get_filename_component-issue cmake /homes/as12321/Code/CMakeGetFileNameComponentIssue The output is the following: CMAKE_SOURCE_DIR: REALPATH = /vol/medic01/users/as12312/Code/CMakeGetFileNameComponentIssue ABSOLUTE = /vol/medic01/users/as12312/Code/CMakeGetFileNameComponentIssue CMAKE_BINARY_DIR: REALPATH = /vol/biomedic/users/as12312/build/merapi/cmake-get_filename_component-issue ABSOLUTE = /homes/as12312/opt/build/merapi/cmake-get_filename_component-issue -- Configuring done -- Generating done -- Build files have been written to: /homes/as12312/opt/build/merapi/cmake-get_filename_component-issue Note that the ABSOLUTE return value of get_filename_component of the real input path contains symbolic links again! ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-15 11:15 Andreas Schuh New Issue 2015-09-15 11:15 Andreas Schuh File Added: CMakeLists.txt ====================================================================== From JamesJ at motionview3d.com Tue Sep 15 12:01:22 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Tue, 15 Sep 2015 16:01:22 -0000 Subject: [cmake-developers] CMake user-provided manifest files In-Reply-To: <55F72B13.8000306@kitware.com> References: <041501d0eca8$e8cdb2c0$ba691840$@motionview3d.com> <55F318E8.8060603@kitware.com> <55F32560.90608@kitware.com> <55F72B13.8000306@kitware.com> Message-ID: <05df01d0efcf$c4ea42e0$4ebec8a0$@motionview3d.com> > -----Original Message----- > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] > On Behalf Of Brad King > Sent: Monday, September 14, 2015 20:16 > To: James Johnston > Cc: cmake-developers at cmake.org > Subject: Re: [cmake-developers] CMake user-provided manifest files > > On 09/11/2015 11:45 AM, James Johnston wrote: > > Because CMake already does *some* things with the linker it makes it > > impossible for me to cleanly specify and use link.exe manifest-related > > switches myself. For example, it hard-codes usage of link.exe > > /MANIFESTFILE and the user can't specify their own location. And the > > locations it does use are undocumented. > > Is there a use case for doing something with the linker-generated manifest > file other than passing it to a "mt" invocation along with (possibly) user- > specified manifest files? If not then there is no reason to make the manifest > file location public. I can't think of anything like that. The only reason I was using the undocumented linker-generated manifest location was to merge it with my own manifest using mt.exe. So I agree, I can't think of a reason the location needs to be publicly documented/available if CMake can cleanly handle user-provided manifests to merge. Best regards, James Johnston From mantis at public.kitware.com Tue Sep 15 13:21:25 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 15 Sep 2015 13:21:25 -0400 Subject: [cmake-developers] [CMake 0015744]: Spaces in paths with non-ASCII characters are not escaped when using Ninja Message-ID: <157f7b498377b2b7401141e5c5388944@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15744 ====================================================================== Reported By: Thiago M. Assigned To: ====================================================================== Project: CMake Issue ID: 15744 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-15 13:21 EDT Last Modified: 2015-09-15 13:21 EDT ====================================================================== Summary: Spaces in paths with non-ASCII characters are not escaped when using Ninja Description: When using CMake with the Ninja generator to build some source code that is inside a path that contains both spaces and non-ASCII characters, the path is used without escaping the spaces inside the generated Ninja rules files. Steps to Reproduce: 1) Create a sources folder in a path which contains both spaces and non-ASCII characters. Ex: `make /tmp/CMake Ninja Spaces/C?digo` 2) Inside the source folder, create a `CMakeLists.txt` with an `add_executable(main main.cpp)`. 3) Run CMake using the Ninja generator. 4) Check the generated `build.ninja` file. It should have spaces in paths escaped with `$`, like: build CMakeFiles/CMakeNinjaSpaces.dir/main.cpp.o: CXX_COMPILER__CMakeNinjaSpaces /tmp/CMake$ Ninja$ Spaces/C?digo/main.cpp However, it has variables names `identX` with unescaped paths: ident0 = /tmp/CMake Ninja Spaces/C?digo/main.cpp build CMakeFiles/CMakeNinjaSpaces.dir/main.cpp.o: CXX_COMPILER__CMakeNinjaSpaces $ident0 Additional Information: The unescaped paths make Ninja rebuild and relink everything whenever it runs, making incremental builds and the edit-build-test cicle impossible. Steps to reproduce (cont.): 5) Run Ninja on the generated `build.ninja` file. It outputs the progress of files being build: [1/2] Building CXX object CMakeFiles/CMakeNinjaSpaces.dir/main.cpp.o [2/2] Linking CXX executable CMakeNinjaSpaces 6) Run Ninja again. It should do nothing and print: `ninja: no work to do.` However, it does rebuild and relink everything, showing again the progress messages described in step 5. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-15 13:21 Thiago M. New Issue 2015-09-15 13:21 Thiago M. File Added: build.ninja ====================================================================== From mantis at public.kitware.com Tue Sep 15 13:36:38 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 15 Sep 2015 19:36:38 +0200 Subject: [cmake-developers] [CMake 0015745]: Export target with multiple names Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15745 ====================================================================== Reported By: Stephen Kelly Assigned To: ====================================================================== Project: CMake Issue ID: 15745 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-15 19:36 CEST Last Modified: 2015-09-15 19:36 CEST ====================================================================== Summary: Export target with multiple names Description: As discussed in ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-15 19:36 Stephen Kelly New Issue ====================================================================== From steveire at gmail.com Tue Sep 15 13:36:54 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 15 Sep 2015 19:36:54 +0200 Subject: [cmake-developers] Allow ALIAS of IMPORTED targets References: <55F49DC0.5090300@gmail.com> Message-ID: Tam?s Ken?z wrote: >> For example, if an ALIAS can be IMPORTED, does it makes sense that it can > be >> exported with export() and install(EXPORT)? > > Yes: couple of months ago I was adding install(EXPORT) to an existing > CMakeList. The name of the library target which I had to export was not > correct as export target name but I was not able change the library target > name because of backward compatibility. Being able to export an alias > would have helped. I still think exporting should be a follow up to allowing IMPORTED ALIAS. Just too keep the branch and discussion as short as possible. Nevertheless, I think you wouldn't need ALIAS targets for your use-case. They are more than you need. You don't need the aliases anywhere except for exporting. So, we could design something which allows you to export aliases, but be completely separate from ALIAS targets. For example, add_library(foo ${foo_SRCS}) set_target_property(foo EXPORT_NAMES foo foo_old_name) ... install(EXPORT ...) resulting in a generated file containing add_library(foo IMPORTED) ... add_library(foo_old_name IMPORTED) ... where each of the generated targets get the same target properties. Note that there is already an EXPORT_NAME target property http://www.cmake.org/cmake/help/v3.3/prop_tgt/EXPORT_NAME.html but it is not a list, so the task would probably be to deprecate that one and add EXPORT_NAMES. I filed http://public.kitware.com/Bug/view.php?id=15745 Thanks, Steve. From steveire at gmail.com Tue Sep 15 14:24:09 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 15 Sep 2015 20:24:09 +0200 Subject: [cmake-developers] xcode7-defaults-to-c11 topic Message-ID: <55F86249.8050101@gmail.com> Hi Gregor, Thanks for working on this topic. As GNU 6 defaults to C++14, and clang will probably follow suit, I think it is better to determine the default dialect automatically instead of maintaining numbers like that in Modules/. I have merged a Konsole output compute-default-dialect to next for testing which implements the automatic detection. Please test it to see if it works with xcode 7. Thanks, Steve. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Tue Sep 15 15:20:30 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 15 Sep 2015 15:20:30 -0400 Subject: [cmake-developers] [CMake 0015746]: pkg_check_modules should document how to handle spaces in framework names Message-ID: <85abe26df22c364aca2e97fba4d32630@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15746 ====================================================================== Reported By: Dan Kegel Assigned To: ====================================================================== Project: CMake Issue ID: 15746 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-15 15:20 EDT Last Modified: 2015-09-15 15:20 EDT ====================================================================== Summary: pkg_check_modules should document how to handle spaces in framework names Description: pc files don't often have spaces in values, but it does happen (especially on the Mac), and a little guidance would be helpful. http://kegel.com/cmake/spaces-in-framework-names/ is a worked example of how to cope with framework names that contain spaces. The idea is: - the .pc file should use a backslash in front of each space in the name (quotes don't seem to work) - the CMakeLists.txt should use string(REPLACE...) to replace semicolons with spaces and/or single quote marks, as appropriate For instance: string(REPLACE "-framework;foo;bar" "-framework 'foo bar'" foo_LDFLAGS "${foo_LDFLAGS}") Steps to Reproduce: On a mac: $ tar -xzvf spaces-in-framework-names.tgz $ cd spaces-in-framework-names # comment out the string(REPLACE...) in CMakeLists.txt to demonstrate problem $ sh demo.sh ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-15 15:20 Dan Kegel New Issue 2015-09-15 15:20 Dan Kegel File Added: spaces-in-framework-names.tgz ====================================================================== From brad.king at kitware.com Tue Sep 15 16:01:42 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 15 Sep 2015 16:01:42 -0400 Subject: [cmake-developers] [PATCH] Do not build CMake in C11 mode if _Thread_local support is broken. In-Reply-To: <1442327472-12533-1-git-send-email-rakuco@FreeBSD.org> References: <1442327472-12533-1-git-send-email-rakuco@FreeBSD.org> Message-ID: <55F87926.50607@kitware.com> On 09/15/2015 10:31 AM, Raphael Kubo da Costa wrote: > Add a test for _Thread_local support and only build CMake itself with > C11 support if it works. > > Bug: http://www.cmake.org/Bug/view.php?id=15741 Thanks, applied: Avoid using C11 to build CMake if _Thread_local support is broken http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ffa6f057 -Brad From tamas.kenez at gmail.com Tue Sep 15 16:36:25 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Tue, 15 Sep 2015 22:36:25 +0200 Subject: [cmake-developers] Allow ALIAS of IMPORTED targets In-Reply-To: References: <55F49DC0.5090300@gmail.com> Message-ID: Thank you, I was not aware of the EXPORT_NAME target property. Tamas On Tue, Sep 15, 2015 at 7:36 PM, Stephen Kelly wrote: > Tam?s Ken?z wrote: > > >> For example, if an ALIAS can be IMPORTED, does it makes sense that it > can > > be > >> exported with export() and install(EXPORT)? > > > > Yes: couple of months ago I was adding install(EXPORT) to an existing > > CMakeList. The name of the library target which I had to export was not > > correct as export target name but I was not able change the library > target > > name because of backward compatibility. Being able to export an alias > > would have helped. > > I still think exporting should be a follow up to allowing IMPORTED ALIAS. > Just too keep the branch and discussion as short as possible. > > Nevertheless, I think you wouldn't need ALIAS targets for your use-case. > They are more than you need. You don't need the aliases anywhere except for > exporting. So, we could design something which allows you to export > aliases, > but be completely separate from ALIAS targets. > > For example, > > add_library(foo ${foo_SRCS}) > set_target_property(foo EXPORT_NAMES foo foo_old_name) > > ... > > install(EXPORT ...) > > resulting in a generated file containing > > add_library(foo IMPORTED) > ... > > add_library(foo_old_name IMPORTED) > ... > > where each of the generated targets get the same target properties. > > Note that there is already an EXPORT_NAME target property > > http://www.cmake.org/cmake/help/v3.3/prop_tgt/EXPORT_NAME.html > > but it is not a list, so the task would probably be to deprecate that one > and add EXPORT_NAMES. > > I filed > > http://public.kitware.com/Bug/view.php?id=15745 > > 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 daniel.wirtz at simtech.uni-stuttgart.de Wed Sep 16 03:56:28 2015 From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz) Date: Wed, 16 Sep 2015 09:56:28 +0200 Subject: [cmake-developers] C|CXX Standards Handling Message-ID: <55F920AC.2000906@simtech.uni-stuttgart.de> Hello CMake Developers, i've recently encountered an issue with the CMake [CMAKE_]C_STANDARD settings. (same for CXX) For initial background see http://public.kitware.com/pipermail/cmake/2015-September/061546.html Basically, CMake silently continues to configure past any set(CMAKE_C_STANDARD ) command even if CMake does not have any information on the necessary flags for the current compiler. In my case, i've had that issue with the SUPERLU_DIST package and Intel 14.xx compilers. The configure stage would go fine but the compile breaks complaining about all sorts of weird things, from which it was far from obvious it was because of the missing -std=c99 flag. Especially as i've entrusted CMake to handle that situation as i've also specified set(CMAKE_C_STANDARD_REQUIRED YES). I know there's standard flags information right now only for gnu and clang, and having them included for all supported compilers will be a different issue. but i suggest to include the following into cmake: - if there is no standards information for the given compiler, issue a warning to tell the developer just that. - if additionally XX_REQUIRED is set on cmake or target level, throw a fatal error on configure time as cmake cannot ensure to set the correct flags required for the requested C standard. of course, this wont save the user the trouble of finding the correct flags for the current compiler for himself, but at least it's a more informed action than just wondering why suddenly everything breaks which went fine on GNU. this will clearly be redundant once all supported compilers have the necessary information, but would also makes cmake more robust in case new compilers come in without having the standards info contained at the beginning. Cheers Daniel -- Dr. Daniel Wirtz Dipl. Math. Dipl. Inf. SRC SimTech Pfaffenwaldring 5a +49 711 685 60044 From brad.king at kitware.com Wed Sep 16 09:03:40 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 16 Sep 2015 09:03:40 -0400 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: References: Message-ID: <55F968AC.4050705@kitware.com> On 09/15/2015 10:09 AM, David Gobbi wrote: > The first is trivial, it simply adds Python 3.5 and 3.6 to the search list. > > The second removes the long-deprecated PYTHON_INCLUDE_PATH as a suggestion > for PYTHON_INCLUDE_DIR. Thanks. I've applied these two: FindPython{Interp,Libs}: Add versions 3.5 and 3.6 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2db092b1 FindPythonLibs: Remove PYTHON_INCLUDE_PATH as input http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c57334fa > The third does two important things: 1) it fixes bugs for searching for > specific versions of the libs and headers for framework installs of > Python on OS X, and 2) it doesn't search for the include directory > until after library has been found, so that it can use the library > version to direct the search for the include directory. This patch conflicts with post-3.3 changes in CMake 'master'. Please rebase on the above-applied commits and revise accordingly. Thanks, -Brad From david.gobbi at gmail.com Wed Sep 16 10:00:00 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 16 Sep 2015 08:00:00 -0600 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: <55F968AC.4050705@kitware.com> References: <55F968AC.4050705@kitware.com> Message-ID: On Wed, Sep 16, 2015 at 7:03 AM, Brad King wrote: > On 09/15/2015 10:09 AM, David Gobbi wrote: > > The first is trivial, it simply adds Python 3.5 and 3.6 to the search > list. > > > > The second removes the long-deprecated PYTHON_INCLUDE_PATH as a > suggestion > > for PYTHON_INCLUDE_DIR. > > Thanks. I've applied these two: > > FindPython{Interp,Libs}: Add versions 3.5 and 3.6 > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2db092b1 > > FindPythonLibs: Remove PYTHON_INCLUDE_PATH as input > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c57334fa > > > The third does two important things: 1) it fixes bugs for searching for > > specific versions of the libs and headers for framework installs of > > Python on OS X, and 2) it doesn't search for the include directory > > until after library has been found, so that it can use the library > > version to direct the search for the include directory. > > This patch conflicts with post-3.3 changes in CMake 'master'. Please > rebase on the above-applied commits and revise accordingly. > I've attached the rebased patch. It looks like someone had already fixed the framework library search issue, so this new patch only changes the search for the include dirs. Cheers, - David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindPythonLibs-Match-include-dir-to-library-version.patch Type: application/octet-stream Size: 3450 bytes Desc: not available URL: From brad.king at kitware.com Wed Sep 16 11:04:39 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 16 Sep 2015 11:04:39 -0400 Subject: [cmake-developers] CMake user-provided manifest files In-Reply-To: <55F72B13.8000306@kitware.com> References: <041501d0eca8$e8cdb2c0$ba691840$@motionview3d.com> <55F318E8.8060603@kitware.com> <55F32560.90608@kitware.com> <55F72B13.8000306@kitware.com> Message-ID: <55F98507.9050006@kitware.com> On 09/14/2015 04:16 PM, Brad King wrote: > I think our path forward here is to teach the Makefile and Ninja > generators how to add user-specified manifest files to the "mt" > invocations as outlined above. I've drafted support for this in all generators, with a test: Add support for *.manifest source files with MSVC tools http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=74fee403 Please try it out. Thanks, -Brad From brad.king at kitware.com Wed Sep 16 11:39:24 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 16 Sep 2015 11:39:24 -0400 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: References: <55F968AC.4050705@kitware.com> Message-ID: <55F98D2C.8030208@kitware.com> On 09/16/2015 10:00 AM, David Gobbi wrote: > this new patch only changes the search for the include dirs. Thanks. Rather than calling find_path twice, the first call could just use HINTS instead of PATHS. HINTS are meant for this use case: searching paths detected from the system in some manner. They are searched before the generic system and environment paths. Does that work for your use case? Also, why does the second call not use the same list of suffixes? Thanks, -Brad From brad.king at kitware.com Wed Sep 16 11:41:59 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 16 Sep 2015 11:41:59 -0400 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: <55F98D2C.8030208@kitware.com> References: <55F968AC.4050705@kitware.com> <55F98D2C.8030208@kitware.com> Message-ID: <55F98DC7.8080700@kitware.com> On 09/16/2015 11:39 AM, Brad King wrote: > On 09/16/2015 10:00 AM, David Gobbi wrote: >> this new patch only changes the search for the include dirs. > > Thanks. Rather than calling find_path twice, the first call could > just use HINTS instead of PATHS. HINTS are meant for this use case: > searching paths detected from the system in some manner. They are > searched before the generic system and environment paths. Does that > work for your use case? > > Also, why does the second call not use the same list of suffixes? Meanwhile I split out the OS X framework path fix: FindPythonLibs: Fix OS X framework include directory search path http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea2db3bb Please check that it looks correct on its own. -Brad From brad.king at kitware.com Wed Sep 16 13:27:20 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 16 Sep 2015 13:27:20 -0400 Subject: [cmake-developers] compute-default-dialect topic Message-ID: <55F9A678.1010800@kitware.com> Steve, In regard to this topic: Project: Determine default language dialect for the compiler. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=77691638 fixup! Project: Determine default language dialect for the compiler. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=10e937ad fixup! Project: Determine default language dialect for the compiler. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ba7ade5f The default dialect computed with the compiler id may not be the same as the effective default dialect when CMAKE_CXX_FLAGS is considered. One may build with -std=c++11, for example, thus making the dialect used for compilation different than the raw compiler default even when CMake does not add a -std= flag. This is done for CMake itself on some dashboard builds: https://open.cdash.org/viewNotes.php?buildid=4011828 set(RR_FLAGS_C "${RR_FLAGS_COMMON} -std=c11") set(RR_FLAGS_CXX "${RR_FLAGS_COMMON} -std=c++11 -stdlib=libc++") set(ENV{CFLAGS} "${RR_WARNINGS_C} ${RR_FLAGS_C}") set(ENV{CXXFLAGS} "${RR_WARNINGS_CXX} ${RR_FLAGS_CXX}") ... CMake_NO_C_STANDARD:BOOL=1 CMake_NO_CXX_STANDARD:BOOL=1 These builds are where the RunCMake.CompileFeatures test failed with this topic. -Brad From brad.king at kitware.com Wed Sep 16 13:38:46 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 16 Sep 2015 13:38:46 -0400 Subject: [cmake-developers] C|CXX Standards Handling In-Reply-To: <55F920AC.2000906@simtech.uni-stuttgart.de> References: <55F920AC.2000906@simtech.uni-stuttgart.de> Message-ID: <55F9A926.8020507@kitware.com> On 09/16/2015 03:56 AM, Daniel Wirtz wrote: > Basically, CMake silently continues to configure past any > set(CMAKE_C_STANDARD ) command even if CMake does > not have any information on the necessary flags for the current compiler. For reference, this was discussed during the original design in this thread: target_compile_features remaining issues, 2014-04-21 13:16:16 GMT http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9812/focus=9996 IIRC it led to the creation of _STANDARD_REQUIRED. Read through that thread for more details. > there's standard flags information right now only for gnu and clang The list of supported compilers is available in the manual: http://www.cmake.org/cmake/help/v3.3/manual/cmake-compile-features.7.html#supported-compilers It includes GNU, Clang, AppleClang, MSVC, and SunPro right now. > - if there is no standards information for the given compiler, issue a > warning to tell the developer just that. See above thread for why it silently decays. > - if additionally XX_REQUIRED is set on cmake or target level, throw a > fatal error on configure time as cmake cannot ensure > to set the correct flags required for the requested C standard. Steve, do you remember if/why/where we decided to ignore these properties on compilers for which know language standard levels or features are known? -Brad From steveire at gmail.com Wed Sep 16 14:22:03 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 16 Sep 2015 20:22:03 +0200 Subject: [cmake-developers] compute-default-dialect topic References: <55F9A678.1010800@kitware.com> Message-ID: Brad King wrote: > The default dialect computed with the compiler id may not be the > same as the effective default dialect when CMAKE_CXX_FLAGS is > considered. One may build with -std=c++11, for example, thus > making the dialect used for compilation different than the raw > compiler default even when CMake does not add a -std= flag. Thanks for that info! I pushed another fixup which may disable the test in that case, and may also disable it with GNU 6 and other compilers with default standard >= 11. Thanks, Steve. From brad.king at kitware.com Wed Sep 16 14:28:36 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 16 Sep 2015 14:28:36 -0400 Subject: [cmake-developers] compute-default-dialect topic In-Reply-To: References: <55F9A678.1010800@kitware.com> Message-ID: <55F9B4D4.5060400@kitware.com> On 09/16/2015 02:22 PM, Stephen Kelly wrote: >> The default dialect computed with the compiler id may not be the >> same as the effective default dialect when CMAKE_CXX_FLAGS is >> considered. > > I pushed another fixup which may disable the test in that case, and may also > disable it with GNU 6 and other compilers with default standard >= 11. That may fix the trouble for CMake's test suite, but might this also be a problem for projects in general? Actually this could be an existing problem whether CMake computes or memorizes the raw compiler default. If we're making decisions about what flags to add based on CMAKE__STANDARD_DEFAULT, but the user has already specified their own -std= flags in CMAKE__FLAGS, might we end up with the incorrect standard level, or multiple flags? -Brad From steveire at gmail.com Wed Sep 16 15:00:24 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 16 Sep 2015 21:00:24 +0200 Subject: [cmake-developers] compute-default-dialect topic References: <55F9A678.1010800@kitware.com> <55F9B4D4.5060400@kitware.com> Message-ID: Brad King wrote: > On 09/16/2015 02:22 PM, Stephen Kelly wrote: >>> The default dialect computed with the compiler id may not be the >>> same as the effective default dialect when CMAKE_CXX_FLAGS is >>> considered. >> >> I pushed another fixup which may disable the test in that case, and may >> also disable it with GNU 6 and other compilers with default standard >= >> 11. > > That may fix the trouble for CMake's test suite, but might this > also be a problem for projects in general? Actually this could > be an existing problem whether CMake computes or memorizes the > raw compiler default. If we're making decisions about what flags > to add based on CMAKE__STANDARD_DEFAULT, but the user has > already specified their own -std= flags in CMAKE__FLAGS, > might we end up with the incorrect standard level, or multiple > flags? Multiple flags, apparently. I made a project with target_compile_features(hello PRIVATE cxx_decltype_auto) # -std=c++14 and built it with GNU 5.1(default dialect 98). I ran cmake with -DCMAKE_CXX_FLAGS=-std=c++11. The result is that a default of 11 is computed (with my branch) for the CXX_STANDARD_DEFAULT because of the CMAKE_CXX_FLAGS=-std=c++11, but 14 is the requirement, so -std=c++11 -std=gnu++14 appears on the command line. The latter 'wins' in this case. If I instead use target_compile_features(hello PRIVATE cxx_static_assert) # -std=c++11 Then -std=c++11 -std=gnu++11 appears instead, which is consistent with the design of CompileFeatures. Arguably the -std=gnu++11 should not be added in that case, but changing that existing behavior would be a different topic. Thanks, Steve. From brad.king at kitware.com Wed Sep 16 15:14:12 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 16 Sep 2015 15:14:12 -0400 Subject: [cmake-developers] compute-default-dialect topic In-Reply-To: References: <55F9A678.1010800@kitware.com> <55F9B4D4.5060400@kitware.com> Message-ID: <55F9BF84.6040505@kitware.com> On 09/16/2015 03:00 PM, Stephen Kelly wrote: > I ran cmake with -DCMAKE_CXX_FLAGS=-std=c++11. > > The result is that a default of 11 is computed (with my branch) for the > CXX_STANDARD_DEFAULT because of the CMAKE_CXX_FLAGS=-std=c++11, Right. I forgot that we honor CMAKE__FLAGS for the compiler id: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineCompilerId.cmake;hb=v3.3.1#l24 That eliminates my concern. The use of multiple flags is not a big problem because the right one wins, and the user did ask for the "loser" to be there even though the project knows how to add the latter. > -std=c++11 -std=gnu++11 > > appears instead, which is consistent with the design of CompileFeatures. > Arguably the -std=gnu++11 should not be added in that case, but changing > that existing behavior would be a different topic. Yes, and it can be done later if found to be necessary. Thanks, -Brad From steveire at gmail.com Wed Sep 16 15:17:01 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 16 Sep 2015 21:17:01 +0200 Subject: [cmake-developers] C|CXX Standards Handling References: <55F920AC.2000906@simtech.uni-stuttgart.de> <55F9A926.8020507@kitware.com> Message-ID: Brad King wrote: > On 09/16/2015 03:56 AM, Daniel Wirtz wrote: >> Basically, CMake silently continues to configure past any >> set(CMAKE_C_STANDARD ) command even if CMake does >> not have any information on the necessary flags for the current compiler. > > For reference, this was discussed during the original design in > this thread: > > target_compile_features remaining issues, 2014-04-21 13:16:16 GMT > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9812/focus=9996 > > IIRC it led to the creation of _STANDARD_REQUIRED. Read through > that thread for more details. I think _STANDARD_REQUIRED is not related to what Daniel described. Daniel is talking about using a compiler for which no features are recorded at all afaik. >> - if additionally XX_REQUIRED is set on cmake or target level, throw a >> fatal error on configure time as cmake cannot ensure >> to set the correct flags required for the requested C standard. > > Steve, do you remember if/why/where we decided to ignore these properties > on compilers for which know language standard levels or features are > known? A brief search didn't reveal the relevant mailing list thread. I think it was to avoid everyone having to wrap target_compile_features() calls in conditions to avoid errors with unsupported compilers, and with unsupported versions of supported compilers. When the feature was initially added, it did not cover as large a matrix as today. There is information about adding support for compile features at http://www.cmake.org/cmake/help/v3.3/manual/cmake-developer.7.html#adding-compile-features Thanks, Steve. From JamesJ at motionview3d.com Wed Sep 16 15:43:52 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Wed, 16 Sep 2015 19:43:52 -0000 Subject: [cmake-developers] CMake user-provided manifest files In-Reply-To: <55F98507.9050006@kitware.com> References: <041501d0eca8$e8cdb2c0$ba691840$@motionview3d.com> <55F318E8.8060603@kitware.com> <55F32560.90608@kitware.com> <55F72B13.8000306@kitware.com> <55F98507.9050006@kitware.com> Message-ID: <06a401d0f0b8$0503d3d0$0f0b7b70$@motionview3d.com> > -----Original Message----- > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] > On Behalf Of Brad King > Sent: Wednesday, September 16, 2015 15:05 > To: James Johnston; Gilles Khouzam > Cc: cmake-developers at cmake.org > Subject: Re: [cmake-developers] CMake user-provided manifest files > > On 09/14/2015 04:16 PM, Brad King wrote: > > I think our path forward here is to teach the Makefile and Ninja > > generators how to add user-specified manifest files to the "mt" > > invocations as outlined above. > > I've drafted support for this in all generators, with a test: > > Add support for *.manifest source files with MSVC tools > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=74fee403 > > Please try it out. Thanks - looks promising! I tried with Ninja generator from a VS2008 command prompt. But I ran into some issues with paths being converted to relative paths. A sample test case is attached. Build it with the Ninja generator. I also tried VS2008 generator directly. That seems to work without error. The Ninja problem seems to be due to this: >From build.ninja: build subdir\ManTest.exe: C_EXECUTABLE_LINKER__ManTest subdir\CMakeFiles\ManTest.dir\Hello.c.obj | subdir\DPIAware.manifest MANIFESTS = DPIAware.manifest PRE_LINK = cd . Corresponding rule: rule C_EXECUTABLE_LINKER__ManTest command = cmd.exe /C "$PRE_LINK && C:\Users\JamesJ\AppData\Local\Temp\cmake-build\bin\cmake.exe -E vs_link_exe --intdir=$OBJECT_DIR --manifests $MANIFESTS -- C:\PROGRA~2\MICROS~1.0\VC\bin\link.exe && $POST_BUILD" So the problem is the current directory when linking is going to be root CMAKE_BINARY_DIR, and the relative path "DPIAware.manifest" will attempt to be used, which of course isn't there as it needs to look in "subdir\DPIAware.manifest". This leads to this error: DPIAware.manifest : general error c1010070: Failed to load and parse the manifest. The system cannot find the file specified. Best regards, James Johnston -------------- next part -------------- A non-text attachment was scrubbed... Name: ManTest.zip Type: application/x-zip-compressed Size: 1301 bytes Desc: not available URL: From mantis at public.kitware.com Wed Sep 16 16:04:06 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 16 Sep 2015 16:04:06 -0400 Subject: [cmake-developers] [CMake 0015747]: Regression: -Wno-dev doesn't work any more in CMake 3.4 Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15747 ====================================================================== Reported By: James Johnston Assigned To: ====================================================================== Project: CMake Issue ID: 15747 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-16 16:04 EDT Last Modified: 2015-09-16 16:04 EDT ====================================================================== Summary: Regression: -Wno-dev doesn't work any more in CMake 3.4 Description: The -Wno-dev option doesn't work any more in CMake 3.4. Tested on the master branch, commit ID febeabbf0b221a19bd4bf16ba7620af22d8dba17 Steps to Reproduce: 1. Create a simple CMakeLists.txt like this: cmake_minimum_required(VERSION 3.3.0 FATAL_ERROR) project(DevWarn) configure_file(infile outfile dummy_arg) 2. Try to configure it with -Wno-dev: cmake "-GVisual Studio 9 2008" -Wno-dev ..\DevWarn 3. Observe the following error... CMake Warning (dev) at CMakeLists.txt:3 (configure_file): configure_file called with unknown argument(s): dummy_arg This warning is for project developers. Use -Wno-dev to suppress it. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-16 16:04 James Johnston New Issue ====================================================================== From brad.king at kitware.com Wed Sep 16 16:13:13 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 16 Sep 2015 16:13:13 -0400 Subject: [cmake-developers] CMake user-provided manifest files In-Reply-To: <06a401d0f0b8$0503d3d0$0f0b7b70$@motionview3d.com> References: <041501d0eca8$e8cdb2c0$ba691840$@motionview3d.com> <55F318E8.8060603@kitware.com> <55F32560.90608@kitware.com> <55F72B13.8000306@kitware.com> <55F98507.9050006@kitware.com> <06a401d0f0b8$0503d3d0$0f0b7b70$@motionview3d.com> Message-ID: <55F9CD59.1090300@kitware.com> On 09/16/2015 03:43 PM, James Johnston wrote: > So the problem is the current directory when linking is going to be root > CMAKE_BINARY_DIR, and the relative path "DPIAware.manifest" will attempt to > be used, which of course isn't there as it needs to look in > "subdir\DPIAware.manifest". This should fix that: fixup! Add support for *.manifest source files with MSVC tools http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e78b5408 I'll also work on integrating your test case. Thanks, -Brad From gjasny at googlemail.com Wed Sep 16 16:41:04 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 16 Sep 2015 22:41:04 +0200 Subject: [cmake-developers] xcode7-defaults-to-c11 topic In-Reply-To: <55F86249.8050101@gmail.com> References: <55F86249.8050101@gmail.com> Message-ID: <55F9D3E0.5090709@googlemail.com> Hi, On 15/09/15 20:24, Stephen Kelly wrote: > I have merged a Konsole output compute-default-dialect to next for > testing which implements the automatic detection. Please test it to see > if it works with xcode 7. The CompileFeatures test does pass: $ git describe v3.3.1-3005-gf1591ef I compiled and tested with $ export DEVELOPER_DIR=/Applications/Xcode7.app/Contents/Developer $ mkdir _build_xcode7 && cd $_ $ cmake -DCMAKE_OSX_SYSROOT=macosx10.11 -DCMAKE_OSX_DEPLOYMENT_TARGET=10.10 -GXcode .. $ xcodebuild $ bin/Debug/ctest --verbose -R CompileFeatures Thanks, Gregor From mantis at public.kitware.com Wed Sep 16 18:20:19 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 16 Sep 2015 18:20:19 -0400 Subject: [cmake-developers] [CMake 0015748]: Regression: get_target_property dies if a source file does not exist Message-ID: <934db2810ae68c5390f4faef729ccc11@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15748 ====================================================================== Reported By: James Johnston Assigned To: ====================================================================== Project: CMake Issue ID: 15748 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-16 18:20 EDT Last Modified: 2015-09-16 18:20 EDT ====================================================================== Summary: Regression: get_target_property dies if a source file does not exist Description: Previously, in CMake 3.3, one could call get_target_property to retrieve the deprecated LOCATION target property even if not all source files exist yet. Now, in CMake master branch (commit febeabbf0b221a19bd4bf16ba7620af22d8dba17) this does not work under some conditions. The bug is a little tricky to isolate into a test case - e.g. not all calls to get_target_property will die. (e.g. if you call get_target_property from the same dir that creates the target, it seems to work). I am also not sure if the LOCATION property is the only target property affected by this. Even though LOCATION is deprecated, this matters because very recent OpenCV versions still use it (e.g. in OpenCV/cmake/OpenCVGenPkgconfig.cmake). Steps to Reproduce: 1. Create file CMakeLists.txt with this contents: cmake_minimum_required(VERSION 2.6.3) project(SourceTest) add_subdirectory(subdir) # Critical: this needs to happen in root CMakeLists.txt and not inside # the subdir. get_target_property(mypath Hello LOCATION_${CMAKE_BUILD_TYPE}) # Now we create the file later, so you can see, ultimately no error should # happen e.g. during generate phase: configure_file(subdir/Hello.c.in ${CMAKE_CURRENT_BINARY_DIR}/subdir/Hello.c) 2. Create subdir/CMakeLists.txt with this contents: add_executable(Hello ${CMAKE_CURRENT_BINARY_DIR}/Hello.c) 3. The contents of subdir/Hello.c can be a simple Hello World program. (actually the contents do not matter to repro this bug since you don't get to compile phase...). 4. Configure the project: cmake -GNinja ../SourceTest 5. I get this error: CMake Error at subdir/CMakeLists.txt:1 (add_executable): Cannot find source file: C:/Users/JamesJ/Documents/Repositories/OI3D-2/SourceTest-build/subdir/Hello. c Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx -- Configuring incomplete, errors occurred! ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-16 18:20 James Johnston New Issue ====================================================================== From JamesJ at motionview3d.com Wed Sep 16 19:01:53 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Wed, 16 Sep 2015 23:01:53 -0000 Subject: [cmake-developers] CMake user-provided manifest files In-Reply-To: <55F9CD59.1090300@kitware.com> References: <041501d0eca8$e8cdb2c0$ba691840$@motionview3d.com> <55F318E8.8060603@kitware.com> <55F32560.90608@kitware.com> <55F72B13.8000306@kitware.com> <55F98507.9050006@kitware.com> <06a401d0f0b8$0503d3d0$0f0b7b70$@motionview3d.com> <55F9CD59.1090300@kitware.com> Message-ID: <06e701d0f0d3$ae4900d0$0adb0270$@motionview3d.com> > -----Original Message----- > From: Brad King [mailto:brad.king at kitware.com] > Sent: Wednesday, September 16, 2015 20:13 > To: James Johnston; 'Gilles Khouzam' > Cc: cmake-developers at cmake.org > Subject: Re: [cmake-developers] CMake user-provided manifest files > > On 09/16/2015 03:43 PM, James Johnston wrote: > > So the problem is the current directory when linking is going to be > > root CMAKE_BINARY_DIR, and the relative path "DPIAware.manifest" will > > attempt to be used, which of course isn't there as it needs to look in > > "subdir\DPIAware.manifest". > > This should fix that: > > fixup! Add support for *.manifest source files with MSVC tools > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e78b5408 > > I'll also work on integrating your test case. > > Thanks, > -Brad That fixed it; just tested building a pile of projects with both Ninja and VS2008 generators (with VS2008 used with Ninja). Best regards, James Johnston From mantis at public.kitware.com Wed Sep 16 22:51:36 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 16 Sep 2015 22:51:36 -0400 Subject: [cmake-developers] [CMake 0015749]: Make the URL option of ExternalProject_Add to accept lists Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15749 ====================================================================== Reported By: Ilya Assigned To: ====================================================================== Project: CMake Issue ID: 15749 Category: CMake Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-16 22:51 EDT Last Modified: 2015-09-16 22:51 EDT ====================================================================== Summary: Make the URL option of ExternalProject_Add to accept lists Description: It would be handy if one could specify a bunch of mirrors for a specific dependency. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-16 22:51 Ilya New Issue ====================================================================== From david.gobbi at gmail.com Thu Sep 17 01:04:23 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 16 Sep 2015 23:04:23 -0600 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: <55F98DC7.8080700@kitware.com> References: <55F968AC.4050705@kitware.com> <55F98D2C.8030208@kitware.com> <55F98DC7.8080700@kitware.com> Message-ID: On Wed, Sep 16, 2015 at 9:41 AM, Brad King wrote: > On 09/16/2015 11:39 AM, Brad King wrote: > > On 09/16/2015 10:00 AM, David Gobbi wrote: > >> this new patch only changes the search for the include dirs. > > > > Thanks. Rather than calling find_path twice, the first call could > > just use HINTS instead of PATHS. HINTS are meant for this use case: > > searching paths detected from the system in some manner. They are > > searched before the generic system and environment paths. Does that > > work for your use case? > > > > Also, why does the second call not use the same list of suffixes? > > Meanwhile I split out the OS X framework path fix: > > FindPythonLibs: Fix OS X framework include directory search path > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea2db3bb > > Please check that it looks correct on its own. Thanks, looks fine. I've modified my patch so that it only calls find_path once. It uses HINTS to search for the includes in the same prefix as where the library was found, which is probably the best place to start. I've left the framework dirs in PATHS because we don't necessarily want them to have priority, we just want to have them in the search path. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindPythonLibs-Match-include-dir-to-library-version.patch Type: application/octet-stream Size: 2933 bytes Desc: not available URL: From Mike.Pagel at bmw.de Thu Sep 17 05:03:55 2015 From: Mike.Pagel at bmw.de (Mike.Pagel at bmw.de) Date: Thu, 17 Sep 2015 09:03:55 +0000 Subject: [cmake-developers] Timestamp of VS-generator rule files Message-ID: <55FD441CAE5A314D8DD773CF40E1048B14E907BB@smucm57b> Hi, we are running into problems when using add_custom_command() without inputs. The semantics of this is documented as "If DEPENDS is not specified the command will run whenever the OUTPUT is missing", which is exactly what we need. This is working everywhere, but not (cleanly) with VisualStudio generators, which introduce the rule file. The documented behavior is violated if the custom command's output existed before the CMake generator runs. VisualStudio will then always trigger the command, as its input (the rule file) is newer than the outputs. Unfortunately, some of our generators notice that the output does not change and does not touch the output timestamp. This prevents dependent targets from rebuilding, but the generators will be triggered, which is time-consuming. We can think of a number of workarounds for this, but I wanted to see whether there is general agreement that the behavior between non-VS and the VS generators should be identical and according to documentation. A fix in the CMake code could force "old" rule files, which then would never trigger the command on their own. Please let me know, what you think, Mike From brad.king at kitware.com Thu Sep 17 08:49:32 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 17 Sep 2015 08:49:32 -0400 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <55B8D472.2090209@kitware.com> References: <55B6B997.90205@gmail.com> <55B8D472.2090209@kitware.com> Message-ID: <55FAB6DC.3050301@kitware.com> On 07/29/2015 09:26 AM, Brad King wrote: > cmake: Add -W options to control deprecation warnings and errors > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c96fe0b4 This caused a regression: -Wno-dev doesn't work any more in CMake 3.4 http://www.cmake.org/Bug/view.php?id=15747 Please take a look to fix it and extend the test suite accordingly. Thanks, -Brad From brad.king at kitware.com Thu Sep 17 09:44:28 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 17 Sep 2015 09:44:28 -0400 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: References: <55F968AC.4050705@kitware.com> <55F98D2C.8030208@kitware.com> <55F98DC7.8080700@kitware.com> Message-ID: <55FAC3BC.3000608@kitware.com> On 09/17/2015 01:04 AM, David Gobbi wrote: > I've modified my patch Thanks, applied: FindPythonLibs: Match include dir to library version http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=89717916 -Brad From brad.king at kitware.com Thu Sep 17 09:44:47 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 17 Sep 2015 09:44:47 -0400 Subject: [cmake-developers] Timestamp of VS-generator rule files In-Reply-To: <55FD441CAE5A314D8DD773CF40E1048B14E907BB@smucm57b> References: <55FD441CAE5A314D8DD773CF40E1048B14E907BB@smucm57b> Message-ID: <55FAC3CF.2040503@kitware.com> On 09/17/2015 05:03 AM, Mike.Pagel at bmw.de wrote: > force "old" rule files, which then would never trigger the command on their own. Yes, I think that makes sense. Those files are only there because the IDE project files need a place to attach the commands. Care to work on a patch for this? Meanwhile you may be able to work around the problem using a MAIN_DEPENDENCY of your own. -Brad From s.kislinskiy at Dkfz-Heidelberg.de Thu Sep 17 09:51:06 2015 From: s.kislinskiy at Dkfz-Heidelberg.de (Kislinskiy, Stefan) Date: Thu, 17 Sep 2015 15:51:06 +0200 Subject: [cmake-developers] generator expression for path slash conversion Message-ID: <57EE86D11538B44096C712532DBB6C5A0131C2B7AA5E@DKFZEX01.ad.dkfz-heidelberg.de> Sorry for the late answer, I was on vacation. I wrote a SHELL_PATH genex which uses cmOutputConverter->ConvertToOutputFormat(..., SHELL) for the conversion. I decided to name the genex SHELL_PATH instead of TO_SHELL_PATH for the sake of consistency to other genexes like LOWER_CASE. What do you think? If it is okay I would write some documentation as well of course. - Stefan -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Montag, 31. August 2015 21:33 To: Kislinskiy, Stefan Cc: CHEVRIER, Marc; cmake-developers at cmake.org; James Johnston Subject: Re: [cmake-developers] generator expression for path slash conversion (was: ExternalProject: Use native paths as substitute for directory tokens) On 08/31/2015 09:35 AM, Kislinskiy, Stefan wrote: > As there is already a patch for such a genex in bug 15509 and the > discussion in 5939 (both linked below in Brad's reply) started 7 years > ago... It would be a great pity to let this issue seep away again. > What can I do to help fixing this finally? Someone will need to think through and propose a specific genex that does the path conversion that makes sense in this context. I think something like $ may be appropriate. For referencing command line tools (as argv[0]) the C++ side uses code like this now: this->ConvertToOutputFormat(ccg.GetCommand(i), SHELL) This genex should map to the same conversion internally. -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: shell_path_genex.patch Type: application/octet-stream Size: 2171 bytes Desc: shell_path_genex.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CMakeLists.txt URL: From brad.king at kitware.com Thu Sep 17 09:55:51 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 17 Sep 2015 09:55:51 -0400 Subject: [cmake-developers] generator expression for path slash conversion In-Reply-To: <57EE86D11538B44096C712532DBB6C5A0131C2B7AA5E@DKFZEX01.ad.dkfz-heidelberg.de> References: <57EE86D11538B44096C712532DBB6C5A0131C2B7AA5E@DKFZEX01.ad.dkfz-heidelberg.de> Message-ID: <55FAC667.5000901@kitware.com> On 09/17/2015 09:51 AM, Kislinskiy, Stefan wrote: > I wrote a SHELL_PATH genex which uses > cmOutputConverter->ConvertToOutputFormat(..., SHELL) for the conversion. > I decided to name the genex SHELL_PATH instead of TO_SHELL_PATH for the > sake of consistency to other genexes like LOWER_CASE. What do you think? LGTM. > I would write some documentation as well of course. Yes, please. Also please look at extending the test suite to cover it. See Tests/GeneratorExpression for genex unit test examples. If possible we should also have a case that uses it in practice in a way that fails on invocation of an actual native tool if the slashes are wrong. That will confirm not only that the genex does what we expect but that it also solves the problem we're trying to solve. Thanks, -Brad From mantis at public.kitware.com Thu Sep 17 10:13:42 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 17 Sep 2015 10:13:42 -0400 Subject: [cmake-developers] [CMake 0015750]: setting COMPILE_DEFINITIONS_ is broken Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15750 ====================================================================== Reported By: CarlPoirier Assigned To: ====================================================================== Project: CMake Issue ID: 15750 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-17 10:13 EDT Last Modified: 2015-09-17 10:13 EDT ====================================================================== Summary: setting COMPILE_DEFINITIONS_ is broken Description: Setting the compile definitions for a particular configuration does not work using the following command, which should according to http://www.cmake.org/Wiki/CMake_2.6_Notes: set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG SOMEDEFINE) Steps to Reproduce: 1. Unzip the included hello world project. 2. Run "cmake -G "Visual Studio 9 2008" . 3. Open the project in Visual Studio 2008. 4. Go to project properties -> C/C++ -> Preprocessor and see that the definition did not apply. Additional Information: Setting the compile definitions for all configurations does work, though: set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS SOMEDEFINE) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-17 10:13 CarlPoirier New Issue 2015-09-17 10:13 CarlPoirier File Added: CMakeTest.zip ====================================================================== From Mike.Pagel at bmw.de Thu Sep 17 10:06:24 2015 From: Mike.Pagel at bmw.de (Mike.Pagel at bmw.de) Date: Thu, 17 Sep 2015 14:06:24 +0000 Subject: [cmake-developers] Timestamp of VS-generator rule files In-Reply-To: <55FAC3CF.2040503@kitware.com> References: <55FD441CAE5A314D8DD773CF40E1048B14E907BB@smucm57b> <55FAC3CF.2040503@kitware.com> Message-ID: <55FD441CAE5A314D8DD773CF40E1048B14E90A2D@smucm57b> MAIN_DEPENDENCY does not easily work in our case (tried it), unless we change a lot of targets in the project, which is not trivial. I'll be trying to submit a patch, thanks for the offer. In case I have questions like "can I use this API or should I use that one to do X", would this mailing list be the right place to ask? Mike -----Urspr?ngliche Nachricht----- Von: cmake-developers [mailto:cmake-developers-bounces at cmake.org] Im Auftrag von Brad King On 09/17/2015 05:03 AM, Mike.Pagel at bmw.de wrote: > force "old" rule files, which then would never trigger the command on their own. Yes, I think that makes sense. Those files are only there because the IDE project files need a place to attach the commands. Care to work on a patch for this? Meanwhile you may be able to work around the problem using a MAIN_DEPENDENCY of your own. -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 brad.king at kitware.com Thu Sep 17 10:19:44 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 17 Sep 2015 10:19:44 -0400 Subject: [cmake-developers] Timestamp of VS-generator rule files In-Reply-To: <55FD441CAE5A314D8DD773CF40E1048B14E90A2D@smucm57b> References: <55FD441CAE5A314D8DD773CF40E1048B14E907BB@smucm57b> <55FAC3CF.2040503@kitware.com> <55FD441CAE5A314D8DD773CF40E1048B14E90A2D@smucm57b> Message-ID: <55FACC00.9050602@kitware.com> On 09/17/2015 10:06 AM, Mike.Pagel at bmw.de wrote: > would this mailing list be the right place to ask? Yes, and thanks for offering to work on the patch. You can post it here when finished, as described in CONTRIBUTING.rst. Thanks, -Brad From david.gobbi at gmail.com Thu Sep 17 10:43:03 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 17 Sep 2015 08:43:03 -0600 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: <55FAC3BC.3000608@kitware.com> References: <55F968AC.4050705@kitware.com> <55F98D2C.8030208@kitware.com> <55F98DC7.8080700@kitware.com> <55FAC3BC.3000608@kitware.com> Message-ID: On Thu, Sep 17, 2015 at 7:44 AM, Brad King wrote: > > Thanks, applied: > > FindPythonLibs: Match include dir to library version > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=89717916 This should be the last one. It finds the install prefix for PYTHON_EXECUTABLE and uses it as a hint for the library location (on WIN32 it uses ${_prefix}/libs, on other systems it uses ${_prefix}/lib). - David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindPythonLibs-Use-python-executable-prefix-as-a-hin.patch Type: application/octet-stream Size: 2208 bytes Desc: not available URL: From brad.king at kitware.com Thu Sep 17 11:18:27 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 17 Sep 2015 11:18:27 -0400 Subject: [cmake-developers] CTest threshold exceeds 1024 bytes In-Reply-To: <01ff01d0ecb0$3695f1a0$a3c1d4e0$@gmx.at> References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> <55AE4EC3.8050607@kitware.com> <015401d0c402$ea609040$bf21b0c0$@gmx.at> <55AFB35D.4000004@kitware.com> <55B653C4.7090205@kitware.com> <724C2DD1-4024-47E3-91C2-DC086107735C@gmx.at> <55D5F2AB.1000600@kitware.com> <55E4A8A5.2020909@kitware.com> <55F18839.6020709@kitware.com> <6DB7FFE9-93EF-4C3E-AAE4-16DE069BA98E@gmx.at> <55F19B74.6010401@kitware.com> <45DDF6B8-89FE-4932-96E4-F71B0770E2A5@gmx.at> <897B93ED-5B09-4B21-B1D5-05CBC65BB4F6@gmx.at> <55F19E34.5030309@kitware.com> <01ff01d0ecb0$3695f1a0$a3c1d4e0$@gmx.at> Message-ID: <55FAD9C3.2090204@kitware.com> On 09/11/2015 12:37 PM, Roman W?ger wrote: > I added the required command line options, but it doesn't produce > the expected output. It works in a normal environment, but not > in the "CTest test case". Could you have a look at it? We need to distinguish running CTest in dashboard script mode, e.g. "ctest -S dashboard_script.cmake", from the command-line dashboard client mode, e.g. "ctest -M Experimental -T Test". For the dashboard script case we already have some settings. I've now added documentation and tests for them: CTest: Document and test custom output size settings http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b671db13 Your new options are actually for the command-line mode. I've ported the test over to that, and it now works. Applied: CTest: Add options to limit output of passed and failed tests http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8ed641f0 What remains for future work is to make the command-line options also work in script mode when the custom variables are not set by the script. -Brad From brad.king at kitware.com Thu Sep 17 11:32:43 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 17 Sep 2015 11:32:43 -0400 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: References: <55F968AC.4050705@kitware.com> <55F98D2C.8030208@kitware.com> <55F98DC7.8080700@kitware.com> <55FAC3BC.3000608@kitware.com> Message-ID: <55FADD1B.10204@kitware.com> On 09/17/2015 10:43 AM, David Gobbi wrote: > It finds the install prefix for PYTHON_EXECUTABLE > and uses it as a hint for the library location Thanks. I revised the previous patch slightly to add a prefix to the _HINT temporary variable and unset it when finished: FindPythonLibs: Match include dir to library version http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a9d32dff Then I made the same tweak to this patch and applied it: FindPythonLibs: Use python executable prefix as a hint http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f8bc4e11 -Brad From david.gobbi at gmail.com Thu Sep 17 11:38:18 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 17 Sep 2015 09:38:18 -0600 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: <55FADD1B.10204@kitware.com> References: <55F968AC.4050705@kitware.com> <55F98D2C.8030208@kitware.com> <55F98DC7.8080700@kitware.com> <55FAC3BC.3000608@kitware.com> <55FADD1B.10204@kitware.com> Message-ID: On Thu, Sep 17, 2015 at 9:32 AM, Brad King wrote: > On 09/17/2015 10:43 AM, David Gobbi wrote: > > It finds the install prefix for PYTHON_EXECUTABLE > > and uses it as a hint for the library location > > Thanks. I revised the previous patch slightly to add a prefix to > the _HINT temporary variable and unset it when finished: > > FindPythonLibs: Match include dir to library version > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a9d32dff > > Then I made the same tweak to this patch and applied it: > > FindPythonLibs: Use python executable prefix as a hint > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f8bc4e11 Looks good. The _PREFIX temporary variable is still lying around, though. Is that a concern? - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Sep 17 11:46:22 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 17 Sep 2015 09:46:22 -0600 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: <4343364.WKSBUh9Jcv@stryke> References: <55F98DC7.8080700@kitware.com> <4343364.WKSBUh9Jcv@stryke> Message-ID: On Thu, Sep 17, 2015 at 9:08 AM, Clinton Stimpson wrote: > > Hi, > > I did a quick test to see if my issue has been resolved. > > I have a CMakeLists.txt file with just: > FIND_PACKAGE(PythonInterp REQUIRED) > FIND_PACKAGE(PythonLibs ${PYTHON_VERSION_STRING} REQUIRED) > > > And I get this error: > Could NOT find PythonLibs: Found unsuitable version "2.7.2", but required > is at least "2.7.5" (found /usr/lib/libpython2.7.dylib) > > > The problem I have is that I get a python executable and python library > from a > system location, and headers from the SDK, which aren't the exact same > version. > > //Path to a program. > PYTHON_EXECUTABLE:FILEPATH=/usr/bin/python > > //Path to a file. > > PYTHON_INCLUDE_DIR:PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/Python.framework/Headers > > //Path to a library. > PYTHON_LIBRARY:FILEPATH=/usr/lib/libpython2.7.dylib > > > Is that related to issues you are addressing here? > No, the prefix check was meant to fix things for people who use homebrew or other third-party package managers that have their own prefix. It wasn't meant to address the SDK. However, there should be a simple fix for your problem. Just do the following, to allow PythonLibs to apply its own logic for matching just the major and minor version numbers (e.g. 2.7 instead of 2.7.5): FIND_PACKAGE(PythonInterp REQUIRED) FIND_PACKAGE(PythonLibs REQUIRED) - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Sep 17 11:48:43 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 17 Sep 2015 11:48:43 -0400 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: References: <55F968AC.4050705@kitware.com> <55F98D2C.8030208@kitware.com> <55F98DC7.8080700@kitware.com> <55FAC3BC.3000608@kitware.com> <55FADD1B.10204@kitware.com> Message-ID: <55FAE0DB.3000902@kitware.com> On 09/17/2015 11:38 AM, David Gobbi wrote: > The _PREFIX temporary variable is still lying around, though. Please provide a follow-up patch I can squash in for that. Thanks, -Brad From david.gobbi at gmail.com Thu Sep 17 12:03:42 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 17 Sep 2015 10:03:42 -0600 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: <55FAE0DB.3000902@kitware.com> References: <55F968AC.4050705@kitware.com> <55F98D2C.8030208@kitware.com> <55F98DC7.8080700@kitware.com> <55FAC3BC.3000608@kitware.com> <55FADD1B.10204@kitware.com> <55FAE0DB.3000902@kitware.com> Message-ID: On Thu, Sep 17, 2015 at 9:48 AM, Brad King wrote: > > > Please provide a follow-up patch I can squash in for that. > I've renamed the variable _PREFIX -> _Python_PREFIX and now the code unsets it once it's finished with it. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindPythonLibs-unset-temporary-_PREFIX-variable.patch Type: application/octet-stream Size: 2199 bytes Desc: not available URL: From clinton at elemtech.com Thu Sep 17 11:08:12 2015 From: clinton at elemtech.com (Clinton Stimpson) Date: Thu, 17 Sep 2015 09:08:12 -0600 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: References: <55F98DC7.8080700@kitware.com> Message-ID: <4343364.WKSBUh9Jcv@stryke> On Wednesday, September 16, 2015 11:04:23 PM David Gobbi wrote: > On Wed, Sep 16, 2015 at 9:41 AM, Brad King wrote: > > On 09/16/2015 11:39 AM, Brad King wrote: > > > On 09/16/2015 10:00 AM, David Gobbi wrote: > > >> this new patch only changes the search for the include dirs. > > > > > > Thanks. Rather than calling find_path twice, the first call could > > > just use HINTS instead of PATHS. HINTS are meant for this use case: > > > searching paths detected from the system in some manner. They are > > > searched before the generic system and environment paths. Does that > > > work for your use case? > > > > > > Also, why does the second call not use the same list of suffixes? > > > > Meanwhile I split out the OS X framework path fix: > > FindPythonLibs: Fix OS X framework include directory search path > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea2db3bb > > > > Please check that it looks correct on its own. > > Thanks, looks fine. I've modified my patch so that it only calls find_path > once. > It uses HINTS to search for the includes in the same prefix as where the > library > was found, which is probably the best place to start. I've left the > framework dirs > in PATHS because we don't necessarily want them to have priority, we just > want to have them in the search path. > > - David Hi, I did a quick test to see if my issue has been resolved. I have a CMakeLists.txt file with just: FIND_PACKAGE(PythonInterp REQUIRED) FIND_PACKAGE(PythonLibs ${PYTHON_VERSION_STRING} REQUIRED) And I get this error: Could NOT find PythonLibs: Found unsuitable version "2.7.2", but required is at least "2.7.5" (found /usr/lib/libpython2.7.dylib) The problem I have is that I get a python executable and python library from a system location, and headers from the SDK, which aren't the exact same version. //Path to a program. PYTHON_EXECUTABLE:FILEPATH=/usr/bin/python //Path to a file. PYTHON_INCLUDE_DIR:PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/Python.framework/Headers //Path to a library. PYTHON_LIBRARY:FILEPATH=/usr/lib/libpython2.7.dylib Is that related to issues you are addressing here? Thanks, Clint From david.gobbi at gmail.com Thu Sep 17 12:42:45 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 17 Sep 2015 10:42:45 -0600 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: References: <55F98DC7.8080700@kitware.com> <4343364.WKSBUh9Jcv@stryke> Message-ID: On Thu, Sep 17, 2015 at 9:46 AM, David Gobbi wrote: > On Thu, Sep 17, 2015 at 9:08 AM, Clinton Stimpson > wrote: > >> >> Is that related to issues you are addressing here? >> > > No, the prefix check was meant to fix things for people who use homebrew > or other third-party package managers that have their own prefix. It > wasn't > meant to address the SDK. > Okay, Clinton. Now you've made me paranoid that I should be prepending the value of CMAKE_OSX_SYSROOT before the prefix if it isn't already part of the prefix. I don't want to ignore CMAKE_OSX_SYSROOT if it has been set, but unfortunately I don't know all the details of how find_library uses CMAKE_OSX_SYSROOT internally. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Sep 17 12:45:04 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 17 Sep 2015 12:45:04 -0400 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: References: <55F968AC.4050705@kitware.com> <55F98D2C.8030208@kitware.com> <55F98DC7.8080700@kitware.com> <55FAC3BC.3000608@kitware.com> <55FADD1B.10204@kitware.com> <55FAE0DB.3000902@kitware.com> Message-ID: <55FAEE10.3000205@kitware.com> On 09/17/2015 12:03 PM, David Gobbi wrote: > I've renamed the variable _PREFIX -> _Python_PREFIX and now the code > unsets it once it's finished with it. Thanks: FindPythonLibs: unset temporary _PREFIX variable http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=19934b67 -Brad From brad.king at kitware.com Thu Sep 17 12:54:26 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 17 Sep 2015 12:54:26 -0400 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: References: <55F98DC7.8080700@kitware.com> <4343364.WKSBUh9Jcv@stryke> Message-ID: <55FAF042.6090409@kitware.com> On 09/17/2015 12:42 PM, David Gobbi wrote: > Okay, Clinton. Now you've made me paranoid that I should be prepending > the value of CMAKE_OSX_SYSROOT before the prefix if it isn't already > part of the prefix. I don't want to ignore CMAKE_OSX_SYSROOT if it has > been set, but unfortunately I don't know all the details of how find_library > uses CMAKE_OSX_SYSROOT internally. Individual find modules and find_ calls should not have to worry about that. See Modules/Platform/Darwin.cmake for use of the CMAKE_OSX_SYSROOT to set CMAKE_SYSTEM_PREFIX_PATH. -Brad From clinton at elemtech.com Thu Sep 17 12:59:12 2015 From: clinton at elemtech.com (Clinton Stimpson) Date: Thu, 17 Sep 2015 10:59:12 -0600 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: <55FAF042.6090409@kitware.com> References: <55FAF042.6090409@kitware.com> Message-ID: <1492540.fT1UPMnZQM@stryke> On Thursday, September 17, 2015 12:54:26 PM Brad King wrote: > On 09/17/2015 12:42 PM, David Gobbi wrote: > > Okay, Clinton. Now you've made me paranoid that I should be prepending > > the value of CMAKE_OSX_SYSROOT before the prefix if it isn't already > > part of the prefix. I don't want to ignore CMAKE_OSX_SYSROOT if it has > > been set, but unfortunately I don't know all the details of how > > find_library uses CMAKE_OSX_SYSROOT internally. > > Individual find modules and find_ calls should not have to worry > about that. See Modules/Platform/Darwin.cmake for use of the > CMAKE_OSX_SYSROOT to set CMAKE_SYSTEM_PREFIX_PATH. Yeah. However, it does bother me that it found includes from the SDK and a library under /usr/lib. For example, if I use the 10.6 SDK on OS X 10.7, it appears that it would find /usr/lib/libpython.2.7.dylib and headers for python 2.6 under the 10.6 SDK. I guess I can put this in the bug tracker. Clint From david.gobbi at gmail.com Thu Sep 17 13:25:24 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 17 Sep 2015 11:25:24 -0600 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: <1492540.fT1UPMnZQM@stryke> References: <55FAF042.6090409@kitware.com> <1492540.fT1UPMnZQM@stryke> Message-ID: On Thu, Sep 17, 2015 at 10:59 AM, Clinton Stimpson wrote: > > However, it does bother me that it found includes from the SDK and a > library > under /usr/lib. > > For example, if I use the 10.6 SDK on OS X 10.7, it appears that it would > find > /usr/lib/libpython.2.7.dylib and headers for python 2.6 under the 10.6 SDK. > > I guess I can put this in the bug tracker. > It's doing this even after my most recent set of patches? The version mismatch issue is specifically what one of my patches was meant to fix. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Sep 17 13:45:17 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 17 Sep 2015 11:45:17 -0600 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: References: <55FAF042.6090409@kitware.com> <1492540.fT1UPMnZQM@stryke> Message-ID: On Thu, Sep 17, 2015 at 11:25 AM, David Gobbi wrote: > On Thu, Sep 17, 2015 at 10:59 AM, Clinton Stimpson > wrote: > >> >> However, it does bother me that it found includes from the SDK and a >> library >> under /usr/lib. >> >> For example, if I use the 10.6 SDK on OS X 10.7, it appears that it would >> find >> /usr/lib/libpython.2.7.dylib and headers for python 2.6 under the 10.6 >> SDK. >> >> I guess I can put this in the bug tracker. >> > > It's doing this even after my most recent set of patches? The version > mismatch > issue is specifically what one of my patches was meant to fix. > Well, actually, I can guess why this might happen. If you don't ask for a specific version of the libs, then it searches in order from the highest version to the lowest. So it finds 2.7 first, which is not in the SDK. But if you have headers for 2.7 either in the root or in the SDK, it ends up finding the headers for 2.6 instead. Some logic could be added to FindPythonLibs.cmake so that it continues counting down the version number until it finds both a library and an include directory that have matching version numbers (that last bit is what is currently missing from the "break" condition in the count-down loop). Do you want to give it a try? - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Thu Sep 17 13:47:22 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 17 Sep 2015 11:47:22 -0600 Subject: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks In-Reply-To: References: <55FAF042.6090409@kitware.com> <1492540.fT1UPMnZQM@stryke> Message-ID: On Thu, Sep 17, 2015 at 11:45 AM, David Gobbi wrote: > On Thu, Sep 17, 2015 at 11:25 AM, David Gobbi > wrote: > >> On Thu, Sep 17, 2015 at 10:59 AM, Clinton Stimpson >> wrote: >> >>> >>> However, it does bother me that it found includes from the SDK and a >>> library >>> under /usr/lib. >>> >>> For example, if I use the 10.6 SDK on OS X 10.7, it appears that it >>> would find >>> /usr/lib/libpython.2.7.dylib and headers for python 2.6 under the 10.6 >>> SDK. >>> >>> I guess I can put this in the bug tracker. >>> >> >> It's doing this even after my most recent set of patches? The version >> mismatch >> issue is specifically what one of my patches was meant to fix. >> > > Well, actually, I can guess why this might happen. If you don't ask for a > specific version of the libs, then it searches in order from the highest > version > to the lowest. So it finds 2.7 first, which is not in the SDK. But if > you have > Typo: this should say "But if you have no headers..." headers for 2.7 either in the root or in the SDK, it ends up finding the > headers > for 2.6 instead. > > Some logic could be added to FindPythonLibs.cmake so that it continues > counting down the version number until it finds both a library and an > include > directory that have matching version numbers (that last bit is what is > currently > missing from the "break" condition in the count-down loop). Do you want to > give it a try? > > - David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Sep 17 15:04:18 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 17 Sep 2015 15:04:18 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.3.2 available for download Message-ID: We are pleased to announce that CMake 3.3.2 is now available for download. Please use the latest release from our download page: http://www.cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.3.2 since 3.3.1: Brad King (2): Makefile: Print color escapes only when necessary CMake 3.3.2 Chuck Atkins (1): find_*: Fix search order when the environment duplicates some HINTS Daniel Pfeifer (3): cmExtra{Kate,SublimeText}Generator: Remove unused cmXMLSafe includes cmCTest{BZR,GIT,P4}: Remove unused cmXMLSafe includes CTest: Fix XML double-encoding cases Matt McCormick (1): CMakeDetermine{C,CXX}Compiler: Avoid if() auto-dereferene in quoted arguments From domen.vrankar at gmail.com Thu Sep 17 15:21:22 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Thu, 17 Sep 2015 21:21:22 +0200 Subject: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive In-Reply-To: References: Message-ID: > Please find attached the "feature" based onto 68dba7f. I added the variable > CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION and its component counterpart > for controlling strict behaviour on the files added to control.tar.gz . Thanks, applied and squashed patches with some changes to cmArchiveWrite as it was causing compiler warnings regarding signed unsigned conversions: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=3b099fd > PS.: what about the other patches? I'll apply them as soon as this feature is merged to master. Thanks, Domen From mikedld at mikedld.com Thu Sep 17 16:18:06 2015 From: mikedld at mikedld.com (Mike Gelfand) Date: Thu, 17 Sep 2015 23:18:06 +0300 Subject: [cmake-developers] "Inconsistent sizeofcmds" on Mac Message-ID: Hello everyone, I?m using cmake 3.3.1 on Mac 10.10.4. I?m building an executable target on Mac with the following settings: CMAKE_OSX_ARCHITECTURES = i386;x86_64 CMAKE_OSX_DEPLOYMENT_TARGET = 10.5 CMAKE_OSX_SYSROOT = .../MacOSX10.10.sdk Right after build, executable is runnable (from inside the binary dir) and everything?s fine. But once I do `make install`, the executable in the install prefix starts giving out errors: % otool -L /install/prefix/myexecutable ... Inconsistent sizeofcmds Adding INSTALL_RPATH target property (the executable depends on a number of shared libraries) results in another error during `make install`, although the command isn?t failing: % make install ... -- Installing: /tmp/prefix/usr/local/rmmagent/rmmagentd .../install_name_tool: for architecture x86_64 object: /install/prefix/myexecutable malformed object (inconsistent sizeofcmds field in mach header) ... What helps is either a) setting BUILD_WITH_INSTALL_RPATH target property to ON (with obvious inconvenience while debugging) or b) making the executable non-fat (i.e. setting architecture to either i386 or x86_64, but not both; which is not what I want in the end). Is this a defect in cmake? Is there anything I can do to work this around? Regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From clinton at elemtech.com Thu Sep 17 16:44:42 2015 From: clinton at elemtech.com (Clinton Stimpson) Date: Thu, 17 Sep 2015 14:44:42 -0600 Subject: [cmake-developers] "Inconsistent sizeofcmds" on Mac In-Reply-To: References: Message-ID: <1775000.LlafreRZIQ@stryke> On Thursday, September 17, 2015 11:18:06 PM Mike Gelfand wrote: > Hello everyone, > > I?m using cmake 3.3.1 on Mac 10.10.4. I?m building an executable target on > Mac with the following settings: > > CMAKE_OSX_ARCHITECTURES = i386;x86_64 > CMAKE_OSX_DEPLOYMENT_TARGET = 10.5 > CMAKE_OSX_SYSROOT = .../MacOSX10.10.sdk > > Right after build, executable is runnable (from inside the binary dir) and > everything?s fine. But once I do `make install`, the executable in the > install prefix starts giving out errors: > > % otool -L /install/prefix/myexecutable > ... > Inconsistent sizeofcmds > > Adding INSTALL_RPATH target property (the executable depends on a number of > shared libraries) results in another error during `make install`, although > the command isn?t failing: > > % make install > ... > -- Installing: /tmp/prefix/usr/local/rmmagent/rmmagentd > .../install_name_tool: for architecture x86_64 object: > /install/prefix/myexecutable malformed object (inconsistent sizeofcmds > field in mach header) ... > > What helps is either a) setting BUILD_WITH_INSTALL_RPATH target property to > ON (with obvious inconvenience while debugging) or b) making the executable > non-fat (i.e. setting architecture to either i386 or x86_64, but not both; > which is not what I want in the end). > > Is this a defect in cmake? Is there anything I can do to work this around? I'm not sure where the defect is, or how to work around it, without getting more details. I've seen problems similar to this, but not exactly the same as what you are seeing. What I have seen before was discussed here: http://public.kitware.com/pipermail/cmake/2014-October/058868.html Perhaps you can go over that and see if it applies to you. In that case, the bug was in install_name_tool, and there was a simple test case to demonstrate the bug. Apple reported that it was fixed in Xcode 6.3. Clint From raffi.enficiaud at mines-paris.org Thu Sep 17 17:03:56 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Thu, 17 Sep 2015 23:03:56 +0200 Subject: [cmake-developers] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive In-Reply-To: References: Message-ID: Le 17/09/15 21:21, Domen Vrankar a ?crit : >> Please find attached the "feature" based onto 68dba7f. I added the variable >> CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION and its component counterpart >> for controlling strict behaviour on the files added to control.tar.gz . > > Thanks, applied and squashed patches with some changes to > cmArchiveWrite as it was causing compiler warnings regarding signed > unsigned conversions: > http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=3b099fd > >> PS.: what about the other patches? > > I'll apply them as soon as this feature is merged to master. Super, thanks! Raffi From mikedld at mikedld.com Thu Sep 17 17:17:05 2015 From: mikedld at mikedld.com (Mike Gelfand) Date: Fri, 18 Sep 2015 00:17:05 +0300 Subject: [cmake-developers] "Inconsistent sizeofcmds" on Mac In-Reply-To: <1775000.LlafreRZIQ@stryke> References: <1775000.LlafreRZIQ@stryke> Message-ID: <667BEA04-A228-4ADF-8226-4ED6EACAB7BB@mikedld.com> On Sep 17, 2015, at 11:44 PM, Clinton Stimpson wrote: > I'm not sure where the defect is, or how to work around it, without getting > more details. > > I've seen problems similar to this, but not exactly the same as what you are > seeing. What I have seen before was discussed here: > http://public.kitware.com/pipermail/cmake/2014-October/058868.html > > Perhaps you can go over that and see if it applies to you. > In that case, the bug was in install_name_tool, and there was a simple test > case to demonstrate the bug. Apple reported that it was fixed in Xcode 6.3. The first command there (otool -l ... | fgrep -A2 LC_RPATH) doesn?t print anything on the installed executable, which is expected. Your test case doesn?t lead to an error either. Not sure what details do you need exactly. I?m currently using Xcode 6.4, Clang reports Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn). For installed executables, output of `otool -l myexecutable` with ?i386;x86_64? and ?x86_64? architectures is exactly the same except for ?Inconsistent sizeofcmds? line printed last in the former case. For executable in binary directory and executable in install prefix, output of `otool -arch all -l myexecutable` with ?i386;x86_64? architectures differs in that the former has Load command 28 cmd LC_RPATH cmdsize 104 path /some/.../other/.../dir/.../lib (offset 12) (for each architecture) which is expected; everything else is exactly the same. Regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From michael.scott250 at gmail.com Thu Sep 17 17:24:25 2015 From: michael.scott250 at gmail.com (Michael Scott) Date: Thu, 17 Sep 2015 22:24:25 +0100 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <55FAB6DC.3050301@kitware.com> References: <55FAB6DC.3050301@kitware.com> Message-ID: <55FB2F89.1000400@gmail.com> On 17/09/2015 13:49, Brad King wrote: > This caused a regression: > > -Wno-dev doesn't work any more in CMake 3.4 > http://www.cmake.org/Bug/view.php?id=15747 > > Please take a look to fix it and extend the test suite accordingly. > > Thanks, > -Brad Ah okay, I've replicated it on my Linux development environment, so I'll try and have a look over the weekend and find out what's going on. Cheers, Michael From mikedld at mikedld.com Thu Sep 17 18:30:02 2015 From: mikedld at mikedld.com (Mike Gelfand) Date: Fri, 18 Sep 2015 01:30:02 +0300 Subject: [cmake-developers] "Inconsistent sizeofcmds" on Mac In-Reply-To: <1775000.LlafreRZIQ@stryke> References: <1775000.LlafreRZIQ@stryke> Message-ID: <5E4C47CE-4313-4335-A765-C2971F715CAB@mikedld.com> Hello, > On Sep 17, 2015, at 11:44 PM, Clinton Stimpson wrote: > > On Thursday, September 17, 2015 11:18:06 PM Mike Gelfand wrote: >> Hello everyone, >> >> I?m using cmake 3.3.1 on Mac 10.10.4. I?m building an executable target on >> Mac with the following settings: >> >> CMAKE_OSX_ARCHITECTURES = i386;x86_64 >> CMAKE_OSX_DEPLOYMENT_TARGET = 10.5 >> CMAKE_OSX_SYSROOT = .../MacOSX10.10.sdk >> >> Right after build, executable is runnable (from inside the binary dir) and >> everything?s fine. But once I do `make install`, the executable in the >> install prefix starts giving out errors: >> >> % otool -L /install/prefix/myexecutable >> ... >> Inconsistent sizeofcmds >> >> Adding INSTALL_RPATH target property (the executable depends on a number of >> shared libraries) results in another error during `make install`, although >> the command isn?t failing: >> >> % make install >> ... >> -- Installing: /tmp/prefix/usr/local/rmmagent/rmmagentd >> .../install_name_tool: for architecture x86_64 object: >> /install/prefix/myexecutable malformed object (inconsistent sizeofcmds >> field in mach header) ... >> >> What helps is either a) setting BUILD_WITH_INSTALL_RPATH target property to >> ON (with obvious inconvenience while debugging) or b) making the executable >> non-fat (i.e. setting architecture to either i386 or x86_64, but not both; >> which is not what I want in the end). >> >> Is this a defect in cmake? Is there anything I can do to work this around? > > I'm not sure where the defect is, or how to work around it, without getting > more details. > > I've seen problems similar to this, but not exactly the same as what you are > seeing. What I have seen before was discussed here: > http://public.kitware.com/pipermail/cmake/2014-October/058868.html > > Perhaps you can go over that and see if it applies to you. > In that case, the bug was in install_name_tool, and there was a simple test > case to demonstrate the bug. Apple reported that it was fixed in Xcode 6.3. With Clint?s help it became clear that it is a bug in install_name_tool after all. I reproduced the issue with Xcode 6.4 and 7.0, using the same commands as at link above except adding `-arch i386 -arch x86_64` to gcc command line. Bug reported to Apple and awaits their reply. Thanks, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cooch at mail.ru Fri Sep 18 08:07:44 2015 From: cooch at mail.ru (=?UTF-8?B?RG1pdHJ5IEtvY2hraW4=?=) Date: Fri, 18 Sep 2015 15:07:44 +0300 Subject: [cmake-developers] =?utf-8?q?CPack/NSIS_is_broken_after_extended_?= =?utf-8?q?length_paths_fix?= Message-ID: <1442578064.600197960@f177.i.mail.ru> Hi Clinton, I was looking into an issue that we have in CMake on Windows with extended paths and later on realized that you've fixed it. However I've realized that you fixed it only in cmSystemTools, which fixes e.g. INSTALL, but does not fix cpack. Actually it's even worse because in current master HEAD I can see that INST_DIR is empty in generated project: ? !define INST_DIR "" (not sure if that's caused by your change) I've figured out that NSIS was not going to fix this (see http://sourceforge.net/p/nsis/feature-requests/241/ ) I've made a small patch to NSIS generator and template to put infamous \\?\ there. I can send directly to you as I guess you know more about these parts of code. Best regards, Dmitry Kochkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Fri Sep 18 09:37:36 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 18 Sep 2015 09:37:36 -0400 Subject: [cmake-developers] [CMake 0015751]: cmake Qt moc files' autogen failed with Q_OBJECT in source code comments Message-ID: <2e4af7b639be758ad0808db2f3945b9f@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15751 ====================================================================== Reported By: Dmitriy V. Shmykov Assigned To: ====================================================================== Project: CMake Issue ID: 15751 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-18 09:37 EDT Last Modified: 2015-09-18 09:37 EDT ====================================================================== Summary: cmake Qt moc files' autogen failed with Q_OBJECT in source code comments Description: When I compile my source code which contains the text "Q_OBJECT" in C++ comments cmake fails with the error text "AUTOGEN: error: .cpp: The file contains a Q_OBJECT macro, but does not include .moc" Steps to Reproduce: create a project with set(CMAKE_AUTOMOC ON) and C++ source code file containing comments with "Q_OBJECT" substring. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-18 09:37 Dmitriy V. ShmykovNew Issue ====================================================================== From brad.king at kitware.com Fri Sep 18 10:19:04 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 18 Sep 2015 10:19:04 -0400 Subject: [cmake-developers] CMake user-provided manifest files In-Reply-To: <06e701d0f0d3$ae4900d0$0adb0270$@motionview3d.com> References: <041501d0eca8$e8cdb2c0$ba691840$@motionview3d.com> <55F318E8.8060603@kitware.com> <55F32560.90608@kitware.com> <55F72B13.8000306@kitware.com> <55F98507.9050006@kitware.com> <06a401d0f0b8$0503d3d0$0f0b7b70$@motionview3d.com> <55F9CD59.1090300@kitware.com> <06e701d0f0d3$ae4900d0$0adb0270$@motionview3d.com> Message-ID: <55FC1D58.7050809@kitware.com> On 09/16/2015 07:01 PM, James Johnston wrote: > That fixed it; just tested building a pile of projects with both Ninja and > VS2008 generators (with VS2008 used with Ninja). Great, thanks for testing. A revision of the commit is now in 'master': Add support for *.manifest source files with MSVC tools http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e134e53b -Brad From clinton at elemtech.com Fri Sep 18 11:31:03 2015 From: clinton at elemtech.com (clinton at elemtech.com) Date: Fri, 18 Sep 2015 09:31:03 -0600 (MDT) Subject: [cmake-developers] CPack/NSIS is broken after extended length paths fix In-Reply-To: <1442578064.600197960@f177.i.mail.ru> References: <1442578064.600197960@f177.i.mail.ru> Message-ID: <1970033140.95595166.1442590263154.JavaMail.zimbra@elemtech.com> ----- On Sep 18, 2015, at 6:07 AM, Dmitry Kochkin wrote: > Hi Clinton, > I was looking into an issue that we have in CMake on Windows with extended paths > and later on realized that you've fixed it. > However I've realized that you fixed it only in cmSystemTools, which fixes e.g. > INSTALL, but does not fix cpack. Yes, I was fixing the 'install' to work with paths > 260 characters, and was using the cpack archive generator at the time. With the path to the build tree, plus the "_CPackPackage/....", some of these paths can become quite long. > Actually it's even worse because in current master HEAD I can see that INST_DIR > is empty in generated project: > !define INST_DIR "" > (not sure if that's caused by your change) Interesting... Do you know why this happens? How is this problem related to extended paths (with the \\?\ prefix)? Do you have an example to demonstrate this problem? > I've figured out that NSIS was not going to fix this (see > http://sourceforge.net/p/nsis/feature-requests/241/ ) Maybe they'll accept a patch to fix it there? Was there any effort to fix it there? > I've made a small patch to NSIS generator and template to put infamous \\?\ > there. > I can send directly to you as I guess you know more about these parts of code. You can send your patch to this mailing list for review. Clint -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Sep 18 14:24:20 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 18 Sep 2015 14:24:20 -0400 Subject: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version In-Reply-To: References: Message-ID: <55FC56D4.2000204@kitware.com> On 09/10/2015 07:24 PM, Gilles Khouzam wrote: > This patch adds a simple version manifest Source\cmake.version.manifest > to the CMake executables. After working out the support for manifests across all generators as discussed elsewhere in this thread, I've added your manifest file to CMake's own build: Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8 (#15674) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cdd15551 Thanks, -Brad From Gilles.Khouzam at microsoft.com Fri Sep 18 14:25:42 2015 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Fri, 18 Sep 2015 18:25:42 +0000 Subject: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version In-Reply-To: <55FC56D4.2000204@kitware.com> References: <55FC56D4.2000204@kitware.com> Message-ID: Great. Thanks -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Friday, September 18, 2015 11:24 To: Gilles Khouzam Cc: cmake-developers at cmake.org Subject: Re: [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version On 09/10/2015 07:24 PM, Gilles Khouzam wrote: > This patch adds a simple version manifest > Source\cmake.version.manifest to the CMake executables. After working out the support for manifests across all generators as discussed elsewhere in this thread, I've added your manifest file to CMake's own build: Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8 (#15674) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cdd15551 Thanks, -Brad From JamesJ at motionview3d.com Fri Sep 18 14:58:37 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Fri, 18 Sep 2015 18:58:37 -0000 Subject: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version In-Reply-To: <55FC56D4.2000204@kitware.com> References: <55FC56D4.2000204@kitware.com> Message-ID: <089001d0f244$073053d0$1590fb70$@motionview3d.com> > -----Original Message----- > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] > On Behalf Of Brad King > Sent: Friday, September 18, 2015 18:24 > To: Gilles Khouzam > Cc: cmake-developers at cmake.org > Subject: Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: > Correctly determine Windows version > > On 09/10/2015 07:24 PM, Gilles Khouzam wrote: > > This patch adds a simple version manifest > > Source\cmake.version.manifest to the CMake executables. > > After working out the support for manifests across all generators as > discussed elsewhere in this thread, I've added your manifest file to CMake's > own build: > > Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8 (#15674) > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cdd15551 While on the subject, there are some other additions to the manifest you might want to consider. The above block will disable UAC heuristics on Windows Vista and above, such that elevation won't ever be requested. It will also disable the Program Compatibility Assistant for Vista IIRC. (as I understand it, supportedOS wasn't added until Windows 7. Why there is a GUID in there for Vista, I'm not sure. App manifests are not the best documented thing on MSDN IMHO.) It would probably be appropriate to use this for all CMake executables. The above block will declare a preference to use the newer common controls library introduced with Windows XP. Without this, Windows will fall back on the old Windows 2000 era of common controls (i.e. Windows 95 style buttons). This would be appropriate for cmake-gui. Since it uses Qt though, the effect is probably minimal, but if some API were called such that native Win32 controls were used somewhere, this would improve the appearance. True/PM The above block will make the cmake-gui DPI aware, such that DPI virtualization is disabled on Windows Vista and above. In laymen's terms, it fixes "blurry text". It looks like Qt already does this (I just tested CMake 3.3 on a high DPI profile.) See http://doc.qt.io/qt-5/highdpi.html. Probably they do it by calling the SetProcessDpiAwareness function. However, this API has some caveats; from MSDN: " The SetProcessDPIAware function in Windows Vista and later versions sets the current process as DPI-aware. However, the use of the SetProcessDPIAware function is discouraged. For example, if a DLL caches DPI settings during initialization, invoking SetProcessDPIAware in your application might generate a possible race condition. For this reason, we recommend that an application enable DPI awareness by using the application's assembly manifest rather than by calling SetProcessDPIAware." --- https://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).a spx And also: " If you use the SetProcessDpiAwareness method to set the DPI awareness level, you must call SetProcessDpiAwareness prior to any Win32API call that forces the system to begin virtualization." The safer path seems to me to be put it in the manifest, as recommended by MSFT. Note there are two possible values: "True" and "True/PM". "PM" stands for per-monitor DPI aware (introduced with Windows 8.1). Looks like Qt supports PM now, but since it was introduced in Windows 8.1, probably only very recent versions of Qt. You'd have to be careful what is in the manifest agrees with the version of Qt being used. (e.g. you don't want to declare "True/PM" on a non-PM older version of Qt, else no per-monitor scaling would happen at all - virtualized or otherwise). Since Qt does call SetProcessDPIAware and cmake-gui does seem to scale OK right now, including this block may end up being a little "pointless" in practice, despite the caveats from MSDN above. Finally there is this block; I'm not exactly sure which versions of Windows might actually require this or what. I'm a little fuzzy on why I included it. Most of the built-in Windows accessories seem to have this in their manifests though. IIRC it's especially needed with the common controls manifest block. Best regards, James Johnston From Robert.Goulet at autodesk.com Fri Sep 18 15:49:51 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Fri, 18 Sep 2015 19:49:51 +0000 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: <55F19C7E.50704@kitware.com> References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> Message-ID: Here's a version that is more conservative. It doesn't change the install(EXPORT) behavior. install(TARGET) already supported genex, so basically this patch adds install(FILES) destination genex. Perhaps we should update the Help to only mention install(FILES) destination instead of all variations of install? I don't have time to work on install(EXPORT) yet. I think it would still be good to have install(FILES) merged even if install(EXPORT) isn't done yet. Thanks! -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Thursday, September 10, 2015 11:07 AM To: Robert Goulet Cc: cmake-developers at cmake.org Subject: Re: Generator expressions for install destination On 09/09/2015 12:21 PM, Robert Goulet wrote: > Here's the patch to add generator expressions to the install command > DESTINATION option. Thanks for the update. >>This should not be needed if things are factored correctly. >>Everything in that block already passes "config" through as a parameter. > > None of the places where I use GetDestination, except in > cmInstallTargetGenerator, receives a config in parameter. > An ideally, the ConfigurationName member should not even exist, but > that will force all places to pass the config as a parameter. > Imho it's better to keep refactoring in a separate patch. I think such a separate refactoring patch should come first. I cannot review the logic with confidence because I don't know what implicitly depends on ConfigurationName being set and whether call paths leading to it set it correctly. Also, take a look at the install(EXPORT) case. I tried using a $ genex in the DESTINATION argument with your patch but it fails trying to create a directory with literal $ in its name (on Windows with a VS generator). Note that the install(EXPORT) command generates some files in the build tree packed away under CMakeFiles/Export and then adds cmake_install.cmake rules to install those. Generation of these files needs to expand the generator expression in time. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: install-dest-genex.patch Type: application/octet-stream Size: 24499 bytes Desc: install-dest-genex.patch URL: From domen.vrankar at gmail.com Fri Sep 18 16:34:54 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Fri, 18 Sep 2015 22:34:54 +0200 Subject: [cmake-developers] [CPackDeb] use of internal md5sum function In-Reply-To: References: Message-ID: > Please find attached a patch on CPackDeb > - which calls the internal function for md5sum computation > - which prevents the hash of the symlinks > > I believe this fixes the issue (partially or totally) > > https://public.kitware.com/Bug/view.php?id=13386 > Applied with minor changes to lintian test result verification: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=7c7874c8 Thanks, Domen From andreas.schuh.84 at gmail.com Fri Sep 18 20:03:27 2015 From: andreas.schuh.84 at gmail.com (Andreas Schuh) Date: Sat, 19 Sep 2015 01:03:27 +0100 Subject: [cmake-developers] Allow ALIAS of IMPORTED targets In-Reply-To: References: <55F49DC0.5090300@gmail.com> Message-ID: Hi, Being able to alias imported targets would be a great feature. Just an addition to the exports discussion, I also don't think it is necessary. Besides the EXPORT_NAME property I was not aware of either, I would instead expect to see an add_library (old_name ALIAS new_name) in the ProjectConfig.cmake(.in) file after importing the new_name library target. This would make it more clear that it is just an alias for the actual new exported/imported target. Also no need to maintain copies of identical imported target properties. I would find this more appealing than exporting the same target twice but with different name. I would think this was just done before because of the missing ability to alias an imported target. Andreas On 15 Sep 2015 21:36, "Tam?s Ken?z" wrote: > Thank you, I was not aware of the EXPORT_NAME target property. > Tamas > > On Tue, Sep 15, 2015 at 7:36 PM, Stephen Kelly wrote: > >> Tam?s Ken?z wrote: >> >> >> For example, if an ALIAS can be IMPORTED, does it makes sense that it >> can >> > be >> >> exported with export() and install(EXPORT)? >> > >> > Yes: couple of months ago I was adding install(EXPORT) to an existing >> > CMakeList. The name of the library target which I had to export was not >> > correct as export target name but I was not able change the library >> target >> > name because of backward compatibility. Being able to export an alias >> > would have helped. >> >> I still think exporting should be a follow up to allowing IMPORTED ALIAS. >> Just too keep the branch and discussion as short as possible. >> >> Nevertheless, I think you wouldn't need ALIAS targets for your use-case. >> They are more than you need. You don't need the aliases anywhere except >> for >> exporting. So, we could design something which allows you to export >> aliases, >> but be completely separate from ALIAS targets. >> >> For example, >> >> add_library(foo ${foo_SRCS}) >> set_target_property(foo EXPORT_NAMES foo foo_old_name) >> >> ... >> >> install(EXPORT ...) >> >> resulting in a generated file containing >> >> add_library(foo IMPORTED) >> ... >> >> add_library(foo_old_name IMPORTED) >> ... >> >> where each of the generated targets get the same target properties. >> >> Note that there is already an EXPORT_NAME target property >> >> http://www.cmake.org/cmake/help/v3.3/prop_tgt/EXPORT_NAME.html >> >> but it is not a list, so the task would probably be to deprecate that one >> and add EXPORT_NAMES. >> >> I filed >> >> http://public.kitware.com/Bug/view.php?id=15745 >> >> 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 >> > > > -- > > 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 michael.scott250 at gmail.com Sat Sep 19 18:32:53 2015 From: michael.scott250 at gmail.com (Michael Scott) Date: Sat, 19 Sep 2015 23:32:53 +0100 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <55FB2F89.1000400@gmail.com> References: <55FB2F89.1000400@gmail.com> Message-ID: <55FDE295.5020605@gmail.com> Investigating the issue a bit more, I can see why it's happening for the given example. When I made those changes, I only modified the "message" CMake command, to check the CMAKE_WARN/ERROR_DEPRECATED and CMAKE_SUPPRESS_DEVELOPER_WARNINGS variables before outputting the message. The message command uses cmake::IssueMessage to actually output the required message. What I wasn't aware of was that other commands and code also use the IssueMessage for outputting author and deprecated messages. As the IssueMessage command doesn't check those variables, or the new warning levels map, before outputting the message, that's why we're seeing this behaviour. What I wanted to check before coming up with a fix, is whether the -W options are intended to only be applicable for the message command (and so the current behaviour is correct), or whether they should affect all author and deprecated messages output by other parts of CMake? If the current behaviour isn't correct, then one thing to have a good think about, is how to handle turning warnings into errors when -Werr-dev or -Werr-deprecated (and also the required behaviour when -Wno- is used). As some users of IssueMessage do different things if an error occurs (and is output), *after* IssueMessage is called. So there might need to be a way to signal to the caller when a warning has been upgraded to an error because of the users options perhaps? Cheers, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Sun Sep 20 05:00:38 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 20 Sep 2015 05:00:38 -0400 Subject: [cmake-developers] [CMake 0015752]: CPackRPM leave @PROTECTED_AT@ in rpm spec Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15752 ====================================================================== Reported By: danblack Assigned To: ====================================================================== Project: CMake Issue ID: 15752 Category: CPack Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-20 05:00 EDT Last Modified: 2015-09-20 05:00 EDT ====================================================================== Summary: CPackRPM leave @PROTECTED_AT@ in rpm spec Description: Related issue where patch was introduced http://public.kitware.com/Bug/view.php?id=14063 diff -u _CPack_Packages/Linux/RPM/SPECS/MariaDB-server.spec.in _CPack_Packages/Linux/RPM/SPECS/MariaDB-server.spec - at CPACK_RPM_INSTALL_FILES@ - at CPACK_RPM_ABSOLUTE_INSTALL_FILES@ - at CPACK_RPM_USER_INSTALL_FILES@ +%dir "/etc/my.cnf.d" +"/usr/sbin/rcmysql" +"/usr/sbin/mysqld" +%dir "/usr/lib/systemd" +%dir "/usr/lib/systemd/system" +%dir "/usr/lib/systemd/system/mariadb at PROTECTED_AT@bootstrap.service.d" Steps to Reproduce: 1. CMakeLists.txt INSTALL(FILES ${CMAKE_CURRENT_SOURCE_DIR}/mariadb-bootstrap.conf DESTINATION ${SYSTEMD_SYSTEM_CONFDIR}/mariadb at bootstrap.service.d/ COMPONENT Server ) 2. error: Directory not found: /home/dan/software_projects/mariadb-server/_CPack_Packages/Linux/RPM/MariaDB-10.1.8-centos5-x86_64/server/usr/lib/systemd/system/mariadb at PROTECTED_AT@bootstrap.service.d Directory not found: /home/dan/software_projects/mariadb-server/_CPack_Packages/Linux/RPM/MariaDB-10.1.8-centos5-x86_64/server/usr/lib/systemd/system/mariadb at PROTECTED_AT@bootstrap.service.d ... CPack Error: Error when generating package: MariaDB Makefile:96: recipe for target 'package' failed make: *** [package] Error 1 Additional Information: patch --- /usr/share/cmake/Modules/CPackRPM.cmake.orig 2015-09-20 16:58:41.218835125 +1000 +++ /usr/share/cmake/Modules/CPackRPM.cmake 2015-09-20 18:42:52.023543458 +1000 @@ -1184,6 +1184,7 @@ # - either because the user asked for it : CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE # - or the user did not provide one : NOT CPACK_RPM_USER_BINARY_SPECFILE if(CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE OR NOT CPACK_RPM_USER_BINARY_SPECFILE) + string(REPLACE "\@PROTECTED_AT\@" "@" CPACK_RPM_INSTALL_FILES "${CPACK_RPM_INSTALL_FILES}") file(WRITE ${CPACK_RPM_BINARY_SPECFILE}.in "# -*- rpm-spec -*- BuildRoot: \@CPACK_RPM_DIRECTORY\@/\@CPACK_PACKAGE_FILE_NAME\@\@CPACK_RPM_PACKAGE_COMPONENT_PART_PATH\@ ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-20 05:00 danblack New Issue ====================================================================== From dpb at corrigendum.ru Sun Sep 20 14:03:59 2015 From: dpb at corrigendum.ru (=?UTF-8?q?=D0=A0=D0=BE=D0=BC=D0=B0=D0=BD=20=D0=94=D0=BE=D0=BD=D1=87=D0=B5=D0=BD=D0=BA=D0=BE?=) Date: Sun, 20 Sep 2015 21:03:59 +0300 Subject: [cmake-developers] [PATCH] CPack: add a new setting, CPACK_VERBATIM_VARIABLES Message-ID: <1442772239-6888-1-git-send-email-dpb@corrigendum.ru> If it's set to a true value, CPack will escape all variables for the CMake parser when writing them out to configuration files. This parallels the VERBATIM argument to add_custom_command. The cpack_encode_variables macro is changed into a function to remove scope pollution. There should be no other effects. --- Help/release/dev/CPack-updates.rst | 5 +++ Modules/CPack.cmake | 43 ++++++++++++++++++++----- Tests/RunCMake/CPackConfig/RunCMakeTest.cmake | 2 ++ Tests/RunCMake/CPackConfig/Special-check.cmake | 5 +++ Tests/RunCMake/CPackConfig/Special.cmake | 3 ++ Tests/RunCMake/CPackConfig/Verbatim-check.cmake | 10 ++++++ Tests/RunCMake/CPackConfig/Verbatim.cmake | 5 +++ 7 files changed, 65 insertions(+), 8 deletions(-) create mode 100644 Tests/RunCMake/CPackConfig/Special-check.cmake create mode 100644 Tests/RunCMake/CPackConfig/Special.cmake create mode 100644 Tests/RunCMake/CPackConfig/Verbatim-check.cmake create mode 100644 Tests/RunCMake/CPackConfig/Verbatim.cmake diff --git a/Help/release/dev/CPack-updates.rst b/Help/release/dev/CPack-updates.rst index 7ac1ed7..ea0780f 100644 --- a/Help/release/dev/CPack-updates.rst +++ b/Help/release/dev/CPack-updates.rst @@ -4,3 +4,8 @@ CPack-updates * The :module:`CPack` module no longer mangles settings with CMake-special characters when they're used as defaults for other settings. The macro ``cpack_set_if_not_set``, which was responsible for this, is now deprecated. + +* The :module:`CPack` module gained a new setting, ``CPACK_VERBATIM_VARIABLES``, + which can be used to ensure the cpack program receives the settings' values + exactly as they were set, even if they contain CMake-special characters. + For compatibility, it's off by default. diff --git a/Modules/CPack.cmake b/Modules/CPack.cmake index 7d6d54c..ea5283c 100644 --- a/Modules/CPack.cmake +++ b/Modules/CPack.cmake @@ -182,6 +182,14 @@ # will be a boolean variable which enables stripping of all files (a list # of files evaluates to TRUE in CMake, so this change is compatible). # +# .. variable:: CPACK_VERBATIM_VARIABLES +# +# If set to a true value, the other variables' values will be escaped before +# being written to the configuration files, so that the cpack program receives +# them exactly as they were specified. If not, characters like quotes and +# backslashes can cause parsing errors or alter the value received by the +# cpack program. Defaults to FALSE for backwards compatibility. +# # The following CPack variables are specific to source packages, and # will not affect binary packages: # @@ -305,21 +313,28 @@ macro(cpack_set_if_not_set name value) _cpack_set_default("${name}" "${value}") endmacro() -# cpack_encode_variables - Macro to encode variables for the configuration file +# cpack_encode_variables - Function to encode variables for the configuration file # find any variable that starts with CPACK and create a variable # _CPACK_OTHER_VARIABLES_ that contains SET commands for # each cpack variable. _CPACK_OTHER_VARIABLES_ is then # used as an @ replacment in configure_file for the CPackConfig. -macro(cpack_encode_variables) - set(_CPACK_OTHER_VARIABLES_) +function(cpack_encode_variables) + set(commands "") get_cmake_property(res VARIABLES) foreach(var ${res}) if(var MATCHES "^CPACK") - set(_CPACK_OTHER_VARIABLES_ - "${_CPACK_OTHER_VARIABLES_}\nSET(${var} \"${${var}}\")") + if(CPACK_VERBATIM_VARIABLES) + _cpack_escape_for_cmake(value "${${var}}") + else() + set(value "${${var}}") endif() + + set(commands "${commands}\nSET(${var} \"${value}\")") + endif() endforeach() -endmacro() + + set(_CPACK_OTHER_VARIABLES_ "${commands}" PARENT_SCOPE) +endfunction() # Internal use functions function(_cpack_set_default name value) @@ -328,6 +343,11 @@ function(_cpack_set_default name value) endif() endfunction() +function(_cpack_escape_for_cmake var value) + string(REGEX REPLACE "([\\\$\"])" "\\\\\\1" escaped "${value}") + set("${var}" "${escaped}" PARENT_SCOPE) +endfunction() + # Set the package name _cpack_set_default(CPACK_PACKAGE_NAME "${CMAKE_PROJECT_NAME}") _cpack_set_default(CPACK_PACKAGE_VERSION_MAJOR "0") @@ -608,8 +628,15 @@ _cpack_set_default(CPACK_SOURCE_INSTALLED_DIRECTORIES _cpack_set_default(CPACK_SOURCE_TOPLEVEL_TAG "${CPACK_SYSTEM_NAME}-Source") _cpack_set_default(CPACK_SOURCE_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION}-Source") -_cpack_set_default(CPACK_SOURCE_IGNORE_FILES - "/CVS/;/\\\\.svn/;/\\\\.bzr/;/\\\\.hg/;/\\\\.git/;\\\\.swp$;\\\\.#;/#") + +set(__cpack_source_ignore_files_default + "/CVS/;/\\.svn/;/\\.bzr/;/\\.hg/;/\\.git/;\\.swp$;\\.#;/#") +if(NOT CPACK_VERBATIM_VARIABLES) + _cpack_escape_for_cmake(__cpack_source_ignore_files_default + "${__cpack_source_ignore_files_default}") +endif() +_cpack_set_default(CPACK_SOURCE_IGNORE_FILES "${__cpack_source_ignore_files_default}") + set(CPACK_INSTALL_CMAKE_PROJECTS "${CPACK_SOURCE_INSTALL_CMAKE_PROJECTS}") set(CPACK_INSTALLED_DIRECTORIES "${CPACK_SOURCE_INSTALLED_DIRECTORIES}") set(CPACK_GENERATOR "${CPACK_SOURCE_GENERATOR}") diff --git a/Tests/RunCMake/CPackConfig/RunCMakeTest.cmake b/Tests/RunCMake/CPackConfig/RunCMakeTest.cmake index ef018b5..16d2cf3 100644 --- a/Tests/RunCMake/CPackConfig/RunCMakeTest.cmake +++ b/Tests/RunCMake/CPackConfig/RunCMakeTest.cmake @@ -2,3 +2,5 @@ include(RunCMake) run_cmake(Simple) run_cmake(Default) +run_cmake(Special) +run_cmake(Verbatim) diff --git a/Tests/RunCMake/CPackConfig/Special-check.cmake b/Tests/RunCMake/CPackConfig/Special-check.cmake new file mode 100644 index 0000000..0624b79 --- /dev/null +++ b/Tests/RunCMake/CPackConfig/Special-check.cmake @@ -0,0 +1,5 @@ +include(${RunCMake_SOURCE_DIR}/check.cmake) + +test_variable(CPACK_BACKSLASH "\\") +test_variable(CPACK_QUOTE "a;b;c") +test_variable(CPACK_DOLLAR "ab") diff --git a/Tests/RunCMake/CPackConfig/Special.cmake b/Tests/RunCMake/CPackConfig/Special.cmake new file mode 100644 index 0000000..9442c93 --- /dev/null +++ b/Tests/RunCMake/CPackConfig/Special.cmake @@ -0,0 +1,3 @@ +set(CPACK_BACKSLASH "\\\\") +set(CPACK_QUOTE "a\" b \"c") +set(CPACK_DOLLAR "a\${NOTHING}b") diff --git a/Tests/RunCMake/CPackConfig/Verbatim-check.cmake b/Tests/RunCMake/CPackConfig/Verbatim-check.cmake new file mode 100644 index 0000000..958547d --- /dev/null +++ b/Tests/RunCMake/CPackConfig/Verbatim-check.cmake @@ -0,0 +1,10 @@ +include(${RunCMake_SOURCE_DIR}/check.cmake) + +test_variable(CPACK_BACKSLASH "\\\\") +test_variable(CPACK_QUOTE "a\" b \"c") +test_variable(CPACK_DOLLAR "a\${NOTHING}b") + +# make sure the default for this is still set correctly with +# CPACK_VERBATIM_VARIABLES on +test_variable(CPACK_SOURCE_IGNORE_FILES + "/CVS/;/\\.svn/;/\\.bzr/;/\\.hg/;/\\.git/;\\.swp$;\\.#;/#") diff --git a/Tests/RunCMake/CPackConfig/Verbatim.cmake b/Tests/RunCMake/CPackConfig/Verbatim.cmake new file mode 100644 index 0000000..4d271c3 --- /dev/null +++ b/Tests/RunCMake/CPackConfig/Verbatim.cmake @@ -0,0 +1,5 @@ +set(CPACK_VERBATIM_VARIABLES YES) + +set(CPACK_BACKSLASH "\\\\") +set(CPACK_QUOTE "a\" b \"c") +set(CPACK_DOLLAR "a\${NOTHING}b") -- 1.9.5.msysgit.0 From domen.vrankar at gmail.com Sun Sep 20 17:47:39 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Sun, 20 Sep 2015 23:47:39 +0200 Subject: [cmake-developers] [PATCH] CPack: add a new setting, CPACK_VERBATIM_VARIABLES In-Reply-To: <1442772239-6888-1-git-send-email-dpb@corrigendum.ru> References: <1442772239-6888-1-git-send-email-dpb@corrigendum.ru> Message-ID: 2015-09-20 20:03 GMT+02:00 ????? ???????? : > If it's set to a true value, CPack will escape all variables for the CMake > parser when writing them out to configuration files. This parallels the > VERBATIM argument to add_custom_command. > > The cpack_encode_variables macro is changed into a function to remove > scope pollution. There should be no other effects. Applied with minor variable description changes to next for testing: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=bc2e54d Thanks, Domen From cooch at mail.ru Mon Sep 21 05:28:37 2015 From: cooch at mail.ru (=?UTF-8?B?RG1pdHJ5IEtvY2hraW4=?=) Date: Mon, 21 Sep 2015 12:28:37 +0300 Subject: [cmake-developers] =?utf-8?q?CPack/NSIS_is_broken_after_extended_?= =?utf-8?q?length_paths_fix?= In-Reply-To: <1970033140.95595166.1442590263154.JavaMail.zimbra@elemtech.com> References: <1442578064.600197960@f177.i.mail.ru> <1970033140.95595166.1442590263154.JavaMail.zimbra@elemtech.com> Message-ID: <1442827717.919671104@f161.i.mail.ru> Hi Clint, >>Actually it's even worse because in current master HEAD I can see that INST_DIR is empty in generated project: >>? !define INST_DIR "" >>(not sure if that's caused by your change) >Interesting... Do you know why this happens? ?How is this problem?related to extended paths (with the \\?\ prefix)? ?Do you have an example to demonstrate this problem? That was my mistake, please ignore. >>I've figured out that NSIS was not going to fix this (see http://sourceforge.net/p/nsis/feature-requests/241/ ) > >Maybe they'll accept a patch to fix it there? ?Was there any effort to fix it there? In the URL I've put they claim you should just use "\\?\" in your NSIS project. I guess it's also possible to fix NSIS, but we cannot rely that user have latest NSIS. > >> >>I've made a small patch to NSIS generator and template to put infamous \\?\ there. >> >>I can send directly to you as I guess you know more about these parts of code. > >You can send your?patch to this mailing list for review. Patch attached. It's a bit hacky, more fixing symptoms I guess. The purpose is only to demonstrate the idea. Let me know if it can be done in better way. Regards, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nsis_fix.patch Type: application/x-patch Size: 2773 bytes Desc: not available URL: From brad.king at kitware.com Mon Sep 21 08:47:15 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Sep 2015 08:47:15 -0400 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <55FDE295.5020605@gmail.com> References: <55FB2F89.1000400@gmail.com> <55FDE295.5020605@gmail.com> Message-ID: <55FFFC53.8030309@kitware.com> On 09/19/2015 06:32 PM, Michael Scott wrote: > whether the -W options are intended to only be applicable > for the message command (and so the current behaviour is correct), > or whether they should affect all author and deprecated messages > output by other parts of CMake? The -Wdev/-Wno-dev options have always been for all messages output by any part of CMake. This needs to be preserved/corrected. > If the current behaviour isn't correct, then one thing to have a > good think about, is how to handle turning warnings into errors > when -Werr-dev or -Werr-deprecated (and also the required behaviour > when -Wno- is used). As some users of IssueMessage do different > things if an error occurs (and is output), *after* IssueMessage > is called. So there might need to be a way to signal to the caller > when a warning has been upgraded to an error because of the users > options perhaps? Likely yes. This may require sweeping changes to address. We're too close to the freeze for 3.4 to do this now. Perhaps we should simply remove -Werr-dev for now. Thanks, -Brad From mantis at public.kitware.com Mon Sep 21 08:49:13 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 21 Sep 2015 08:49:13 -0400 Subject: [cmake-developers] [CMake 0015753]: CMake cannot detect changes in nested header files when using '-iquote' Message-ID: <458d08fb1efaf23a863d996ceb6917a9@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15753 ====================================================================== Reported By: danilcha Assigned To: ====================================================================== Project: CMake Issue ID: 15753 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-21 08:49 EDT Last Modified: 2015-09-21 08:49 EDT ====================================================================== Summary: CMake cannot detect changes in nested header files when using '-iquote' Description: Create a new project with such CMakeLists.txt: cmake_minimum_required(VERSION 3.3) project(test) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -iquote ${CMAKE_CURRENT_SOURCE_DIR}") add_executable(test-iquote main.cpp dir/1.h dir/2.h) And such structure: CMakeLists.txt Main.cpp (contains #include "dir/1.h") dir\ 1.h (contains #include "dir/2.h") 2.h Build. Then modify 2.h. Build again. Nothing will happen, it will just say '[100%] Built target test-iquote'. Additional Information: Tried with both clang and GCC. GNU Make 3.81. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-21 08:49 danilcha New Issue ====================================================================== From clinton at elemtech.com Mon Sep 21 08:56:27 2015 From: clinton at elemtech.com (Clinton Stimpson) Date: Mon, 21 Sep 2015 06:56:27 -0600 Subject: [cmake-developers] CPack/NSIS is broken after extended length paths fix In-Reply-To: <1442827717.919671104@f161.i.mail.ru> References: <1442578064.600197960@f177.i.mail.ru> <1970033140.95595166.1442590263154.JavaMail.zimbra@elemtech.com> <1442827717.919671104@f161.i.mail.ru> Message-ID: <33565947.QeHYnEHunC@stryke> On Monday, September 21, 2015 12:28:37 PM Dmitry Kochkin wrote: > Hi Clint, > > >>Actually it's even worse because in current master HEAD I can see that > >>INST_DIR is empty in generated project: !define INST_DIR "" > >>(not sure if that's caused by your change) > > > >Interesting... Do you know why this happens? How is this problem related > >to extended paths (with the \\?\ prefix)? Do you have an example to > >demonstrate this problem? That was my mistake, please ignore.> > >>I've figured out that NSIS was not going to fix this (see > >>http://sourceforge.net/p/nsis/feature-requests/241/ )> > >Maybe they'll accept a patch to fix it there? Was there any effort to fix > >it there? > In the URL I've put they claim you should just use "\\?\" in your NSIS > project. I guess it's also possible to fix NSIS, but we cannot rely that > user have latest NSIS. Using "\\?\" in a NSIS project is a workaround, not a fix. If a workaround is put into CMake, then you are relying on the latest CMake, right? > >>I've made a small patch to NSIS generator and template to put infamous > >>\\?\ there. > >> > >>I can send directly to you as I guess you know more about these parts of > >>code.> > >You can send your patch to this mailing list for review. > > Patch attached. It's a bit hacky, more fixing symptoms I guess. The purpose > is only to demonstrate the idea. Let me know if it can be done in better > way. Yes, it fixes symptoms. The correct and robust way to fix this is to fix NSIS. I have concerns with this patch: 1. Are the paths cleaned before placed into the NSIS template? Only clean paths can be prepended with \\?\. For example, these paths may not contain "." or "../" in them. 2. This patch can break UNC paths. UNC paths must be prepended with a "\\? \UNC\" prefix instead of "\\?\". If CPACK_TEMPORARY_DIRECTORY is a UNC path, this patch breaks it. 3. For the uninstall code put into the NSIS template, how do you know whether INSTDIR is a UNC path or not? INSTDIR is determined by the end-user when installing the software. Blindly prepending "\\?\" may not work all the time. Clint From s.kislinskiy at Dkfz-Heidelberg.de Mon Sep 21 10:05:27 2015 From: s.kislinskiy at Dkfz-Heidelberg.de (Kislinskiy, Stefan) Date: Mon, 21 Sep 2015 16:05:27 +0200 Subject: [cmake-developers] generator expression for path slash conversion In-Reply-To: <55FAC667.5000901@kitware.com> References: <57EE86D11538B44096C712532DBB6C5A0131C2B7AA5E@DKFZEX01.ad.dkfz-heidelberg.de> <55FAC667.5000901@kitware.com> Message-ID: <57EE86D11538B44096C712532DBB6C5A0131C2B7AC4B@DKFZEX01.ad.dkfz-heidelberg.de> I wrote the documentation and extended the GeneratorExpression tests for the SHELL_PATH genex. It works fine for WIN32 and UNIX. However, I'm having some trouble to test for MSYS. The check looks like: if(MSYS) check(test_shell_path "/c/shell/path") elseif(WIN32) check(test_shell_path "c:\\\\shell\\\\path") elseif(UNIX) check(test_shell_path "c:/shell/path") endif() No matter what I'm doing, it always ends up in the WIN32 branch with FORWARD slashes. Additionally the drive letter is NOT converted to a posix path as it should be the case for MSYS. I tried MSYS from the official MinGW package, and I tried the MSYS2 installer. In both cases I called cmake from MinGW-sh, MSYS-sh, and even cmd.exe. I used the "MSYS Makefiles" Generator. In addition I tried the "MinGW Makefiles" generator just to check if "if(MINGW)" is working... which also fails. The configuring/generating itself is working.. Any ideas? Stefan -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Donnerstag, 17. September 2015 15:56 To: Kislinskiy, Stefan Cc: CHEVRIER, Marc; cmake-developers at cmake.org; James Johnston Subject: Re: [cmake-developers] generator expression for path slash conversion On 09/17/2015 09:51 AM, Kislinskiy, Stefan wrote: > I wrote a SHELL_PATH genex which uses > cmOutputConverter->ConvertToOutputFormat(..., SHELL) for the conversion. > I decided to name the genex SHELL_PATH instead of TO_SHELL_PATH for > the sake of consistency to other genexes like LOWER_CASE. What do you think? LGTM. > I would write some documentation as well of course. Yes, please. Also please look at extending the test suite to cover it. See Tests/GeneratorExpression for genex unit test examples. If possible we should also have a case that uses it in practice in a way that fails on invocation of an actual native tool if the slashes are wrong. That will confirm not only that the genex does what we expect but that it also solves the problem we're trying to solve. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: shell_path_genex_v2.patch Type: application/octet-stream Size: 5640 bytes Desc: shell_path_genex_v2.patch URL: From brad.king at kitware.com Mon Sep 21 10:16:34 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Sep 2015 10:16:34 -0400 Subject: [cmake-developers] generator expression for path slash conversion In-Reply-To: <57EE86D11538B44096C712532DBB6C5A0131C2B7AC4B@DKFZEX01.ad.dkfz-heidelberg.de> References: <57EE86D11538B44096C712532DBB6C5A0131C2B7AA5E@DKFZEX01.ad.dkfz-heidelberg.de> <55FAC667.5000901@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AC4B@DKFZEX01.ad.dkfz-heidelberg.de> Message-ID: <56001142.8070004@kitware.com> On 09/21/2015 10:05 AM, Kislinskiy, Stefan wrote: > if(MSYS) > check(test_shell_path "/c/shell/path") > elseif(WIN32) > check(test_shell_path "c:\\\\shell\\\\path") > elseif(UNIX) > check(test_shell_path "c:/shell/path") > endif() > > No matter what I'm doing, it always ends up in the WIN32 branch > with FORWARD slashes. Additionally the drive letter is NOT converted to a posix path as it should be the case for MSYS. I tried MSYS from the official MinGW package, and I tried the MSYS2 installer. In both cases I called cmake from MinGW-sh, MSYS-sh, and even cmd.exe. I used the "MSYS Makefiles" Generator. In addition I tried the "MinGW Makefiles" generator just to check if "if(MINGW)" is working... which also fails. The configuring/generating itself is working.. Any ideas? The code in the check-part4.cmake script runs in a cmake script (via "cmake -P"). That does not have any information about the configuration of the project, generator used, or target platform. If you need this information it needs to be passed in through additional "-Dvar=val" arguments prior to the -P argument. -Brad From s.kislinskiy at Dkfz-Heidelberg.de Mon Sep 21 10:21:44 2015 From: s.kislinskiy at Dkfz-Heidelberg.de (Kislinskiy, Stefan) Date: Mon, 21 Sep 2015 16:21:44 +0200 Subject: [cmake-developers] generator expression for path slash conversion In-Reply-To: <56001142.8070004@kitware.com> References: <57EE86D11538B44096C712532DBB6C5A0131C2B7AA5E@DKFZEX01.ad.dkfz-heidelberg.de> <55FAC667.5000901@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AC4B@DKFZEX01.ad.dkfz-heidelberg.de> <56001142.8070004@kitware.com> Message-ID: <57EE86D11538B44096C712532DBB6C5A0131C2B7AC52@DKFZEX01.ad.dkfz-heidelberg.de> Ah, thank you very much! I was confused as the distinction between WIN32 and UNIX worked nevertheless. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Montag, 21. September 2015 16:17 To: Kislinskiy, Stefan Cc: CHEVRIER, Marc; cmake-developers at cmake.org; James Johnston Subject: Re: [cmake-developers] generator expression for path slash conversion On 09/21/2015 10:05 AM, Kislinskiy, Stefan wrote: > if(MSYS) > check(test_shell_path "/c/shell/path") > elseif(WIN32) > check(test_shell_path "c:\\\\shell\\\\path") > elseif(UNIX) > check(test_shell_path "c:/shell/path") > endif() > > No matter what I'm doing, it always ends up in the WIN32 branch with > FORWARD slashes. Additionally the drive letter is NOT converted to a posix path as it should be the case for MSYS. I tried MSYS from the official MinGW package, and I tried the MSYS2 installer. In both cases I called cmake from MinGW-sh, MSYS-sh, and even cmd.exe. I used the "MSYS Makefiles" Generator. In addition I tried the "MinGW Makefiles" generator just to check if "if(MINGW)" is working... which also fails. The configuring/generating itself is working.. Any ideas? The code in the check-part4.cmake script runs in a cmake script (via "cmake -P"). That does not have any information about the configuration of the project, generator used, or target platform. If you need this information it needs to be passed in through additional "-Dvar=val" arguments prior to the -P argument. -Brad From brad.king at kitware.com Mon Sep 21 10:51:47 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Sep 2015 10:51:47 -0400 Subject: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version In-Reply-To: <55FC56D4.2000204@kitware.com> References: <55FC56D4.2000204@kitware.com> Message-ID: <56001983.4070306@kitware.com> On 09/18/2015 02:24 PM, Brad King wrote: > After working out the support for manifests across all generators > as discussed elsewhere in this thread, I've added your manifest > file to CMake's own build: > > Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8 (#15674) > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cdd15551 That broke the build of cmake-gui due to an incorrect relative path to the manifest file. I've revised the commit accordingly: Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8 (#15674) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=17009189 -Brad From mantis at public.kitware.com Mon Sep 21 10:54:30 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 21 Sep 2015 10:54:30 -0400 Subject: [cmake-developers] [CMake 0015754]: Visual Studio incremental build not working properly when target names start with a capital letter Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15754 ====================================================================== Reported By: Johannes Asal Assigned To: ====================================================================== Project: CMake Issue ID: 15754 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-21 10:54 EDT Last Modified: 2015-09-21 10:54 EDT ====================================================================== Summary: Visual Studio incremental build not working properly when target names start with a capital letter Description: When using a target name starting with a capital letter (e.g. Mylibrary) in add_library (and probably also add_executable), GCC toolchains build fine but Visual Studio (tested with 2010 specifically) refuses to compile new .cpp files in the first incremental build after adding them to the CMakeLists.txt. However, it correctly detects that the CMakeLists.txt has changed and reconfigures accordingly. The second incremental build compiles the added files, which makes it even more strange. Please note that the bug occurs only when building via the CMake command line interface (cmake.exe --build). Building from within Visual Studio works always which is why I think it must be a problem with CMake. Steps to Reproduce: Install Visual Studio 2010. Unzip the attached ZIP file. Open a command line in the /build subfolder and call cmake -G"Visual Studio 10" .. Then do a cmake --build . Watch how test1.cpp is compiled properly. Then open CMakeLists.txt and uncomment the line with test2.cpp. Do an incremental build by calling cmake --build . The change of CMakeLists.txt is detected but test2.cpp is NOT COMPILED! Do a second incremental build cmake --build . Now test2.cpp is compiled. Delete the bugreport folder and extract it again from the ZIP file to return to the initial state. Open the CMakeLists.txt and rename the 'Notworking' target name in add_library to 'working'. Repeat all steps above and you will see that test2.cpp is compiled in the first incremental build already, as one would expect. I tested a lot of combinations and it seems that the capital letter in front seems to be the source of the problem. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-21 10:54 Johannes Asal New Issue 2015-09-21 10:54 Johannes Asal File Added: bugreport.zip ====================================================================== From brad.king at kitware.com Mon Sep 21 11:09:01 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Sep 2015 11:09:01 -0400 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: References: <55E4B396.9090609@kitware.com> <55E714E1.10505@kitware.com> <55F0496A.1040205@kitware.com> <55F18811.8000400@kitware.com> <55F1D428.4030707@kitware.com> <55F1D516.802@kitware.com> Message-ID: <56001D8D.3070703@kitware.com> On 09/10/2015 09:31 PM, Gilles Khouzam wrote: > Here is the patch for Windows 10 Support which would be issue 15686. [snip] > This change requires the change for issue 0015674 for determining the > version of the OS. That change is now done as posted here: [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14327/focus=14478 Please rebase the rest of your Win 10 patch on that and revise according to the comments below. > New Properties Added: > VS_TARGET_PLATFORM_VERSION: Target property. Specifies that the SDK being > used to compile the project. For Windows 10 RTM, that will be 10.0.10240.0. > For Store apps, this property is required by Visual Studio. If the property > is not specified, the system will be queried for the available Windows 10 > SDKs installed and the most recent but less than or equal version than the > host system version will be set as a default (in > CMAKE_VS_TARGET_PLATFORM_VERSION) and used. Please split this part out into its own (preceding) patch, much like was done for the windows version detection. Also, currently the patch does not implement [CMAKE_]VS_TARGET_PLATFORM_VERSION as previously discussed: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14201/focus=14246 For example: > + if (this->SystemVersion == "10.0") > + { > + // Find the default version of the Windows 10 SDK and set > + // a default CMAKE_VS_TARGET_PLATFORM_VERSION > + std::string sdkVersion = GetWindows10SDKVersion(); > + if(sdkVersion.empty()) > + { > + e << "Could not find an appropriate version of the Windows 10 SDK" > + << "installed on this machine"; > + mf->IssueMessage(cmake::FATAL_ERROR, e.str()); > + return false; > + } > + mf->AddDefinition("CMAKE_VS_TARGET_PLATFORM_VERSION", > + sdkVersion.c_str()); > + } Logic like this should be used to select a default SDK when neither the property nor the variable is set. I think we've had some confusion between the user-settable target property/variable and the generator- reported selection result used by the compiler id. The latter is used here in your patch: > + set(id_WindowsTargetPlatformVersion "${CMAKE_VS_TARGET_PLATFORM_VERSION}") Currently the CMAKE_VS_ convention is used by the VS generators to report information about what the've decided. I think this makes sense so a variable called CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION could serve this purpose (reporting to project code what VS decided to use). What we need separately is an interface for users and/or project code to select a specific WindowsTargetPlatformVersion. The target property currently called VS_TARGET_PLATFORM_VERSION will work well for project code to set the value for specific targets. We still need another setting for users or toolchain files to set to make it a project-wide default. Perhaps we should have a separate variable called CMAKE_WINDOWS_TARGET_PLATFORM_VERSION and rename the target property to just WINDOWS_TARGET_PLATFORM_VERSION The property should be initialized via SetPropertyDefault to copy the variable setting into each target. -Brad From brad.king at kitware.com Mon Sep 21 11:10:37 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Sep 2015 11:10:37 -0400 Subject: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version In-Reply-To: <089001d0f244$073053d0$1590fb70$@motionview3d.com> References: <55FC56D4.2000204@kitware.com> <089001d0f244$073053d0$1590fb70$@motionview3d.com> Message-ID: <56001DED.8040104@kitware.com> On 09/18/2015 02:58 PM, James Johnston wrote: > While on the subject, there are some other additions to the manifest you > might want to consider. I think these are worth considering but we're too close to the 3.4 freeze to make these changes now. Please look at adding these during post-3.4 development. Thanks, -Brad From mantis at public.kitware.com Mon Sep 21 12:27:50 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 21 Sep 2015 12:27:50 -0400 Subject: [cmake-developers] [CMake 0015755]: add_dependencies() undoes include_directories() Message-ID: <8209ea811ad2d6bf42e4aaf57145b075@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15755 ====================================================================== Reported By: Dimitri Merejkowsky Assigned To: ====================================================================== Project: CMake Issue ID: 15755 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-21 12:27 EDT Last Modified: 2015-09-21 12:27 EDT ====================================================================== Summary: add_dependencies() undoes include_directories() Description: Calling add_dependencies() between two targets causes some calls to include_directories() to no longer be taken into account Steps to Reproduce: See attached project. $ mkdir b1 $ cmake .. $ make ... [ 25%] Linking C executable eggs CMakeFiles/eggs.dir/eggs.c.o: In function `main': eggs.c:(.text+0xa): undefined reference to `spam $ mkdir b2 $ cmake -DADD_DEPENDENCIES=ON .. $ make [ 25%] Building C object spam/CMakeFiles/spam.dir/src/spam.c.o spam/src/spam.c:1:23: fatal error: spam/spam.h: No such file or directory ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-21 12:27 Dimitri MerejkowskyNew Issue 2015-09-21 12:27 Dimitri MerejkowskyFile Added: spam.zip ====================================================================== From brad.king at kitware.com Mon Sep 21 13:54:35 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Sep 2015 13:54:35 -0400 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> Message-ID: <5600445B.8010400@kitware.com> On 09/18/2015 03:49 PM, Robert Goulet wrote: > Here's a version that is more conservative. It doesn't change > the install(EXPORT) behavior. > install(TARGET) already supported genex Right. I'd forgotten about these changes: install: Allow generator expressions in TARGETS DESTINATION (#14317) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f30022eb http://www.cmake.org/Bug/view.php?id=14317#c37959 >, so basically this patch adds install(FILES) destination genex. Okay. I see many hunks of this form: > - this->Destination, > + this->GetDestination(), Making the Destination member private and moving GetDestination() back into cmInstallGenerator is refactoring that should be split out into its own commit. Note that GetDestination() was removed from the base class here: cmInstallGenerator: Move GetDestination to subclasses that need it http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f99991db Restoring it will need a justification in the commit message. I'm concerned about having both overloads avilable: > + std::string GetDestination() const; > + std::string GetDestination(std::string const& config) const; when only one is safe to call from each subclass. This is why the above-linked commit removed the method from cmInstallGenerator in favor of having the needed overload in each subclass. > - cmInstallGenerator(const char* destination, > + cmInstallGenerator(cmMakefile* mf, > + const char* destination, This and its related changes are also refactoring that should go in its own commit. > + // We need per-config actions if destination have generator expressions. > + if(cmGeneratorExpression::Find(Destination) != std::string::npos) > + { > + this->ActionsPerConfig = true; > + } Was this the solution to the availability of a configuration for calls to GetDestination()? > Perhaps we should update the Help to only mention install(FILES) > destination instead of all variations of install? Yes, the actual availability of the behavior should be documented. Also please look at making the test suite actually verify that the installation works as expected. The above-linked commit f30022eb adds a test that fails if generator expressions are not evaluated to the correct values. Thanks, -Brad From mantis at public.kitware.com Mon Sep 21 17:15:16 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 21 Sep 2015 15:15:16 -0600 Subject: [cmake-developers] [CMake 0015756]: FindLua.cmake doesn't work when both Lua5.2 and Lua5.3 are installed. Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15756 ====================================================================== Reported By: Alan Witkowski Assigned To: ====================================================================== Project: CMake Issue ID: 15756 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-21 15:15 MDT Last Modified: 2015-09-21 15:15 MDT ====================================================================== Summary: FindLua.cmake doesn't work when both Lua5.2 and Lua5.3 are installed. Description: If you call find_package(Lua 5.2 REQUIRED) or find_package(Lua REQUIRED) this happens: Found Lua: /usr/lib64/liblua5.2.so;/usr/lib64/libm.so (found suitable version "5.3.1", minimum required is "5.2") Basically the 5.2 library is found but it still uses the 5.3 include path, hence the wrong "suitable version": CMakeCache.txt LUA_INCLUDE_DIR:PATH=/usr/include LUA_LIBRARY:FILEPATH=/usr/lib64/liblua5.2.so Calling find_package(Lua 5.3 REQUIRED) works fine though. Additional Information: lua5.3 is installed to /usr/include lua5.2 is installed to /usr/include/lua5.2 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-21 15:15 Alan Witkowski New Issue ====================================================================== From michael.scott250 at gmail.com Mon Sep 21 17:51:10 2015 From: michael.scott250 at gmail.com (Michael Scott) Date: Mon, 21 Sep 2015 22:51:10 +0100 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <55FFFC53.8030309@kitware.com> References: <55FFFC53.8030309@kitware.com> Message-ID: <56007BCE.7050605@gmail.com> > The -Wdev/-Wno-dev options have always been for all messages > output by any part of CMake. This needs to be preserved/corrected. Okay, I've fixed the change to cmake::PrintMessagePreamble, so that it'll stop warning or error dev or deprecated messages getting printed out when the relevant CMake variables have been set. I just need to add some more test cases to cover this and I'll submit a patch. > Likely yes. This may require sweeping changes to address. We're > too close to the freeze for 3.4 to do this now. Perhaps we should > simply remove -Werr-dev for now. Yes the -Werr-dev, -Wno-err-dev, -Werr-deprectated and -Wno-err-deprecated may be trickier than expected to get behaving as intended. I'll try and get a better idea of the users of IssueMessage and see if some ideas come to mind. Removing them would be fair enough at this point, better to not include them than to include broken functionality I'm sure. Do new features, such as -Werr-dev, have to be sent by October 1st is it? Cheers, Michael From domen.vrankar at gmail.com Tue Sep 22 06:03:52 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Tue, 22 Sep 2015 12:03:52 +0200 Subject: [cmake-developers] [CPackDeb] empty directories in packages In-Reply-To: References: Message-ID: > I was looking at this issue > http://public.kitware.com/Bug/view.php?id=13009 > > and apparently it is not possible to install empty directories (I just > tested). > > I believe that it should be possible to do that (even if there are better > ways like postinst). > What is your opinion? I agree. This is also an issue on other packaging generators (e.g. tar gz) > The attached patch addresses this (and adds the corresponding test). It is > based on my previous patch > "0001-CPackDeb-preventing-md5sum-on-symlinks.patch". Thanks, applied to next for testing: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=47b060 Your patch only fixed the issue for component packaging so I extended it to non component packaging as well. This also fixes the issue for other generators: http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=b58de9f Other fixed bug reports: http://public.kitware.com/Bug/view.php?id=8767 and http://public.kitware.com/Bug/view.php?id=14978 Thanks, Domen From eike at sf-mail.de Tue Sep 22 06:36:01 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 22 Sep 2015 12:36:01 +0200 Subject: [cmake-developers] [CPackDeb] empty directories in packages In-Reply-To: References: Message-ID: <277a2adbb260828e4043af9b444c696e@sf-mail.de> Domen Vrankar wrote: >> I was looking at this issue >> http://public.kitware.com/Bug/view.php?id=13009 >> >> and apparently it is not possible to install empty directories (I just >> tested). >> >> I believe that it should be possible to do that (even if there are >> better >> ways like postinst). >> What is your opinion? > > I agree. This is also an issue on other packaging generators (e.g. tar > gz) > >> The attached patch addresses this (and adds the corresponding test). >> It is >> based on my previous patch >> "0001-CPackDeb-preventing-md5sum-on-symlinks.patch". > > Thanks, applied to next for testing: > http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=47b060 > > Your patch only fixed the issue for component packaging so I extended > it to non component packaging as well. This also fixes the issue for > other generators: > http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=b58de9f You left a commented out line in Source/CPack/cmCPackGenerator.cxx. Greetings, Eike -- From domen.vrankar at gmail.com Tue Sep 22 07:25:36 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Tue, 22 Sep 2015 13:25:36 +0200 Subject: [cmake-developers] [CPackDeb] empty directories in packages In-Reply-To: <277a2adbb260828e4043af9b444c696e@sf-mail.de> References: <277a2adbb260828e4043af9b444c696e@sf-mail.de> Message-ID: > You left a commented out line in Source/CPack/cmCPackGenerator.cxx. Hm that should not be there. I'll delete it when I get to my PC. Thanks, Domen From brad.king at kitware.com Tue Sep 22 08:53:50 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 22 Sep 2015 08:53:50 -0400 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <56007BCE.7050605@gmail.com> References: <55FFFC53.8030309@kitware.com> <56007BCE.7050605@gmail.com> Message-ID: <56014F5E.5070901@kitware.com> On 09/21/2015 05:51 PM, Michael Scott wrote: > Yes the -Werr-dev, -Wno-err-dev, -Werr-deprectated and > -Wno-err-deprecated may be trickier than expected to get behaving as > intended. I'll try and get a better idea of the users of IssueMessage > and see if some ideas come to mind. Removing them would be fair enough > at this point, better to not include them than to include broken > functionality I'm sure. Do new features, such as -Werr-dev, have to be > sent by October 1st is it? Oct 1 is the feature freeze in 'master' for CMake 3.4, though the scale/scope of new features should be going down as we approach that date. In this case we have a bug in a new feature that was introduced in post-3.3 development so we need to either fix it or remove the offending parts of the new features before Oct 1 for 3.4. Thanks, -Brad From brad.king at kitware.com Tue Sep 22 09:19:21 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 22 Sep 2015 09:19:21 -0400 Subject: [cmake-developers] Regression caused by compute-default-dialect topic In-Reply-To: <55F9BF84.6040505@kitware.com> References: <55F9A678.1010800@kitware.com> <55F9B4D4.5060400@kitware.com> <55F9BF84.6040505@kitware.com> Message-ID: <56015559.9030000@kitware.com> On 09/16/2015 03:14 PM, Brad King wrote: > That eliminates my concern. This is now in 'master' as: Project: Determine default language dialect for the compiler. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7235334a However, I just discovered that it breaks use of toolchain files that force a compiler and set the version: $ cat ~/toolchain.cmake include(CMakeForceCompiler) CMAKE_FORCE_C_COMPILER(/usr/bin/gcc GNU) set(CMAKE_C_COMPILER_VERSION 5.2) $ cmake -DCMAKE_TOOLCHAIN_FILE=~/toolchain.cmake ../CMake/Tests/COnly CMake Error at /.../share/cmake-3.3/Modules/Compiler/GNU-C.cmake:27 (message): CMAKE_C_STANDARD_COMPUTED_DEFAULT should be set for GNU (/usr/bin/gcc) version 5.2 Call Stack (most recent call first): /.../share/cmake-3.3/Modules/CMakeCInformation.cmake:33 (include) CMakeLists.txt:3 (project) This is because the language standard default is computed while determining the compiler id, but that is skipped when using a toolchain file that forces the compiler. I think we need to: * Tolerate the lack of CMAKE__STANDARD_COMPUTED_DEFAULT and fall back to our old lookup table. * Allow toolchain files to set CMAKE__STANDARD_DEFAULT themselves just as they can set CMAKE__COMPILER_{ID,VERSION} now. * Add a RunCMake test that uses incrementally more complex toolchain files like the above (ID only, ID+version, ID+version+standard). ----------------------------------------------------------------------- This may also reveal a larger problem in that compiler features functionality does not work well with toolchain files that force the compiler. Doing so skips the test for a working compiler, but that also skips ABI and Features detection: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeTestCCompiler.cmake;hb=v3.3.2#l73 Asking toolchain files to set the ABI information was not too much, but the compiler feature detection produces a lot of information that toolchain files should not have to spell out. We may need to consider moving the ABI and Feature checks to somewhere that occurs even when forcing the compiler with a toolchain file. That is beyond the scope of the immediate need for a fix to the above error though. Thanks, -Brad From Robert.Goulet at autodesk.com Tue Sep 22 09:58:26 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Tue, 22 Sep 2015 13:58:26 +0000 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: <5600445B.8010400@kitware.com> References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> Message-ID: <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> > This and its related changes are also refactoring that should go in its own commit. Ok let's begin with this. Patch attached for adding makefile to install generators. This refactoring is required for install(FILES) genex support, and most likely other install() signatures in the future. Thanks. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Monday, September 21, 2015 1:55 PM To: Robert Goulet Cc: cmake-developers at cmake.org Subject: Re: Generator expressions for install destination On 09/18/2015 03:49 PM, Robert Goulet wrote: > Here's a version that is more conservative. It doesn't change the > install(EXPORT) behavior. > install(TARGET) already supported genex Right. I'd forgotten about these changes: install: Allow generator expressions in TARGETS DESTINATION (#14317) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f30022eb http://www.cmake.org/Bug/view.php?id=14317#c37959 >, so basically this patch adds install(FILES) destination genex. Okay. I see many hunks of this form: > - this->Destination, > + this->GetDestination(), Making the Destination member private and moving GetDestination() back into cmInstallGenerator is refactoring that should be split out into its own commit. Note that GetDestination() was removed from the base class here: cmInstallGenerator: Move GetDestination to subclasses that need it http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f99991db Restoring it will need a justification in the commit message. I'm concerned about having both overloads avilable: > + std::string GetDestination() const; std::string > + GetDestination(std::string const& config) const; when only one is safe to call from each subclass. This is why the above-linked commit removed the method from cmInstallGenerator in favor of having the needed overload in each subclass. > - cmInstallGenerator(const char* destination, > + cmInstallGenerator(cmMakefile* mf, > + const char* destination, This and its related changes are also refactoring that should go in its own commit. > + // We need per-config actions if destination have generator expressions. > + if(cmGeneratorExpression::Find(Destination) != std::string::npos) > + { > + this->ActionsPerConfig = true; > + } Was this the solution to the availability of a configuration for calls to GetDestination()? > Perhaps we should update the Help to only mention install(FILES) > destination instead of all variations of install? Yes, the actual availability of the behavior should be documented. Also please look at making the test suite actually verify that the installation works as expected. The above-linked commit f30022eb adds a test that fails if generator expressions are not evaluated to the correct values. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: add-makefile-to-install-generators.patch Type: application/octet-stream Size: 15306 bytes Desc: add-makefile-to-install-generators.patch URL: From brad.king at kitware.com Tue Sep 22 13:03:57 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 22 Sep 2015 13:03:57 -0400 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> Message-ID: <560189FD.5030106@kitware.com> On 09/22/2015 09:58 AM, Robert Goulet wrote: > Patch attached for adding makefile to install generators. > This refactoring is required for install(FILES) genex support, > and most likely other install() signatures in the future. Thanks. I applied that and merged to 'next' for testing: cmInstallGenerator: Add Makefile member http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d44cb327 I also extended the topic with some other refactoring it enables: cmInstallFilesGenerator: Drop LocalGenerator member http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e4b1728c cmInstallTargetGenerator: Simplify using Makefile member http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3f6b267d Steve, please check whether this runs afoul of your cmState refactoring design. Thanks, -Brad From Robert.Goulet at autodesk.com Tue Sep 22 13:18:31 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Tue, 22 Sep 2015 17:18:31 +0000 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: <560189FD.5030106@kitware.com> References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> Message-ID: Thanks, once this is accepted in master I will send you my updated install(FILES) with genex support. I removed the GetDestination() signature since I agree it's not needed and might be confusing. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, September 22, 2015 1:04 PM To: Robert Goulet Cc: cmake-developers at cmake.org; Stephen Kelly Subject: Re: Generator expressions for install destination On 09/22/2015 09:58 AM, Robert Goulet wrote: > Patch attached for adding makefile to install generators. > This refactoring is required for install(FILES) genex support, and > most likely other install() signatures in the future. Thanks. I applied that and merged to 'next' for testing: cmInstallGenerator: Add Makefile member http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d44cb327 I also extended the topic with some other refactoring it enables: cmInstallFilesGenerator: Drop LocalGenerator member http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e4b1728c cmInstallTargetGenerator: Simplify using Makefile member http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3f6b267d Steve, please check whether this runs afoul of your cmState refactoring design. Thanks, -Brad From steveire at gmail.com Tue Sep 22 16:00:00 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 22 Sep 2015 22:00 +0200 Subject: [cmake-developers] Generator expressions for install destination References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> Message-ID: Brad King wrote: > On 09/22/2015 09:58 AM, Robert Goulet wrote: >> Patch attached for adding makefile to install generators. >> This refactoring is required for install(FILES) genex support, >> and most likely other install() signatures in the future. > > Thanks. I applied that and merged to 'next' for testing: > > cmInstallGenerator: Add Makefile member > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d44cb327 > > I also extended the topic with some other refactoring it enables: > > cmInstallFilesGenerator: Drop LocalGenerator member > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e4b1728c > > cmInstallTargetGenerator: Simplify using Makefile member > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3f6b267d This is going in the wrong direction. See (Merge topic 'generators-use-cmLocalGenerator', 2015-08-24) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9135e370 Generator expressions are evaluated at generation-time, but with configuration-time types (cmMakefile and cmTarget). They should instead use generation-time types (cmLocalGenerator and cmGeneratorTarget). cmMakefile currently stores cmGeneratorTargets but it should not know them at all. This is a layering violation. See the fix-layering-violation branch in my clone which implements that and also contains other orthogonal and wip refactorings for my convenience (I have been cherry-picking commits from this into branches to merge to next): https://github.com/steveire/CMake/commits/fix-layering-violation None of that refactoring can proceed until after CMake 3.4 is released: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14286/focus=14323 The patch from Robert should not undo that effort, so the branch should be reverted from next and not merged to master. Thanks, Steve. From brad.king at kitware.com Tue Sep 22 16:27:14 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 22 Sep 2015 16:27:14 -0400 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> Message-ID: <5601B9A2.3060505@kitware.com> On 09/22/2015 04:00 PM, Stephen Kelly wrote: > This is going in the wrong direction. > (Merge topic 'generators-use-cmLocalGenerator', 2015-08-24) > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9135e370 [snip] > The patch from Robert should not undo that effort, so the branch > should be reverted from next and not merged to master. Thanks, Steve. I suspected this which is why I called your attention to this review. Reverted. Robert, this feature is going to have to wait until post-3.4 development opens so it can be based on Steve's refactoring work. I suspect it will be easier to implement after that refactoring anyway. Sorry this trouble was not identified earlier in review. -Brad From Robert.Goulet at autodesk.com Tue Sep 22 16:27:37 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Tue, 22 Sep 2015 20:27:37 +0000 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> Message-ID: <19a621155766478db4203cc519bf62d6@BN1PR79MB007.MGDADSK.autodesk.com> Ok then perhaps the refactoring can wait but we'd still like to get install(FILES) destination genex support in 3.4 if possible, and genex evaluation requires the cmMakefile. How should we proceed then? -----Original Message----- From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Stephen Kelly Sent: Tuesday, September 22, 2015 4:00 PM To: cmake-developers at cmake.org Subject: Re: [cmake-developers] Generator expressions for install destination Brad King wrote: > On 09/22/2015 09:58 AM, Robert Goulet wrote: >> Patch attached for adding makefile to install generators. >> This refactoring is required for install(FILES) genex support, and >> most likely other install() signatures in the future. > > Thanks. I applied that and merged to 'next' for testing: > > cmInstallGenerator: Add Makefile member > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d44cb327 > > I also extended the topic with some other refactoring it enables: > > cmInstallFilesGenerator: Drop LocalGenerator member > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e4b1728c > > cmInstallTargetGenerator: Simplify using Makefile member > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3f6b267d This is going in the wrong direction. See (Merge topic 'generators-use-cmLocalGenerator', 2015-08-24) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9135e370 Generator expressions are evaluated at generation-time, but with configuration-time types (cmMakefile and cmTarget). They should instead use generation-time types (cmLocalGenerator and cmGeneratorTarget). cmMakefile currently stores cmGeneratorTargets but it should not know them at all. This is a layering violation. See the fix-layering-violation branch in my clone which implements that and also contains other orthogonal and wip refactorings for my convenience (I have been cherry-picking commits from this into branches to merge to next): https://github.com/steveire/CMake/commits/fix-layering-violation None of that refactoring can proceed until after CMake 3.4 is released: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14286/focus=14323 The patch from Robert should not undo that effort, so the branch should be reverted from next and not merged to master. 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 Tue Sep 22 16:29:47 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 22 Sep 2015 22:29:47 +0200 Subject: [cmake-developers] Regression caused by compute-default-dialect topic References: <55F9A678.1010800@kitware.com> <55F9B4D4.5060400@kitware.com> <55F9BF84.6040505@kitware.com> <56015559.9030000@kitware.com> Message-ID: Brad King wrote: > On 09/16/2015 03:14 PM, Brad King wrote: >> That eliminates my concern. > > This is now in 'master' as: > > Project: Determine default language dialect for the compiler. > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7235334a > > However, I just discovered that it breaks use of toolchain files > that force a compiler and set the version: > > $ cat ~/toolchain.cmake > include(CMakeForceCompiler) > CMAKE_FORCE_C_COMPILER(/usr/bin/gcc GNU) > set(CMAKE_C_COMPILER_VERSION 5.2) I've pushed fix-forced-toolchain-dialect to fix this. It uses an existing mechanism already in use to determine whether the compiler was forced. > This is because the language standard default is computed while > determining the compiler id, but that is skipped when using a toolchain > file that forces the compiler. Is there any legitimate need to force the compiler? For example, why does the android toolchain file force GNU and Clang compilers? Is it misunderstanding on the part of the toolchain author? Or are there really Clang and GNU releases which can not be executed by CMake as usual? In particular, are those GNU and Clang releases part of the Android NDK? Ie: Should CmakeForceCompiler.cmake be deprecated? It seems to date from a time when the compiler id and whether it 'basically works' were the only things CMake wished to know in order to initialize. Today there is much more, including compiler version, ABI and features. If the module should remain, then more complex macros should be added and maintained, in a design which accommodates future growth of reasons to run the compiler during initialization. > I think we need to: > > * Tolerate the lack of CMAKE__STANDARD_COMPUTED_DEFAULT and fall > back to our old lookup table. As you note below, that would not be useful because no features are recorded for forced compilers. > * Allow toolchain files to set CMAKE__STANDARD_DEFAULT themselves > just as they can set CMAKE__COMPILER_{ID,VERSION} now. As above. > This may also reveal a larger problem in that compiler features > functionality does not work well with toolchain files that force > the compiler. Doing so skips the test for a working compiler, > but that also skips ABI and Features detection: > > http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeTestCCompiler.cmake;hb=v3.3.2#l73 > > Asking toolchain files to set the ABI information was not too much, > but the compiler feature detection produces a lot of information > that toolchain files should not have to spell out. Yes, I think if the module should remain, then more complex macros should be added and maintained, in a design which accommodates future growth of reasons to run the compiler during initialization. Thanks, Steve. From Robert.Goulet at autodesk.com Tue Sep 22 16:35:01 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Tue, 22 Sep 2015 20:35:01 +0000 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: <5601B9A2.3060505@kitware.com> References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> <5601B9A2.3060505@kitware.com> Message-ID: Ok so that brings the question, how is 3.4 schedule looking? We really wanted to get install(FILES) destination genex in CMake 3.4 release version... this is a bit disappointing because we'll have to stick with our custom branch another round. Oh well. Thanks. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, September 22, 2015 4:27 PM To: Robert Goulet Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] Generator expressions for install destination On 09/22/2015 04:00 PM, Stephen Kelly wrote: > This is going in the wrong direction. > (Merge topic 'generators-use-cmLocalGenerator', 2015-08-24) > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9135e370 [snip] > The patch from Robert should not undo that effort, so the branch > should be reverted from next and not merged to master. Thanks, Steve. I suspected this which is why I called your attention to this review. Reverted. Robert, this feature is going to have to wait until post-3.4 development opens so it can be based on Steve's refactoring work. I suspect it will be easier to implement after that refactoring anyway. Sorry this trouble was not identified earlier in review. -Brad From steveire at gmail.com Tue Sep 22 16:34:32 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 22 Sep 2015 22:34:32 +0200 Subject: [cmake-developers] Generator expressions for install destination References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> <5601B9A2.3060505@kitware.com> Message-ID: Brad King wrote: > On 09/22/2015 04:00 PM, Stephen Kelly wrote: >> This is going in the wrong direction. >> (Merge topic 'generators-use-cmLocalGenerator', 2015-08-24) >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9135e370 > [snip] >> The patch from Robert should not undo that effort, so the branch >> should be reverted from next and not merged to master. > > Thanks, Steve. I suspected this which is why I called your attention > to this review. Reverted. > > Robert, this feature is going to have to wait until post-3.4 development > opens so it can be based on Steve's refactoring work. I suspect it will > be easier to implement after that refactoring anyway. Sorry this trouble > was not identified earlier in review. Yes, sorry from me too! I haven't been following this thread until now. Thanks, Steve. From brad.king at kitware.com Tue Sep 22 16:39:07 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 22 Sep 2015 16:39:07 -0400 Subject: [cmake-developers] CMakeForceCompiler (was: Regression caused by compute-default-dialect topic) In-Reply-To: References: <55F9A678.1010800@kitware.com> <55F9B4D4.5060400@kitware.com> <55F9BF84.6040505@kitware.com> <56015559.9030000@kitware.com> Message-ID: <5601BC6B.7000205@kitware.com> On 09/22/2015 04:29 PM, Stephen Kelly wrote: > I've pushed fix-forced-toolchain-dialect to fix this. It uses an existing > mechanism already in use to determine whether the compiler was forced. Looks good, thanks. > Is there any legitimate need to force the compiler? The CMakeForceCompiler module was added here: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fda7753f The commit message mentions: ... embedded compilers need a user specific linker file for compiling an executable ... thus cannot build the compiler-id program... Since then the compiler id logic has learned to do things like pass the --version flag and match vendor-specific output. That could be used to identify these embedded compilers. Then the test for working compiler will still need a linker file but perhaps we can generate one once we know the compiler id. > For example, why does the android toolchain file force GNU and Clang > compilers? Is it misunderstanding on the part of the toolchain author? I don't think the android.toolchain.cmake file needs to force the compiler. It can simply set CMAKE_{C,CXX}_COMPILER and let the normal detection proceed. > Ie: Should CmakeForceCompiler.cmake be deprecated? It seems to date from a > time when the compiler id and whether it 'basically works' were the only > things CMake wished to know in order to initialize. Today there is much > more, including compiler version, ABI and features. Yes, I think it should be deprecated if possible. First we must provide alternatives for all its use cases though. -Brad From steveire at gmail.com Tue Sep 22 16:42:50 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 22 Sep 2015 22:42:50 +0200 Subject: [cmake-developers] [CMake] Visual Studio - Ninja Generator References: <55E48101.2010502@gmail.com> <053901d0e5b6$6c47ae70$44d70b50$@motionview3d.com> <55F04977.6040101@kitware.com> <041601d0ecaa$20dd64c0$62982e40$@motionview3d.com> Message-ID: James Johnston wrote: >> > it would be useful to have Visual Studio available as an "Extra" CMake >> > generator. For example, specification of "Visual Studio 2015 - Ninja" >> >> This functionality sounds reasonable but the name of the extra/generator >> pair looks funny when spelled out that way. We should consider having >> another way to specify the extra generator. > > This name is consistent with the other extra generators: ... however the design is not. The 'extra generators' do their generation after the 'real' makefile or ninja generator. Your proposal seems to be something different design-wise. From what I understand, you are proposing something which would need to do different things during the 'real' generate. In terms of name though, it might not matter that IDE and non-IDE 'extra' generators are implemented in completely different ways. > But I agree it is just confusing at this point. Maybe this format could > be deprecated in favor of a new cmake.exe switch to specify an extra > generator. Perhaps. It seems Xcode+Ninja could also be a valid pairing. Thanks, Steve. From brad.king at kitware.com Tue Sep 22 16:45:45 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 22 Sep 2015 16:45:45 -0400 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> <5601B9A2.3060505@kitware.com> Message-ID: <5601BDF9.3000905@kitware.com> On 09/22/2015 04:35 PM, Robert Goulet wrote: > Ok so that brings the question, how is 3.4 schedule looking? The feature freeze will be Oct 1 shortly after which post-3.4 development will open. Steve will then start his post-3.4 refactoring topic merges and then we can come back to this feature. > We really wanted to get install(FILES) destination genex in CMake 3.4 > release version... this is a bit disappointing because we'll have to > stick with our custom branch another round. Oh well. Sorry about that but the timing just didn't work out. At least your genex support for OUTPUT_NAME and OUTPUT_DIRECTORY will be in 3.4. Thanks for your patience, -Brad From steveire at gmail.com Tue Sep 22 16:53:04 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 22 Sep 2015 22:53:04 +0200 Subject: [cmake-developers] Generator expressions for install destination References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> <19a621155766478db4203cc519bf62d6@BN1PR79MB007.MGDADSK.autodesk.com> Message-ID: Robert Goulet wrote: > Ok then perhaps the refactoring can wait but we'd still like to get > install(FILES) destination genex support in 3.4 if possible, and genex > evaluation requires the cmMakefile. How should we proceed then? cmLocalGenerator has a GetMakefile method (currently). Don't you just need to use this->LocalGenerator->GetMakefile() in cmInstallFilesGenerator? Whether Brad would still accept a patch like that for 3.4 I don't know, but I think it should be a relatively simple implementation? However, there may need to be more tests for the new functionality and error cases etc. Thanks, Steve. From steveire at gmail.com Tue Sep 22 17:03:15 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 22 Sep 2015 23:03:15 +0200 Subject: [cmake-developers] Help with diagnosing dashboard failure Message-ID: Hi, A few days ago I merged a commit which moves the construction of cmLocalGenerator objects. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3aa333d It fails on the RunCMake.try_compile test on several dashboards in the CMP0056 test at the end where the policy is set to NEW. I didn't see an obvious pattern of which dashboards fail. I am unable to reproduce the problem. I can not see any reason for the problem. If you can reproduce the problem, please assist in debugging that. Simply cherry-pick the a3aa333d commit, build and run the RunCMake.try_compile CMP0056 test. If it fails, please investigate why it fails. For example: 1) Is the policy correctly determined to be NEW in cmCoreTryCompile.cxx? 2) Is the CMAKE_EXE_LINKER_FLAGS correctly generated in the CMakeLists generated for the try_compile? 3) etc Thanks, Steve. From Robert.Goulet at autodesk.com Tue Sep 22 17:24:42 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Tue, 22 Sep 2015 21:24:42 +0000 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> <19a621155766478db4203cc519bf62d6@BN1PR79MB007.MGDADSK.autodesk.com> Message-ID: <8aba767832a14419b4cbdf810b88b116@BN1PR79MB007.MGDADSK.autodesk.com> Yeah I guess it could look something like this (attachment). However I just realized that if I don't also get install(DIRECTORY) in 3.4 then this is not worth rushing it, since as you mention I would also need to write proper test cases. Just let me know when I can start looking at this again (after your refactoring is done) and I'll try to do the proper work to make it work with all install types destinations (files, directory and export). -----Original Message----- From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Stephen Kelly Sent: Tuesday, September 22, 2015 4:53 PM To: cmake-developers at cmake.org Subject: Re: [cmake-developers] Generator expressions for install destination Robert Goulet wrote: > Ok then perhaps the refactoring can wait but we'd still like to get > install(FILES) destination genex support in 3.4 if possible, and genex > evaluation requires the cmMakefile. How should we proceed then? cmLocalGenerator has a GetMakefile method (currently). Don't you just need to use this->LocalGenerator->GetMakefile() in cmInstallFilesGenerator? Whether Brad would still accept a patch like that for 3.4 I don't know, but I think it should be a relatively simple implementation? However, there may need to be more tests for the new functionality and error cases etc. 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 -------------- A non-text attachment was scrubbed... Name: install-files-dest-genex.patch Type: application/octet-stream Size: 3199 bytes Desc: install-files-dest-genex.patch URL: From steveire at gmail.com Tue Sep 22 17:36:03 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 22 Sep 2015 23:36:03 +0200 Subject: [cmake-developers] Generator expressions for install destination References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> <19a621155766478db4203cc519bf62d6@BN1PR79MB007.MGDADSK.autodesk.com> <8aba767832a14419b4cbdf810b88b116@BN1PR79MB007.MGDADSK.autodesk.com> Message-ID: Robert Goulet wrote: > Yeah I guess it could look something like this (attachment). Yes, something like that (modulo the long line). > However I > just realized that if I don't also get install(DIRECTORY) in 3.4 then this > is not worth rushing it, since as you mention I would also need to write > proper test cases. > > Just let me know when I can start looking at this again (after your > refactoring is done) and I'll try to do the proper work to make it work > with all install types destinations (files, directory and export). My refactoring won't affect the files and directory much, so you can proceed similar to that patch without conflicting. An appropriate branch like that could be committed before my refactoring, depending on when it is ready. My refactoring will only remove the `->GetMakefile()` part from affected lines, but it will take a while to get to the point where that can actually be done, so you don't need to wait for it. Thanks, Steve. From Gilles.Khouzam at microsoft.com Wed Sep 23 01:29:21 2015 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Wed, 23 Sep 2015 05:29:21 +0000 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: <56001D8D.3070703@kitware.com> References: <55E4B396.9090609@kitware.com> <55E714E1.10505@kitware.com> <55F0496A.1040205@kitware.com> <55F18811.8000400@kitware.com> <55F1D428.4030707@kitware.com> <55F1D516.802@kitware.com> <56001D8D.3070703@kitware.com> Message-ID: Thanks for the feedback Brad, I have rebased the changes and I think that I have the proper default functionality properly implemented. I've extracted the WINDOWS_TARGET_PLATFORM_VERSION changes into a separate patch. WINDOWS_TARGET_PLATFORM_VERSION is a target property, for that will specify the WindowsTargetPlatformVersion tag in VS. WINDOWS_TARGET_PLATFORM_MIN_VERSION is a target property that will specify the WindowsTargetPlatformMinVersion tag in VS. Now, for the default behavior, if CMAKE_WINDOWS_TARGET_PLATFORM_VERSION is set through a toolchain file or the project, then that will be the default which will initialize the WINDOWS_TARGET_PLATFORM_VERSION for each target through the SetPropertyDefault initialization call. On the other hand, if CMAKE_WINDOWS_TARGET_PLATFORM_VERSION is not set, nothing should happen since this is not a required property other than for Windows 10 Universal (store) apps, the default behavior in that case should be to not have the property. There is one open issue though. How should we have the value for CMAKE_WINDOWS_TARGET_PLATFORM_VERSION be the latest installed SDK when this is not a Windows Store project? For Windows Store projects this would get set if the property is not defined through the InitializeSystem procedure. How would we handle this for the non Windows Store case? Do this based on the version and no CMAKE_SYSTEM_NAME defined? Or should we force there to be a CMAKE_SYSTEM_NAME to be defined as Windows for example? -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Monday, September 21, 2015 08:09 To: Gilles Khouzam Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/10/2015 09:31 PM, Gilles Khouzam wrote: > Here is the patch for Windows 10 Support which would be issue 15686. [snip] > This change requires the change for issue 0015674 for determining the > version of the OS. That change is now done as posted here: [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14327/focus=14478 Please rebase the rest of your Win 10 patch on that and revise according to the comments below. > New Properties Added: > VS_TARGET_PLATFORM_VERSION: Target property. Specifies that the SDK > being used to compile the project. For Windows 10 RTM, that will be 10.0.10240.0. > For Store apps, this property is required by Visual Studio. If the > property is not specified, the system will be queried for the > available Windows 10 SDKs installed and the most recent but less than > or equal version than the host system version will be set as a default > (in > CMAKE_VS_TARGET_PLATFORM_VERSION) and used. Please split this part out into its own (preceding) patch, much like was done for the windows version detection. Also, currently the patch does not implement [CMAKE_]VS_TARGET_PLATFORM_VERSION as previously discussed: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14201/focus=14246 For example: > + if (this->SystemVersion == "10.0") > + { > + // Find the default version of the Windows 10 SDK and set > + // a default CMAKE_VS_TARGET_PLATFORM_VERSION > + std::string sdkVersion = GetWindows10SDKVersion(); > + if(sdkVersion.empty()) > + { > + e << "Could not find an appropriate version of the Windows 10 SDK" > + << "installed on this machine"; > + mf->IssueMessage(cmake::FATAL_ERROR, e.str()); > + return false; > + } > + mf->AddDefinition("CMAKE_VS_TARGET_PLATFORM_VERSION", > + sdkVersion.c_str()); > + } Logic like this should be used to select a default SDK when neither the property nor the variable is set. I think we've had some confusion between the user-settable target property/variable and the generator- reported selection result used by the compiler id. The latter is used here in your patch: > + set(id_WindowsTargetPlatformVersion > + "${CMAKE_VS_TARGET_PLATFORM_VERSION} + WindowsTargetPlatformVersion>") Currently the CMAKE_VS_ convention is used by the VS generators to report information about what the've decided. I think this makes sense so a variable called CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION could serve this purpose (reporting to project code what VS decided to use). What we need separately is an interface for users and/or project code to select a specific WindowsTargetPlatformVersion. The target property currently called VS_TARGET_PLATFORM_VERSION will work well for project code to set the value for specific targets. We still need another setting for users or toolchain files to set to make it a project-wide default. Perhaps we should have a separate variable called CMAKE_WINDOWS_TARGET_PLATFORM_VERSION and rename the target property to just WINDOWS_TARGET_PLATFORM_VERSION The property should be initialized via SetPropertyDefault to copy the variable setting into each target. -Brad From raffi.enficiaud at mines-paris.org Wed Sep 23 03:47:15 2015 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Wed, 23 Sep 2015 09:47:15 +0200 Subject: [cmake-developers] [CPackDeb] empty directories in packages In-Reply-To: References: Message-ID: Le 22/09/15 12:03, Domen Vrankar a ?crit : >> I was looking at this issue >> http://public.kitware.com/Bug/view.php?id=13009 >> >> and apparently it is not possible to install empty directories (I just >> tested). >> >> I believe that it should be possible to do that (even if there are better >> ways like postinst). >> What is your opinion? > > I agree. This is also an issue on other packaging generators (e.g. tar gz) > >> The attached patch addresses this (and adds the corresponding test). It is >> based on my previous patch >> "0001-CPackDeb-preventing-md5sum-on-symlinks.patch". > > Thanks, applied to next for testing: > http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=47b060 > > Your patch only fixed the issue for component packaging so I extended > it to non component packaging as well. This also fixes the issue for > other generators: > http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=b58de9f > > Other fixed bug reports: > http://public.kitware.com/Bug/view.php?id=8767 and > http://public.kitware.com/Bug/view.php?id=14978 > > > Thanks, > Domen > Thanks, I was not sure about the CPack part. Hopefully now I will be able to build my package on Launchpad :) Best, Raffi From mantis at public.kitware.com Wed Sep 23 05:28:57 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 23 Sep 2015 05:28:57 -0400 Subject: [cmake-developers] [CMake 0015757]: Including a project from parent subdirectory causes CMake to produce wrong build files for Ninja generator Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15757 ====================================================================== Reported By: Pavel Solodovnikov Assigned To: ====================================================================== Project: CMake Issue ID: 15757 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2015-09-23 05:28 EDT Last Modified: 2015-09-23 05:28 EDT ====================================================================== Summary: Including a project from parent subdirectory causes CMake to produce wrong build files for Ninja generator Description: Suppose we have following project structure: testing_ninja/ --- mylib1/ ------ CMakeLists.txt ------ src.cpp --- mylib2/ ------ CMakeLists.txt ------ src.cpp CMakeLists.txt for mylib1 creates a library mylib1.dll, which exports some symbols needed by mylib2, so mylib2 depends on mylib1 ( via target_link_libraries(mylib2 mylib1) ). If mylib1 CMakelists.txt contains following line, which includes mylib2 project: add_subdirectory("../mylib2" "../mylib2") then if we use Ninja generator to produce build files (invoking cmake inside mylib1 directory), the generated build.ninja file contains errors. CMake-generated build.ninja file contains mixed absolute-relative paths for mylib1.lib target which confuses ninja in such a way: when ninja is invoked it immediately reports an error that it couldn't find mylib1.lib binary needed by mylib2 (however it should be generated at build time and ninja should not rely on its existence). Error message is as follows: E:\testing_ninja\mylib1>ninja ninja: error: 'E:/testing_ninja/mylib1/mylib1.lib', needed by 'E:/testing_ninja/ mylib2/mylib2.dll', missing and no known rule to make it As I understand it happens because CMake generates a list of phony targets for each build target (expressed via relative path to target), so ninja does not need these files to exist at the beginning of build. And because CMake is mixing up relative and absolute paths in this case, ninja does not recognize phony targets anymore (they are expressed as absolute paths now) and fails. If I move mylib2 project inside mylib1 directory so the whole source tree stays inside the folder in which the root CMakeLists.txt file is placed, this behavior does not happen. To note one important moment: this only does happen if mylib1 appears to be dynamic library, if we build static libraries instead everything is alright. I've attached a test project to demonstrate such behavior. Tested only on Windows but I assume that it could be reproduced under the same conditions on other platforms. Steps to Reproduce: 1) Extract attached archive 2) Invoke cmake inside mylib1 directory with following arguments: cmake -G "Ninja" . ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-23 05:28 Pavel SolodovnikovNew Issue 2015-09-23 05:28 Pavel SolodovnikovFile Added: testing_ninja.zip ====================================================================== From brad.king at kitware.com Wed Sep 23 08:38:21 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Sep 2015 08:38:21 -0400 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: References: <55E4B396.9090609@kitware.com> <55E714E1.10505@kitware.com> <55F0496A.1040205@kitware.com> <55F18811.8000400@kitware.com> <55F1D428.4030707@kitware.com> <55F1D516.802@kitware.com> <56001D8D.3070703@kitware.com> Message-ID: <56029D3D.80405@kitware.com> On 09/23/2015 01:29 AM, Gilles Khouzam wrote: > Now, for the default behavior, if > CMAKE_WINDOWS_TARGET_PLATFORM_VERSION is set through a toolchain > file or the project, then that will be the default which will > initialize the WINDOWS_TARGET_PLATFORM_VERSION for each target > through the SetPropertyDefault initialization call. On the other > hand, if CMAKE_WINDOWS_TARGET_PLATFORM_VERSION is not set, > nothing should happen since this is not a required property other > than for Windows 10 Universal (store) apps, the default behavior > in that case should be to not have the property. Okay. > There is one open issue though. How should we have the value for > CMAKE_WINDOWS_TARGET_PLATFORM_VERSION be the latest installed SDK > when this is not a Windows Store project? For Windows Store > projects this would get set if the property is not defined > through the InitializeSystem procedure. How would we handle this > for the non Windows Store case? Do this based on the version and > no CMAKE_SYSTEM_NAME defined? Or should we force there to be a > CMAKE_SYSTEM_NAME to be defined as Windows for example? CMAKE_SYSTEM_NAME is already always defined to a value detected from the host system when not defined by a toolchain file or by the user in the cache. On a Windows host the value will be "Windows". I don't fully understand the case in question. When not building for Windows Store, does WindowsTargetPlatformVersion need a value if the user does not request one? What happens if it does not get a value? Is it needed for Windows 10 Desktop? Thanks, -Brad From s.kislinskiy at Dkfz-Heidelberg.de Wed Sep 23 08:40:32 2015 From: s.kislinskiy at Dkfz-Heidelberg.de (Kislinskiy, Stefan) Date: Wed, 23 Sep 2015 14:40:32 +0200 Subject: [cmake-developers] generator expression for path slash conversion In-Reply-To: <55FAC667.5000901@kitware.com> References: <57EE86D11538B44096C712532DBB6C5A0131C2B7AA5E@DKFZEX01.ad.dkfz-heidelberg.de> <55FAC667.5000901@kitware.com> Message-ID: <57EE86D11538B44096C712532DBB6C5A0131C2B7AE4D@DKFZEX01.ad.dkfz-heidelberg.de> I wrote the documentation, added a genex test that checks it the given path is converted as expected on different platforms, and added another ExternalProject test for Windows that invokes pushd, which is is command sensitive to the path style. I wasn't sure about the VERSION I am supposed to write into the cmake_minimum_required() line in Tests/ExternalProjectShellPathGenex/CMakeLists.txt, so I chose 3.3.20150923. Maybe you need to adjust the version there? I tried to be as consistent as possible regarding the tests and their already existing fellow tests. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Donnerstag, 17. September 2015 15:56 To: Kislinskiy, Stefan Cc: CHEVRIER, Marc; cmake-developers at cmake.org; James Johnston Subject: Re: [cmake-developers] generator expression for path slash conversion On 09/17/2015 09:51 AM, Kislinskiy, Stefan wrote: > I wrote a SHELL_PATH genex which uses > cmOutputConverter->ConvertToOutputFormat(..., SHELL) for the conversion. > I decided to name the genex SHELL_PATH instead of TO_SHELL_PATH for > the sake of consistency to other genexes like LOWER_CASE. What do you think? LGTM. > I would write some documentation as well of course. Yes, please. Also please look at extending the test suite to cover it. See Tests/GeneratorExpression for genex unit test examples. If possible we should also have a case that uses it in practice in a way that fails on invocation of an actual native tool if the slashes are wrong. That will confirm not only that the genex does what we expect but that it also solves the problem we're trying to solve. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: shell_path_genex_v3.patch Type: application/octet-stream Size: 8944 bytes Desc: shell_path_genex_v3.patch URL: From brad.king at kitware.com Wed Sep 23 09:55:31 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Sep 2015 09:55:31 -0400 Subject: [cmake-developers] generator expression for path slash conversion In-Reply-To: <57EE86D11538B44096C712532DBB6C5A0131C2B7AE4D@DKFZEX01.ad.dkfz-heidelberg.de> References: <57EE86D11538B44096C712532DBB6C5A0131C2B7AA5E@DKFZEX01.ad.dkfz-heidelberg.de> <55FAC667.5000901@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AE4D@DKFZEX01.ad.dkfz-heidelberg.de> Message-ID: <5602AF53.5010601@kitware.com> On 09/23/2015 08:40 AM, Kislinskiy, Stefan wrote: > I wrote the documentation, added a genex test that checks it the > given path is converted as expected on different platforms, and > added another ExternalProject test for Windows that invokes > pushd, which is is command sensitive to the path style. Thanks. I needed to fix a typo to get the latter test to run: - add_test(ExternalProjectShellPathGenex ${CMAKE_TEST_COMMAND} + add_test(ExternalProjectShellPathGenex ${CMAKE_CTEST_COMMAND} However, it fails when there is a space in the path because the conversion result ends up as something like "\"c:\path with space\...\"" The problem is that the genex evaluates and adds the quotes and then the custom command generator escapes the argument for the shell again. The problem is that ConvertToOutputFormat is meant as the final conversion step when writing a path into a shell command in the generator, so it quotes values with spaces and may add other escapes ad needed for the build system script (e.g. the Makefile). The custom command generator will then repeat all that with another layer. Therefore ConvertToOutputFormat is not the right implementation for SHELL_PATH. I think we want just the slash conversion to be done by the genex. Unfortunately the proper sequence of path escaping steps depends on the context in which the path will be written. When using $ inside add_custom_command we want it to do just the slash conversion because add_custom_command will take care of the rest of the layers of escaping. However, in case of using file(GENERATE) for a .cmd file then we would want the quoting too. Perhaps we can defer that use case to later work with a separate $ genex. > I wasn't sure about the VERSION I am supposed to write into the > cmake_minimum_required() line in > Tests/ExternalProjectShellPathGenex/CMakeLists.txt, so I chose > 3.3.20150923. That's fine. Thanks, -Brad From Gilles.Khouzam at microsoft.com Wed Sep 23 10:03:09 2015 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Wed, 23 Sep 2015 14:03:09 +0000 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: <56029D3D.80405@kitware.com> References: <55E4B396.9090609@kitware.com> <55E714E1.10505@kitware.com> <55F0496A.1040205@kitware.com> <55F18811.8000400@kitware.com> <55F1D428.4030707@kitware.com> <55F1D516.802@kitware.com> <56001D8D.3070703@kitware.com> <56029D3D.80405@kitware.com> Message-ID: >CMAKE_SYSTEM_NAME is already always defined to a value detected from the host system when not defined by a toolchain file or by the user in the cache. On a Windows host the value will be "Windows". >I don't fully understand the case in question. When not building for Windows Store, does WindowsTargetPlatformVersion need a value if the user does not request one? What happens if it does not get a value? Is it >needed for Windows 10 Desktop? Ok, if the CMAKE_SYSTEM_NAME is defined as Windows by default, then this should be good. Yes, the property is also used in desktop if someone wants to use the Windows 10 SDK instead of the Windows 8.1 SDK. If the property is not present then the default is to use the Windows 8.1 SDK. I'm suggesting that if the SYSTEM_NAME is Windows but the Version is set to 10.0 then we can use the same logic as for Store apps. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Wednesday, September 23, 2015 05:38 To: Gilles Khouzam Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/23/2015 01:29 AM, Gilles Khouzam wrote: > Now, for the default behavior, if > CMAKE_WINDOWS_TARGET_PLATFORM_VERSION is set through a toolchain file > or the project, then that will be the default which will initialize > the WINDOWS_TARGET_PLATFORM_VERSION for each target through the > SetPropertyDefault initialization call. On the other hand, if > CMAKE_WINDOWS_TARGET_PLATFORM_VERSION is not set, nothing should > happen since this is not a required property other than for Windows 10 > Universal (store) apps, the default behavior in that case should be to > not have the property. Okay. > There is one open issue though. How should we have the value for > CMAKE_WINDOWS_TARGET_PLATFORM_VERSION be the latest installed SDK when > this is not a Windows Store project? For Windows Store projects this > would get set if the property is not defined through the > InitializeSystem procedure. How would we handle this for the non > Windows Store case? Do this based on the version and no > CMAKE_SYSTEM_NAME defined? Or should we force there to be a > CMAKE_SYSTEM_NAME to be defined as Windows for example? CMAKE_SYSTEM_NAME is already always defined to a value detected from the host system when not defined by a toolchain file or by the user in the cache. On a Windows host the value will be "Windows". I don't fully understand the case in question. When not building for Windows Store, does WindowsTargetPlatformVersion need a value if the user does not request one? What happens if it does not get a value? Is it needed for Windows 10 Desktop? Thanks, -Brad From Robert.Goulet at autodesk.com Wed Sep 23 10:11:08 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Wed, 23 Sep 2015 14:11:08 +0000 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> <19a621155766478db4203cc519bf62d6@BN1PR79MB007.MGDADSK.autodesk.com> <8aba767832a14419b4cbdf810b88b116@BN1PR79MB007.MGDADSK.autodesk.com> Message-ID: <99e0293109fc4ee8b5dff7a745e39d02@BN1PR79MB007.MGDADSK.autodesk.com> Brad, if I made that patch clean with tests, would you accept it for 3.4? It doesn't require any refactoring with what Steven mentioned. -----Original Message----- From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Stephen Kelly Sent: Tuesday, September 22, 2015 5:36 PM To: cmake-developers at cmake.org Subject: Re: [cmake-developers] Generator expressions for install destination Robert Goulet wrote: > Yeah I guess it could look something like this (attachment). Yes, something like that (modulo the long line). > However I > just realized that if I don't also get install(DIRECTORY) in 3.4 then > this is not worth rushing it, since as you mention I would also need > to write proper test cases. > > Just let me know when I can start looking at this again (after your > refactoring is done) and I'll try to do the proper work to make it > work with all install types destinations (files, directory and export). My refactoring won't affect the files and directory much, so you can proceed similar to that patch without conflicting. An appropriate branch like that could be committed before my refactoring, depending on when it is ready. My refactoring will only remove the `->GetMakefile()` part from affected lines, but it will take a while to get to the point where that can actually be done, so you don't need to wait for it. 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 brad.king at kitware.com Wed Sep 23 10:16:46 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Sep 2015 10:16:46 -0400 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: References: <55E4B396.9090609@kitware.com> <55E714E1.10505@kitware.com> <55F0496A.1040205@kitware.com> <55F18811.8000400@kitware.com> <55F1D428.4030707@kitware.com> <55F1D516.802@kitware.com> <56001D8D.3070703@kitware.com> <56029D3D.80405@kitware.com> Message-ID: <5602B44E.5030309@kitware.com> On 09/23/2015 10:03 AM, Gilles Khouzam wrote: > If the property is not present then the default is to use the Windows 8.1 SDK. Thanks for explaining that VS behavior. > I'm suggesting that if the SYSTEM_NAME is Windows but the Version is set > to 10.0 then we can use the same logic as for Store apps. Yes, if CMAKE_SYSTEM_NAME is "Windows" and CMAKE_SYSTEM_VERSION indicates Windows > 8.1 then we should use the latest SDK that is available but not newer than the version of Windows targeted. BTW, what are the values of CMAKE_HOST_SYSTEM_VERSION on Windows 7, 8, 8.1, and 10 when CMake is built with the new manifest file? IIUC they should be: Windows 7 => 6.1 Windows 8 => 6.2 Windows 8.1 => 6.3 Windows 10 => 10.0 plus a third component for the Windows build number. Thanks, -Brad From brad.king at kitware.com Wed Sep 23 10:19:28 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Sep 2015 10:19:28 -0400 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: <99e0293109fc4ee8b5dff7a745e39d02@BN1PR79MB007.MGDADSK.autodesk.com> References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> <19a621155766478db4203cc519bf62d6@BN1PR79MB007.MGDADSK.autodesk.com> <8aba767832a14419b4cbdf810b88b116@BN1PR79MB007.MGDADSK.autodesk.com> <99e0293109fc4ee8b5dff7a745e39d02@BN1PR79MB007.MGDADSK.autodesk.com> Message-ID: <5602B4F0.4000101@kitware.com> On 09/23/2015 10:11 AM, Robert Goulet wrote: > if I made that patch clean with tests, would you accept it for 3.4? Likely yes. I was only suggesting the delay to avoid regressing Steve's refactoring work. Please use "git format-patch" to produce the patch file attachments. That way your authorship info and commit message can be included. Thanks, -Brad From s.kislinskiy at Dkfz-Heidelberg.de Wed Sep 23 10:45:53 2015 From: s.kislinskiy at Dkfz-Heidelberg.de (Kislinskiy, Stefan) Date: Wed, 23 Sep 2015 16:45:53 +0200 Subject: [cmake-developers] generator expression for path slash conversion In-Reply-To: <5602AF53.5010601@kitware.com> References: <57EE86D11538B44096C712532DBB6C5A0131C2B7AA5E@DKFZEX01.ad.dkfz-heidelberg.de> <55FAC667.5000901@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AE4D@DKFZEX01.ad.dkfz-heidelberg.de> <5602AF53.5010601@kitware.com> Message-ID: <57EE86D11538B44096C712532DBB6C5A0131C2B7AE80@DKFZEX01.ad.dkfz-heidelberg.de> I see. I would suggest that I add another output flag to cmOutputConverter like SHELL_NO_ESCAPE then. If this flag is passed to ConvertToOutputFormat() instead of SHELL, the call of EscapeForShell() will be circumvented. This way there wouldn't be code duplication and we would still cover the MSYS case (drive letter conversion). Something that just came to my mind: Isn't it possible to specify parameters for generator expressions? - How about something like $? -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Mittwoch, 23. September 2015 15:56 To: Kislinskiy, Stefan Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] generator expression for path slash conversion On 09/23/2015 08:40 AM, Kislinskiy, Stefan wrote: > I wrote the documentation, added a genex test that checks it the given > path is converted as expected on different platforms, and added > another ExternalProject test for Windows that invokes pushd, which is > is command sensitive to the path style. Thanks. I needed to fix a typo to get the latter test to run: - add_test(ExternalProjectShellPathGenex ${CMAKE_TEST_COMMAND} + add_test(ExternalProjectShellPathGenex ${CMAKE_CTEST_COMMAND} However, it fails when there is a space in the path because the conversion result ends up as something like "\"c:\path with space\...\"" The problem is that the genex evaluates and adds the quotes and then the custom command generator escapes the argument for the shell again. The problem is that ConvertToOutputFormat is meant as the final conversion step when writing a path into a shell command in the generator, so it quotes values with spaces and may add other escapes ad needed for the build system script (e.g. the Makefile). The custom command generator will then repeat all that with another layer. Therefore ConvertToOutputFormat is not the right implementation for SHELL_PATH. I think we want just the slash conversion to be done by the genex. Unfortunately the proper sequence of path escaping steps depends on the context in which the path will be written. When using $ inside add_custom_command we want it to do just the slash conversion because add_custom_command will take care of the rest of the layers of escaping. However, in case of using file(GENERATE) for a .cmd file then we would want the quoting too. Perhaps we can defer that use case to later work with a separate $ genex. > I wasn't sure about the VERSION I am supposed to write into the > cmake_minimum_required() line in > Tests/ExternalProjectShellPathGenex/CMakeLists.txt, so I chose > 3.3.20150923. That's fine. Thanks, -Brad From brad.king at kitware.com Wed Sep 23 10:57:07 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Sep 2015 10:57:07 -0400 Subject: [cmake-developers] generator expression for path slash conversion In-Reply-To: <57EE86D11538B44096C712532DBB6C5A0131C2B7AE80@DKFZEX01.ad.dkfz-heidelberg.de> References: <57EE86D11538B44096C712532DBB6C5A0131C2B7AA5E@DKFZEX01.ad.dkfz-heidelberg.de> <55FAC667.5000901@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AE4D@DKFZEX01.ad.dkfz-heidelberg.de> <5602AF53.5010601@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AE80@DKFZEX01.ad.dkfz-heidelberg.de> Message-ID: <5602BDC3.1090000@kitware.com> On 09/23/2015 10:45 AM, Kislinskiy, Stefan wrote: > I see. I would suggest that I add another output flag to > cmOutputConverter like SHELL_NO_ESCAPE then. If this flag is passed > to ConvertToOutputFormat() instead of SHELL, the call of > EscapeForShell() will be circumvented. This way there wouldn't be > code duplication and we would still cover the MSYS case > (drive letter conversion). The conversion code in question is about 10 lines and could be factored out into another helper method. Then the genex impl could just use the helper directly. > Isn't it possible to specify parameters for generator expressions? Yes. > How about something like $? Neat idea. However, for now I'd rather not try to predict the use cases for which such parameters will be needed. Instead we should just make sure the interface leaves room for future extension. Since "," is allowed in paths we cannot simply disallow it or blindly use it as a separator. Therefore we should have the actual path always be the last parameter. For now I think you can just require (with an error) that the value given to SHELL_PATH as input must be an absolute path (cmSystemTools::FileIsFullPath). Then in the future we could recognize things like $ without ambiguity. Please include test cases for errors on relative paths (see Tests/RunCMake/GeneratorExpression). Thanks, -Brad From marc.chevrier at sap.com Wed Sep 23 11:00:07 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Wed, 23 Sep 2015 15:00:07 +0000 Subject: [cmake-developers] [CPack][BUG] Fail to package with CPACK_INSTALLED_DIRECTORIES In-Reply-To: <35211127-F170-4181-AA16-59E46FD0D3DE@sap.com> References: <35211127-F170-4181-AA16-59E46FD0D3DE@sap.com> Message-ID: <54E7B154-AFE7-4B8C-81C1-335525D0E73C@sap.com> Any comments about this problem? From: cmake-developers on behalf of SAP SAP Date: Tuesday 15 September 2015 09:42 To: "cmake-developers at cmake.org" Subject: [cmake-developers] [CPack][BUG] Fail to package with CPACK_INSTALLED_DIRECTORIES Hi, To enable to handle various packages as part of the same project and to avoid to execute preinstall target before packaging, I rely on CPack variables CPACK_INSTALLED_DIRECTORIES and CPACK_INSTALL_COMMANDS. Unfortunately, packaging is failing in the following conditions: * Platform Windows (regardless generator: test done with ?Visual Studio? and "Ninja?) * Install command with PERMISSIONS read-only (like OWNER_READ) * PROJECT command with LANGUAGES CXX (specifying LANGUAGES NONE is OK !??) In this case, installed read-only files cannot be copied by CPack. Attached is a CMakeLists.txt showing the problem: * Target package-OK generates the expected package (no read-only permissions) * Target package-KO fails to generate the package (same as previous one except read-only permissions) Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Sep 23 11:34:32 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Sep 2015 11:34:32 -0400 Subject: [cmake-developers] Help with diagnosing dashboard failure In-Reply-To: References: Message-ID: <5602C688.2030609@kitware.com> On 09/22/2015 05:03 PM, Stephen Kelly wrote: > A few days ago I merged a commit which moves the construction of > cmLocalGenerator objects. > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3aa333d > > It fails on the RunCMake.try_compile test on several dashboards in the > CMP0056 test at the end where the policy is set to NEW. [snip] > I am unable to reproduce the problem. I'm able to reproduce it on 64-bit Linux with the Unix Makefiles generator. However, I cannot do it with just a3aa333d. The test failures reported on the dashboard a few days ago were actually using this version: Merge topic 'fix-max-path-initialization' into next http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2cdc6d09 That topic includes 26cae90b, a revision of a3aa333d, followed by several more changes. The merge base of that topic does not fail but the head of the topic does. Within the topic the problem bisects to: cmGlobalGenerator: Create local generator after configuring the makefile. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d3f6ff43 Can you reproduce it with that version? -Brad From steveire at gmail.com Wed Sep 23 13:15:59 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 23 Sep 2015 19:15:59 +0200 Subject: [cmake-developers] Help with diagnosing dashboard failure References: <5602C688.2030609@kitware.com> Message-ID: Brad King wrote: > On 09/22/2015 05:03 PM, Stephen Kelly wrote: >> A few days ago I merged a commit which moves the construction of >> cmLocalGenerator objects. >> >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3aa333d >> >> It fails on the RunCMake.try_compile test on several dashboards in the >> CMP0056 test at the end where the policy is set to NEW. > [snip] >> I am unable to reproduce the problem. > > I'm able to reproduce it on 64-bit Linux with the Unix Makefiles > generator. However, I cannot do it with just a3aa333d. Interesting, thanks for trying it. I had a report that it failed on the first commit of the fix-max-path-initialization branch which is currently in stage. > The > test failures reported on the dashboard a few days ago were > actually using this version: > > Merge topic 'fix-max-path-initialization' into next > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2cdc6d09 > > That topic includes 26cae90b, a revision of a3aa333d, Yes, however the revision was not correct. The current fix-max-path- initialization branch does not use that revision. > followed > by several more changes. The merge base of that topic does not > fail but the head of the topic does. Within the topic the problem > bisects to: > > cmGlobalGenerator: Create local generator after configuring the makefile. > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d3f6ff43 > > Can you reproduce it with that version? That commit fails because it is based on 26cae90b. I would expect every test to fail with that commit, not just the RunCMake.try_compile test. If I checkout fix-max-path-initialization and run git rebase -i --exec 'cd /home/stephen/dev/src/cmake-master-build2 && ninja install && ctest -R ke.try_comp' origin/master then every commit passes RunCMake.try_compile for me. Thanks, Steve. From Robert.Goulet at autodesk.com Wed Sep 23 13:47:43 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Wed, 23 Sep 2015 17:47:43 +0000 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: <5602B4F0.4000101@kitware.com> References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> <19a621155766478db4203cc519bf62d6@BN1PR79MB007.MGDADSK.autodesk.com> <8aba767832a14419b4cbdf810b88b116@BN1PR79MB007.MGDADSK.autodesk.com> <99e0293109fc4ee8b5dff7a745e39d02@BN1PR79MB007.MGDADSK.autodesk.com> <5602B4F0.4000101@kitware.com> Message-ID: <39598d62613f44dba05a4e825c6fd3a3@BN1PR79MB007.MGDADSK.autodesk.com> Updated patch for install(FILES) DESTINATION genex support. Test added as well. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Wednesday, September 23, 2015 10:19 AM To: Robert Goulet ; Stephen Kelly ; cmake-developers at cmake.org Subject: Re: [cmake-developers] Generator expressions for install destination On 09/23/2015 10:11 AM, Robert Goulet wrote: > if I made that patch clean with tests, would you accept it for 3.4? Likely yes. I was only suggesting the delay to avoid regressing Steve's refactoring work. Please use "git format-patch" to produce the patch file attachments. That way your authorship info and commit message can be included. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: install-files-dest-genex.patch Type: application/octet-stream Size: 6962 bytes Desc: install-files-dest-genex.patch URL: From brad.king at kitware.com Wed Sep 23 14:26:29 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Sep 2015 14:26:29 -0400 Subject: [cmake-developers] Help with diagnosing dashboard failure In-Reply-To: References: <5602C688.2030609@kitware.com> Message-ID: <5602EED5.5040700@kitware.com> On 09/23/2015 01:15 PM, Stephen Kelly wrote: > Yes, however the revision was not correct. The current fix-max-path- > initialization branch does not use that revision. > >> cmGlobalGenerator: Create local generator after configuring the makefile. >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d3f6ff43 >> >> Can you reproduce it with that version? > > That commit fails because it is based on 26cae90b. I would expect every test > to fail with that commit, not just the RunCMake.try_compile test. Well, that's the version on which the dashboard reported lots of failures. If the new version of the topic does not have that problem, then where was trouble with it reported on the dashboard? -Brad From brad.king at kitware.com Wed Sep 23 15:02:41 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Sep 2015 15:02:41 -0400 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: <39598d62613f44dba05a4e825c6fd3a3@BN1PR79MB007.MGDADSK.autodesk.com> References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> <19a621155766478db4203cc519bf62d6@BN1PR79MB007.MGDADSK.autodesk.com> <8aba767832a14419b4cbdf810b88b116@BN1PR79MB007.MGDADSK.autodesk.com> <99e0293109fc4ee8b5dff7a745e39d02@BN1PR79MB007.MGDADSK.autodesk.com> <5602B4F0.4000101@kitware.com> <39598d62613f44dba05a4e825c6fd3a3@BN1PR79MB007.MGDADSK.autodesk.com> Message-ID: <5602F751.60900@kitware.com> On 09/23/2015 01:47 PM, Robert Goulet wrote: > Updated patch for install(FILES) DESTINATION genex support. Test added as well. Thanks. I applied it without the test: install: Allow generator expressions in FILES DESTINATION http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=17aa6fd3 and then added alternative tests: Tests: Cover install(FILES) with a genex DESTINATION http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=69ab5f55 I was concerned that the original test case depended too much on possibly platform-specific file names and such. I also added a test for a bad genex producing an error message. -Brad From steveire at gmail.com Wed Sep 23 15:13:50 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 23 Sep 2015 21:13:50 +0200 Subject: [cmake-developers] Help with diagnosing dashboard failure References: <5602C688.2030609@kitware.com> <5602EED5.5040700@kitware.com> Message-ID: Brad King wrote: > On 09/23/2015 01:15 PM, Stephen Kelly wrote: >> Yes, however the revision was not correct. The current fix-max-path- >> initialization branch does not use that revision. >> >>> cmGlobalGenerator: Create local generator after configuring the >>> makefile. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d3f6ff43 >>> >>> Can you reproduce it with that version? >> >> That commit fails because it is based on 26cae90b. I would expect every >> test to fail with that commit, not just the RunCMake.try_compile test. > > Well, that's the version on which the dashboard reported lots of failures. > If the new version of the topic does not have that problem, then where > was trouble with it reported on the dashboard? Here for example: https://open.cdash.org/testDetails.php?test=375168917&build=4019052 which is based on 2cdc6d09. Regardless of 26cae90b or a3aa333d, the code fragment is later removed in the 'cmGlobalGenerator: Create local generators after all makefiles configured.' commit. 26cae90b and a3aa333d are both intermediate states, but it is the end of the branch for which many dashboard failures were reported https://open.cdash.org/index.php?project=CMake&date=2015-09-20 The end result of the current fix-max-path-initialization branch is the same as it was then. Thanks, Steve. From Robert.Goulet at autodesk.com Wed Sep 23 15:19:22 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Wed, 23 Sep 2015 19:19:22 +0000 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: <5602F751.60900@kitware.com> References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> <19a621155766478db4203cc519bf62d6@BN1PR79MB007.MGDADSK.autodesk.com> <8aba767832a14419b4cbdf810b88b116@BN1PR79MB007.MGDADSK.autodesk.com> <99e0293109fc4ee8b5dff7a745e39d02@BN1PR79MB007.MGDADSK.autodesk.com> <5602B4F0.4000101@kitware.com> <39598d62613f44dba05a4e825c6fd3a3@BN1PR79MB007.MGDADSK.autodesk.com> <5602F751.60900@kitware.com> Message-ID: Alright thanks Brad! I have a similar change that applies the exact same code logic to install(DIRECTORY), but I haven't wrote the test yet. Should I still write a test for it before I send it to you? -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Wednesday, September 23, 2015 3:03 PM To: Robert Goulet ; cmake-developers at cmake.org Subject: Re: [cmake-developers] Generator expressions for install destination On 09/23/2015 01:47 PM, Robert Goulet wrote: > Updated patch for install(FILES) DESTINATION genex support. Test added as well. Thanks. I applied it without the test: install: Allow generator expressions in FILES DESTINATION http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=17aa6fd3 and then added alternative tests: Tests: Cover install(FILES) with a genex DESTINATION http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=69ab5f55 I was concerned that the original test case depended too much on possibly platform-specific file names and such. I also added a test for a bad genex producing an error message. -Brad From brad.king at kitware.com Wed Sep 23 15:37:20 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Sep 2015 15:37:20 -0400 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> <19a621155766478db4203cc519bf62d6@BN1PR79MB007.MGDADSK.autodesk.com> <8aba767832a14419b4cbdf810b88b116@BN1PR79MB007.MGDADSK.autodesk.com> <99e0293109fc4ee8b5dff7a745e39d02@BN1PR79MB007.MGDADSK.autodesk.com> <5602B4F0.4000101@kitware.com> <39598d62613f44dba05a4e825c6fd3a3@BN1PR79MB007.MGDADSK.autodesk.com> <5602F751.60900@kitware.com> Message-ID: <5602FF70.9030808@kitware.com> On 09/23/2015 03:19 PM, Robert Goulet wrote: > I have a similar change that applies the exact same code logic > to install(DIRECTORY), but I haven't wrote the test yet. Should > I still write a test for it before I send it to you? Yes, please. Base the commit on 69ab5f55. You should be able to find install(DIRECTORY) calls in SimpleInstall and ExportImport similar to those I updated for install(FILES). Thanks, -Brad From brad.king at kitware.com Wed Sep 23 16:43:03 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Sep 2015 16:43:03 -0400 Subject: [cmake-developers] Help with diagnosing dashboard failure In-Reply-To: References: <5602C688.2030609@kitware.com> <5602EED5.5040700@kitware.com> Message-ID: <56030ED7.4010505@kitware.com> On 09/23/2015 03:13 PM, Stephen Kelly wrote: > The end result of the current fix-max-path-initialization branch is the same > as it was then. Okay. I can reproduce it with the current topic (ba7f7067..16354083). Within the topic it bisects to: -------------------------------------------------------------------------- f287bd4a94afc8064762144c405cfdee502323f8 is the first bad commit commit f287bd4a94afc8064762144c405cfdee502323f8 Author: Stephen Kelly Date: Sun Sep 13 20:32:33 2015 +0200 cmGlobalGenerator: Create local generator after configuring the makefile. -------------------------------------------------------------------------- With that version I can reproduce it on 64-bit Linux with Unix Makefiles in a CMAKE_BUILD_TYPE=Debug build. This corresponds to the same result as my earlier post. Can you reproduce it with that version? -Brad From Robert.Goulet at autodesk.com Wed Sep 23 17:18:41 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Wed, 23 Sep 2015 21:18:41 +0000 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: <5602FF70.9030808@kitware.com> References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> <19a621155766478db4203cc519bf62d6@BN1PR79MB007.MGDADSK.autodesk.com> <8aba767832a14419b4cbdf810b88b116@BN1PR79MB007.MGDADSK.autodesk.com> <99e0293109fc4ee8b5dff7a745e39d02@BN1PR79MB007.MGDADSK.autodesk.com> <5602B4F0.4000101@kitware.com> <39598d62613f44dba05a4e825c6fd3a3@BN1PR79MB007.MGDADSK.autodesk.com> <5602F751.60900@kitware.com> <5602FF70.9030808@kitware.com> Message-ID: Here is the patch to support genex for install(DIRECTORY) command DESTINATION option. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Wednesday, September 23, 2015 3:37 PM To: Robert Goulet ; cmake-developers at cmake.org Subject: Re: [cmake-developers] Generator expressions for install destination On 09/23/2015 03:19 PM, Robert Goulet wrote: > I have a similar change that applies the exact same code logic to > install(DIRECTORY), but I haven't wrote the test yet. Should I still > write a test for it before I send it to you? Yes, please. Base the commit on 69ab5f55. You should be able to find install(DIRECTORY) calls in SimpleInstall and ExportImport similar to those I updated for install(FILES). Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: install-dir-dest-genex.patch Type: application/octet-stream Size: 11206 bytes Desc: install-dir-dest-genex.patch URL: From Gilles.Khouzam at microsoft.com Wed Sep 23 18:48:41 2015 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Wed, 23 Sep 2015 22:48:41 +0000 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: <5602B44E.5030309@kitware.com> References: <55E4B396.9090609@kitware.com> <55E714E1.10505@kitware.com> <55F0496A.1040205@kitware.com> <55F18811.8000400@kitware.com> <55F1D428.4030707@kitware.com> <55F1D516.802@kitware.com> <56001D8D.3070703@kitware.com> <56029D3D.80405@kitware.com> <5602B44E.5030309@kitware.com> Message-ID: Ok, I've got this working as discussed. This adds only the WINDOWS_TARGET_PLATFORM_VERSION property as it currently only supports the desktop scenario and is extracted from the rest of the Windows 10 Store support. This property enables a Windows 10 Desktop project to use a specific version of the Windows 10. If CMAKE_SYSTEM_VERSION is set to 10.0 then the latest Windows 10 SDK but not more recent than the current build of Windows. If you want to specify a specific version to use, then there is the global property CMAKE_WINDOWS_TARGET_PLATFORM_VERSION that will be passed down to each target. To specify a value for a specific target there is the target property WINDOWS_TARGET_PLATFORM_VERSION. There is one thing that I've changed that I want to make sure is the right thing. As it stands, CMAKE_SYSTEM_VERSION is only valid when cross-compiling, I've changed the CMakeDetermineSystem.cmake file to not use the HOST_SYSTEM_VERSION when CMAKE_SYSTEM_VERSION is set. Otherwise, we can only use this feature through CMAKE_SYSTEM_VERSION on cross-compiling scenarios. I'm not sure what the best way to test this feature, it can be added to any desktop project on Windows 10 and it should work properly. I've tried it with CMake itself and it's working fine and building against the Win10 SDK. Yes, you have the right versions for all the CMAKE_HOST_SYSTEM_VERSION for the different OS versions. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Wednesday, September 23, 2015 07:17 To: Gilles Khouzam Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/23/2015 10:03 AM, Gilles Khouzam wrote: > If the property is not present then the default is to use the Windows 8.1 SDK. Thanks for explaining that VS behavior. > I'm suggesting that if the SYSTEM_NAME is Windows but the Version is > set to 10.0 then we can use the same logic as for Store apps. Yes, if CMAKE_SYSTEM_NAME is "Windows" and CMAKE_SYSTEM_VERSION indicates Windows > 8.1 then we should use the latest SDK that is available but not newer than the version of Windows targeted. BTW, what are the values of CMAKE_HOST_SYSTEM_VERSION on Windows 7, 8, 8.1, and 10 when CMake is built with the new manifest file? IIUC they should be: Windows 7 => 6.1 Windows 8 => 6.2 Windows 8.1 => 6.3 Windows 10 => 10.0 plus a third component for the Windows build number. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: WindowsTargetPlatform.patch Type: application/octet-stream Size: 13828 bytes Desc: WindowsTargetPlatform.patch URL: From steveire at gmail.com Thu Sep 24 03:04:02 2015 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 24 Sep 2015 09:04:02 +0200 Subject: [cmake-developers] Help with diagnosing dashboard failure References: <5602C688.2030609@kitware.com> <5602EED5.5040700@kitware.com> <56030ED7.4010505@kitware.com> Message-ID: Brad King wrote: > On 09/23/2015 03:13 PM, Stephen Kelly wrote: >> The end result of the current fix-max-path-initialization branch is the >> same as it was then. > > Okay. I can reproduce it with the current topic (ba7f7067..16354083). > Within the topic it bisects to: > > -------------------------------------------------------------------------- > f287bd4a94afc8064762144c405cfdee502323f8 is the first bad commit > commit f287bd4a94afc8064762144c405cfdee502323f8 > Author: Stephen Kelly > Date: Sun Sep 13 20:32:33 2015 +0200 > > cmGlobalGenerator: Create local generator after configuring the > makefile. > -------------------------------------------------------------------------- > > With that version I can reproduce it on 64-bit Linux with Unix Makefiles > in a CMAKE_BUILD_TYPE=Debug build. This corresponds to the same result > as my earlier post. > > Can you reproduce it with that version? Yes, I can now. I realized that I was using the Ninja generator instead of Makefiles. Thanks! Steve. From domen.vrankar at gmail.com Thu Sep 24 03:06:51 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Thu, 24 Sep 2015 09:06:51 +0200 Subject: [cmake-developers] [CPack][BUG] Fail to package with CPACK_INSTALLED_DIRECTORIES In-Reply-To: <54E7B154-AFE7-4B8C-81C1-335525D0E73C@sap.com> References: <35211127-F170-4181-AA16-59E46FD0D3DE@sap.com> <54E7B154-AFE7-4B8C-81C1-335525D0E73C@sap.com> Message-ID: 2015-09-23 17:00 GMT+02:00 CHEVRIER, Marc : > Any comments about this problem? Sorry I've forgotten about this mail... From what you're describing it should work. I'll take a look later today and get back to you then. Thanks, Domen From ruslan_baratov at yahoo.com Thu Sep 24 06:10:29 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 24 Sep 2015 13:10:29 +0300 Subject: [cmake-developers] Patch: install universal iOS libraries Message-ID: <5603CC15.5070201@yahoo.com> Hi, Patches help to install universal iOS (device + simulator) libraries by triggering some extra instructions (build + fuse) after "regular" library installation finished. This behavior controlled by CMake variable CMAKE_IOS_INSTALL_UNIVERSAL_LIBS. = Example = > cat CMakeLists.txt cmake_minimum_required(VERSION 3.0) project(Foo) add_library(foo foo.cpp) install(TARGETS foo DESTINATION lib) > cat toolchain.cmake set(CMAKE_MACOSX_BUNDLE YES) set(CMAKE_OSX_SYSROOT "iphoneos") set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer") set(MACOSX_BUNDLE_GUI_IDENTIFIER "com.example") > rm -rf _builds _install > cmake -H. -B_builds -GXcode -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake -DCMAKE_INSTALL_PREFIX=_install ... = Current functionality = Device one arch (default): > cmake ... > cmake --build _builds --target install > lipo -info _install/lib/libfoo.a Non-fat file: _install/lib/libfoo.a is architecture: armv7 Simulator one arch: > cmake ... > cmake --build _builds --target install -- -sdk iphonesimulator > lipo -info _install/lib/libfoo.a Non-fat file: _install/lib/libfoo.a is architecture: x86_64 Device multi arch: > cmake ... -DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO > cmake --build _builds --target install > lipo -info _install/lib/libfoo.a Architectures in the fat file: _install/lib/libfoo.a are: armv7 arm64 Simulator multi arch: > cmake ... -DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO > cmake --build _builds --target install -- -sdk iphonesimulator > lipo -info _install/lib/libfoo.a Architectures in the fat file: _install/lib/libfoo.a are: i386 x86_64 = This upgrade = Device + simulator one arch: > cmake ... -DCMAKE_IOS_INSTALL_UNIVERSAL_LIBS=YES > cmake --build _builds --target install > lipo -info _install/lib/libfoo.a Architectures in the fat file: _install/lib/libfoo.a are: armv7 x86_64 Device + simulator multi arch: > cmake ... -DCMAKE_IOS_INSTALL_UNIVERSAL_LIBS=YES -DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO > cmake --build _builds --target install > lipo -info _install/lib/libfoo.a Architectures in the fat file: _install/lib/libfoo.a are: i386 armv7 x86_64 arm64 Let me know if this looks acceptable, then I will add documentation part and tests. Thanks, Ruslo -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Get-target-name-for-universal-iOS-library-install.patch Type: text/x-patch Size: 2268 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-CMake-module-for-universal-iOS-library-install.patch Type: text/x-patch Size: 9361 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Universal-iOS-library-install.patch Type: text/x-patch Size: 2834 bytes Desc: not available URL: From s.kislinskiy at Dkfz-Heidelberg.de Thu Sep 24 09:05:40 2015 From: s.kislinskiy at Dkfz-Heidelberg.de (Kislinskiy, Stefan) Date: Thu, 24 Sep 2015 15:05:40 +0200 Subject: [cmake-developers] generator expression for path slash conversion In-Reply-To: <5602BDC3.1090000@kitware.com> References: <57EE86D11538B44096C712532DBB6C5A0131C2B7AA5E@DKFZEX01.ad.dkfz-heidelberg.de> <55FAC667.5000901@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AE4D@DKFZEX01.ad.dkfz-heidelberg.de> <5602AF53.5010601@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AE80@DKFZEX01.ad.dkfz-heidelberg.de> <5602BDC3.1090000@kitware.com> Message-ID: <57EE86D11538B44096C712532DBB6C5A0131C2B7AF76@DKFZEX01.ad.dkfz-heidelberg.de> I factored out the code from cmOutputConverter::ConvertToOutputFormat() into another helper method called ConvertDirectorySeparatorsForShell(), changed the SHELL_PATH genex to accept only absolute paths, and changed its documentation accordingly. I also added a BadSHELL_PATH test to the RunCMake/GeneratorExpression tests, that use the SHELL_PATH genex with an empty parameter as well as a relative path. I also fixed the TEST/CTEST typo you discovered yesterday. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Mittwoch, 23. September 2015 16:57 To: Kislinskiy, Stefan Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] generator expression for path slash conversion On 09/23/2015 10:45 AM, Kislinskiy, Stefan wrote: > I see. I would suggest that I add another output flag to > cmOutputConverter like SHELL_NO_ESCAPE then. If this flag is passed to > ConvertToOutputFormat() instead of SHELL, the call of > EscapeForShell() will be circumvented. This way there wouldn't be code > duplication and we would still cover the MSYS case (drive letter > conversion). The conversion code in question is about 10 lines and could be factored out into another helper method. Then the genex impl could just use the helper directly. > Isn't it possible to specify parameters for generator expressions? Yes. > How about something like $? Neat idea. However, for now I'd rather not try to predict the use cases for which such parameters will be needed. Instead we should just make sure the interface leaves room for future extension. Since "," is allowed in paths we cannot simply disallow it or blindly use it as a separator. Therefore we should have the actual path always be the last parameter. For now I think you can just require (with an error) that the value given to SHELL_PATH as input must be an absolute path (cmSystemTools::FileIsFullPath). Then in the future we could recognize things like $ without ambiguity. Please include test cases for errors on relative paths (see Tests/RunCMake/GeneratorExpression). Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: shell_path_genex_v4.patch Type: application/octet-stream Size: 14515 bytes Desc: shell_path_genex_v4.patch URL: From DLRdave at aol.com Thu Sep 24 09:52:07 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 24 Sep 2015 09:52:07 -0400 Subject: [cmake-developers] generator expression for path slash conversion In-Reply-To: <57EE86D11538B44096C712532DBB6C5A0131C2B7AF76@DKFZEX01.ad.dkfz-heidelberg.de> References: <57EE86D11538B44096C712532DBB6C5A0131C2B7AA5E@DKFZEX01.ad.dkfz-heidelberg.de> <55FAC667.5000901@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AE4D@DKFZEX01.ad.dkfz-heidelberg.de> <5602AF53.5010601@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AE80@DKFZEX01.ad.dkfz-heidelberg.de> <5602BDC3.1090000@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AF76@DKFZEX01.ad.dkfz-heidelberg.de> Message-ID: Unfortunately, "pushd" is an inappropriate command to use when the argument is quoted. It works just fine with "/" characters if the argument is quoted... For example: C:\Users\davidcole>pushd C:\Windows\System32 C:\Windows\System32>pushd C:/dev The syntax of the command is incorrect. C:\Windows\System32>pushd "C:/dev" C:\dev> It would be better to use a test command that **actually** fails when a "/" path is a quoted entity.... HTH, David C. On Thu, Sep 24, 2015 at 9:05 AM, Kislinskiy, Stefan wrote: > I factored out the code from cmOutputConverter::ConvertToOutputFormat() into another helper method called ConvertDirectorySeparatorsForShell(), changed the SHELL_PATH genex to accept only absolute paths, and changed its documentation accordingly. I also added a BadSHELL_PATH test to the RunCMake/GeneratorExpression tests, that use the SHELL_PATH genex with an empty parameter as well as a relative path. I also fixed the TEST/CTEST typo you discovered yesterday. > > -----Original Message----- > From: Brad King [mailto:brad.king at kitware.com] > Sent: Mittwoch, 23. September 2015 16:57 > To: Kislinskiy, Stefan > Cc: cmake-developers at cmake.org > Subject: Re: [cmake-developers] generator expression for path slash conversion > > On 09/23/2015 10:45 AM, Kislinskiy, Stefan wrote: >> I see. I would suggest that I add another output flag to >> cmOutputConverter like SHELL_NO_ESCAPE then. If this flag is passed to >> ConvertToOutputFormat() instead of SHELL, the call of >> EscapeForShell() will be circumvented. This way there wouldn't be code >> duplication and we would still cover the MSYS case (drive letter >> conversion). > > The conversion code in question is about 10 lines and could be factored out into another helper method. Then the genex impl could just use the helper directly. > >> Isn't it possible to specify parameters for generator expressions? > > Yes. > >> How about something like $? > > Neat idea. However, for now I'd rather not try to predict the use cases for which such parameters will be needed. Instead we should just make sure the interface leaves room for future extension. Since "," is allowed in paths we cannot simply disallow it or blindly use it as a separator. Therefore we should have the actual path always be the last parameter. > > For now I think you can just require (with an error) that the value given to SHELL_PATH as input must be an absolute path (cmSystemTools::FileIsFullPath). Then in the future we could recognize things like $ without ambiguity. Please include test cases for errors on relative paths (see Tests/RunCMake/GeneratorExpression). > > Thanks, > -Brad > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers From brad.king at kitware.com Thu Sep 24 10:21:30 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 24 Sep 2015 10:21:30 -0400 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> <19a621155766478db4203cc519bf62d6@BN1PR79MB007.MGDADSK.autodesk.com> <8aba767832a14419b4cbdf810b88b116@BN1PR79MB007.MGDADSK.autodesk.com> <99e0293109fc4ee8b5dff7a745e39d02@BN1PR79MB007.MGDADSK.autodesk.com> <5602B4F0.4000101@kitware.com> <39598d62613f44dba05a4e825c6fd3a3@BN1PR79MB007.MGDADSK.autodesk.com> <5602F751.60900@kitware.com> <5602FF70.9030808@kitware.com> Message-ID: <560406EA.2030501@kitware.com> On 09/23/2015 05:18 PM, Robert Goulet wrote: > Here is the patch to support genex for install(DIRECTORY) command > DESTINATION option. Thanks. Applied with minor tweaks: install: Allow generator expressions in DIRECTORY DESTINATION http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd189cc2 -Brad From brad.king at kitware.com Thu Sep 24 10:21:37 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 24 Sep 2015 10:21:37 -0400 Subject: [cmake-developers] generator expression for path slash conversion In-Reply-To: <57EE86D11538B44096C712532DBB6C5A0131C2B7AF76@DKFZEX01.ad.dkfz-heidelberg.de> References: <57EE86D11538B44096C712532DBB6C5A0131C2B7AA5E@DKFZEX01.ad.dkfz-heidelberg.de> <55FAC667.5000901@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AE4D@DKFZEX01.ad.dkfz-heidelberg.de> <5602AF53.5010601@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AE80@DKFZEX01.ad.dkfz-heidelberg.de> <5602BDC3.1090000@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AF76@DKFZEX01.ad.dkfz-heidelberg.de> Message-ID: <560406F1.6040901@kitware.com> On 09/24/2015 09:05 AM, Kislinskiy, Stefan wrote: > I factored out the code from cmOutputConverter::ConvertToOutputFormat() > into another helper method called ConvertDirectorySeparatorsForShell(), > changed the SHELL_PATH genex to accept only absolute paths, and changed > its documentation accordingly. I also added a BadSHELL_PATH test to the > RunCMake/GeneratorExpression tests, that use the SHELL_PATH genex with > an empty parameter as well as a relative path. I also fixed the > TEST/CTEST typo you discovered yesterday. Thanks. I started with a change to simplify the test infrastructure slightly: Tests: Simplify GeneratorExpression check implementation http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7de868c4 Then I applied your changes with minor tweaks and merged to 'next' for testing: Genex: Add a SHELL_PATH expression http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8adf6ab5 I left out the ExternalProjectShellPathGenex test because it fails on the Ninja, MSYS Makefiles, and MinGW Makefiles generators on Windows. The 'pushd' and 'popd' commands do not work there due to the way the build tool runs the command in a shell. It passed for me only in a VS IDE generator. See also David Cole's sibling response about this test. -Brad From brad.king at kitware.com Thu Sep 24 10:25:18 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 24 Sep 2015 10:25:18 -0400 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <56014F5E.5070901@kitware.com> References: <55FFFC53.8030309@kitware.com> <56007BCE.7050605@gmail.com> <56014F5E.5070901@kitware.com> Message-ID: <560407CE.8070703@kitware.com> On 09/22/2015 08:53 AM, Brad King wrote: > In this case we have a bug in a new feature that was > introduced in post-3.3 development so we need to either fix it or > remove the offending parts of the new features before Oct 1 for 3.4. In preparation for the 3.4 freeze I've added a topic to revert the entire change: Revert topic 'cmake-W-options' (#15747) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=81739e92 Currently it is in 'next' for testing. I will merge to 'master' before 3.4 if the regression cannot otherwise be fixed by then. -Brad From s.kislinskiy at Dkfz-Heidelberg.de Thu Sep 24 11:08:34 2015 From: s.kislinskiy at Dkfz-Heidelberg.de (Kislinskiy, Stefan) Date: Thu, 24 Sep 2015 17:08:34 +0200 Subject: [cmake-developers] generator expression for path slash conversion In-Reply-To: <560406F1.6040901@kitware.com> References: <57EE86D11538B44096C712532DBB6C5A0131C2B7AA5E@DKFZEX01.ad.dkfz-heidelberg.de> <55FAC667.5000901@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AE4D@DKFZEX01.ad.dkfz-heidelberg.de> <5602AF53.5010601@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AE80@DKFZEX01.ad.dkfz-heidelberg.de> <5602BDC3.1090000@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AF76@DKFZEX01.ad.dkfz-heidelberg.de> <560406F1.6040901@kitware.com> Message-ID: <57EE86D11538B44096C712532DBB6C5A0131C2B7AFAA@DKFZEX01.ad.dkfz-heidelberg.de> Great, thank you, Brad & David. Regarding the ExternalProjectShellPathGenex test: I wrongly assumed that the WIN32 variable wouldn't be set when using MSYS and the like. Would it make sense to keep the test when changing the WIN32 check to MSVC? Good to know that pushd is working for quoted paths. As I didn't use paths with spaces, the argument wasn't quoted and the test worked like expected for me (succeeded with the SHELL_PATH genex and failed when I removed the SHELL_PATH genex). We could ensure that there isn't any space character in the argument by using a top-level path like C:/. Not hard coded but derived from a variable like CMAKE_SOURCE_DIR. Or, of course, there is a standard Windows command out there that cannot handle slashed even if they are quoted (any idea?). I chose pushd, as that was the command that started it all (used indirectly by the Boost build scripts). Regarding the nice bracket tweak: Maybe the minimum required version in Tests/GeneratorExpression/CMakeLists.txt should be updated to 3.0.0 then? Stefan -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Donnerstag, 24. September 2015 16:22 To: Kislinskiy, Stefan Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] generator expression for path slash conversion On 09/24/2015 09:05 AM, Kislinskiy, Stefan wrote: > I factored out the code from > cmOutputConverter::ConvertToOutputFormat() > into another helper method called > ConvertDirectorySeparatorsForShell(), > changed the SHELL_PATH genex to accept only absolute paths, and > changed its documentation accordingly. I also added a BadSHELL_PATH > test to the RunCMake/GeneratorExpression tests, that use the > SHELL_PATH genex with an empty parameter as well as a relative path. I > also fixed the TEST/CTEST typo you discovered yesterday. Thanks. I started with a change to simplify the test infrastructure slightly: Tests: Simplify GeneratorExpression check implementation http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7de868c4 Then I applied your changes with minor tweaks and merged to 'next' for testing: Genex: Add a SHELL_PATH expression http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8adf6ab5 I left out the ExternalProjectShellPathGenex test because it fails on the Ninja, MSYS Makefiles, and MinGW Makefiles generators on Windows. The 'pushd' and 'popd' commands do not work there due to the way the build tool runs the command in a shell. It passed for me only in a VS IDE generator. See also David Cole's sibling response about this test. -Brad From JamesJ at motionview3d.com Thu Sep 24 11:12:03 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Thu, 24 Sep 2015 15:12:03 -0000 Subject: [cmake-developers] generator expression for path slash conversion In-Reply-To: <57EE86D11538B44096C712532DBB6C5A0131C2B7AFAA@DKFZEX01.ad.dkfz-heidelberg.de> References: <57EE86D11538B44096C712532DBB6C5A0131C2B7AA5E@DKFZEX01.ad.dkfz-heidelberg.de> <55FAC667.5000901@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AE4D@DKFZEX01.ad.dkfz-heidelberg.de> <5602AF53.5010601@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AE80@DKFZEX01.ad.dkfz-heidelberg.de> <5602BDC3.1090000@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AF76@DKFZEX01.ad.dkfz-heidelberg.de> <560406F1.6040901@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AFAA@DKFZEX01.ad.dkfz-heidelberg.de> Message-ID: <0c0501d0f6db$5edc21e0$1c9465a0$@motionview3d.com> > -----Original Message----- > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] > On Behalf Of Kislinskiy, Stefan > Sent: Thursday, September 24, 2015 15:09 > To: Brad King > Cc: cmake-developers at cmake.org > Subject: Re: [cmake-developers] generator expression for path slash > conversion > > Great, thank you, Brad & David. > > Regarding the ExternalProjectShellPathGenex test: I wrongly assumed that > the WIN32 variable wouldn't be set when using MSYS and the like. Would it > make sense to keep the test when changing the WIN32 check to MSVC? Just an FYI: MSVC can still be set; it's an indicator of the *compiler* in use, not the *generator*. For example, it could be set if using cl.exe with Ninja. Best regards, James Johnston From brad.king at kitware.com Thu Sep 24 16:34:52 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 24 Sep 2015 16:34:52 -0400 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: References: <55E714E1.10505@kitware.com> <55F0496A.1040205@kitware.com> <55F18811.8000400@kitware.com> <55F1D428.4030707@kitware.com> <55F1D516.802@kitware.com> <56001D8D.3070703@kitware.com> <56029D3D.80405@kitware.com> <5602B44E.5030309@kitware.com> Message-ID: <56045E6C.30904@kitware.com> On 09/23/2015 06:48 PM, Gilles Khouzam wrote: > This adds only the WINDOWS_TARGET_PLATFORM_VERSION property as it > currently only supports the desktop scenario and is extracted > from the rest of the Windows 10 Store support. Thanks. While reviewing this much simpler patch I realized that the WindowsTargetPlatformVersion is more like PlatformToolset than I previously thought. This led me to another design, perhaps closer to one of your earlier patches, in which the VS 2015+ generators select the WindowsTargetPlatformVersion up front based either on CMAKE_WINDOWS_TARGET_PLATFORM_VERSION or on a computed default. Either way we should set CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION to report the selection to CMakeDetermineCompilerId for use in "CompilerId/VS-10.vcxproj.in". For now I decided to leave out support for per-target WINDOWS_TARGET_PLATFORM_VERSION properties. While testing these changes I found a bug that I've now fixed: cmCoreTryCompile: Fix internal argument vector construction http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=710bde43 Please try out the attached patches based on that version. Then provide fixup patches based on the comments below if needed. > If CMAKE_SYSTEM_VERSION is set to 10.0 then After your change to add a third component to CMAKE_HOST_SYSTEM_VERSION the value of CMAKE_SYSTEM_VERSION on a Windows 10 host may have a third component. Therefore we should check that the version starts with "10.0" rather than is exactly this version. Actually perhaps we should use cmSystemTools::VersionCompare to do actual integer version component checks. > the latest Windows 10 SDK but not more recent than the current > build of Windows. Rather than using VerifyVersionInfo for this, shouldn't the check simply compare the SDK version to the targeted CMAKE_SYSTEM_VERSION? If we are cross-compiling or otherwise specifying a specific target version of Windows then we do not want the SDK to exceed that regardless of what the host is running. Also, the sorting logic in GetWindows10SDKVersion appears to use lexicographic string ordering rather than a component-wise integer comparison. This will not always produce the correct result. This is another candidate for using cmSystemTools::VersionCompare. > There is one thing that I've changed that I want to make sure is > the right thing. As it stands, CMAKE_SYSTEM_VERSION is only valid > when cross-compiling, I've changed the CMakeDetermineSystem.cmake > file to not use the HOST_SYSTEM_VERSION when CMAKE_SYSTEM_VERSION > is set. Otherwise, we can only use this feature through > CMAKE_SYSTEM_VERSION on cross-compiling scenarios. That makes sense. I've split that out into its own commit and explained the motivation in the commit message. See attached patch. > I'm not sure what the best way to test this feature, it can be > added to any desktop project on Windows 10 and it should work > properly. I've tried it with CMake itself and it's working fine > and building against the Win10 SDK. We could have the test suite detect when it is building on a Windows 10 host and then add a test that sets CMAKE_WINDOWS_TARGET_PLATFORM_VERSION and verifies that the value ends up in a generated project file. We already have some tests that parse the generated .sln file to check for specific content. Also just simply by running on a Win 10 host then the entire test suite should build with CMAKE_SYSTEM_VERSION set automatically high enough to enable default SDK selection. Please look at setting up nightly testing submissions to the dashboard from such a host once the changes are integrated. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-CMAKE_SYSTEM_VERSION-to-be-set-without-CMAKE_S.patch Type: text/x-diff Size: 1323 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-VS-Add-hook-to-initialize-Windows-platform-settings.patch Type: text/x-diff Size: 3270 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-VS-Add-support-for-selecting-the-Windows-10-SDK.patch Type: text/x-diff Size: 13967 bytes Desc: not available URL: From Robert.Goulet at autodesk.com Thu Sep 24 17:21:43 2015 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Thu, 24 Sep 2015 21:21:43 +0000 Subject: [cmake-developers] Generator expressions for install destination In-Reply-To: <560406EA.2030501@kitware.com> References: <7120d35e1e8742839ae6fe826ecf4194@CO1PR79MB027.MGDADSK.autodesk.com> <55F19C7E.50704@kitware.com> <5600445B.8010400@kitware.com> <4dbdb7d434ec488daf5b3cba8fc5fef3@BN1PR79MB007.MGDADSK.autodesk.com> <560189FD.5030106@kitware.com> <19a621155766478db4203cc519bf62d6@BN1PR79MB007.MGDADSK.autodesk.com> <8aba767832a14419b4cbdf810b88b116@BN1PR79MB007.MGDADSK.autodesk.com> <99e0293109fc4ee8b5dff7a745e39d02@BN1PR79MB007.MGDADSK.autodesk.com> <5602B4F0.4000101@kitware.com> <39598d62613f44dba05a4e825c6fd3a3@BN1PR79MB007.MGDADSK.autodesk.com> <5602F751.60900@kitware.com> <5602FF70.9030808@kitware.com> , <560406EA.2030501@kitware.com> Message-ID: <83ABDD95-AF1B-44B2-9F55-8CEF5D3CED8A@autodesk.com> Thanks Brad! Sent from mobile, please excuse typos. > On Sep 24, 2015, at 10:24 AM, Brad King wrote: > >> On 09/23/2015 05:18 PM, Robert Goulet wrote: >> Here is the patch to support genex for install(DIRECTORY) command >> DESTINATION option. > > Thanks. Applied with minor tweaks: > > install: Allow generator expressions in DIRECTORY DESTINATION > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd189cc2 > > -Brad > From michael.scott250 at gmail.com Thu Sep 24 17:45:53 2015 From: michael.scott250 at gmail.com (Michael Scott) Date: Thu, 24 Sep 2015 22:45:53 +0100 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <560407CE.8070703@kitware.com> References: <560407CE.8070703@kitware.com> Message-ID: <56046F11.2050501@gmail.com> I've created a fix for the issue of -Wno-dev and -Wno-deprecated options not being honoured, and extended the tests to cover this additional scenario. However I'm having an issue with determining if variables are set in cmake.cxx. The initial fix checked for the variables using the "GetCacheEntryValue" method in cmState, but I found that this didn't work when the variable (say CMAKE_WARN_DEPRECATED) was set in a .cmake file, as is the case for the "RunCMake/message/warnmessage.cmake". I toyed around with trying to get a hold of a cmMakefile instance and check the state of the variable via that, by getting the first object of the global generator makefiles, but this didn't always seem to work. Would you be able to advise on what the correct way is to get the current value of a variable, in the cmake class? I feel like I'm missing something simple here, as I'm still not too familiar with the code. Cheers, Michael From marc.chevrier at sap.com Fri Sep 25 03:58:50 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Fri, 25 Sep 2015 07:58:50 +0000 Subject: [cmake-developers] [CMake][BUG] C++11 support broken for SolarisStudio 12.4 Message-ID: <333A65FC-B334-4266-83CD-E455823FC8CD@sap.com> Hi, Currently, it is not possible to use C++11 mode on Solaris with SolarisStudio 12.4 (test done on Solaris 11.2 sparc). If I try a simple executable (see attached file), compilation is OK (option ?std=c++11 is correctly passed to compiler) but link failed because, with SolarisStudio compiler, option ?std=c++11 is also required at link time and is currently missed. And unfortunately, it seems there is no equivalent to compile configuration variable CMAKE_CXX11_STANDARD_COMPILE_OPTION for the linker so no so easy to fix this problem? Here is the log (see red lines): /opt/solarisstudio12.4/bin/CC -std=c++11 -o CMakeFiles/Test.dir/test.cpp.o -c /usr/u/i051466/tests/cmake/build/test.cpp [100%] Linking CXX executable Test /usr/u/i051466/INSTALL.122/bin/cmake -E cmake_link_script CMakeFiles/Test.dir/link.txt --verbose=1 /opt/solarisstudio12.4/bin/CC CMakeFiles/Test.dir/test.cpp.o -o Test Undefined first referenced symbol in file std::ctype::_M_widen_init()const CMakeFiles/Test.dir/test.cpp.o std::ostream::put(char) CMakeFiles/Test.dir/test.cpp.o std::__throw_bad_cast() CMakeFiles/Test.dir/test.cpp.o __SUNW_ABIG3_cpp_personality CMakeFiles/Test.dir/test.cpp.o __cxxabiv1::register_exit_code(void (*)(void)extern"C") CMakeFiles/Test.dir/test.cpp.o std::ostream::flush() CMakeFiles/Test.dir/test.cpp.o std::cout CMakeFiles/Test.dir/test.cpp.o [Hint: static member std::cout must be defined in the program] std::ios::clear(std::_Ios_Iostate) CMakeFiles/Test.dir/test.cpp.o std::ios_base::Init::~Init() CMakeFiles/Test.dir/test.cpp.o std::ios_base::Init::Init() CMakeFiles/Test.dir/test.cpp.o std::ostream & std::__ostream_insert >(std::ostream &,const char*,int) CMakeFiles/Test.dir/test.cpp.o ld: fatal: symbol referencing errors FYI: * If I add option ?std=c++11 in the file ?/Test.dir/link.txt, link is successful * I built CMake using version 12.2 of SolarisStudio because if I use SolarisStudio 12.4, cmake tool is unsuable (I will sent another mail describing this problem). Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CMakeLists.txt URL: From marc.chevrier at sap.com Fri Sep 25 04:02:08 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Fri, 25 Sep 2015 08:02:08 +0000 Subject: [cmake-developers] [CMake][BUG] Unable to build CMake with SolarisStudio 12.4 Message-ID: Hi, Attached is a patch fixing compilation error which prevent building CMake with SolarisStudio 12.4. Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-SolarisStudio-12.4-cmake-compilation-fix.patch Type: application/octet-stream Size: 1093 bytes Desc: 0001-SolarisStudio-12.4-cmake-compilation-fix.patch URL: From marc.chevrier at sap.com Fri Sep 25 04:18:50 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Fri, 25 Sep 2015 08:18:50 +0000 Subject: [cmake-developers] [CMake][BUG] CMake built with SolarisStudio 12.4 is unusable Message-ID: <7007BF13-930C-447C-91E5-05F8ACD83105@sap.com> Hi, When CMake is built with SolarisStudio 12.4, cmake tool is unusable. Even the most simple test failed at generation time! This simple CMakeLists.txt cmake_minimum_required (VERSION 3.3.2) project (Test LANGUAGES CXX) Generates the following error: -- The CXX compiler identification is SunPro 5.13.0 -- Check for working CXX compiler: /opt/solarisstudio12.4/bin/CC CMake Error: CMake can not determine linker language for target: cmTC_d9073 CMake Error: Cannot determine link language for target "cmTC_d9073". CMake Error: Internal CMake error, TryCompile generation of cmake failed -- Check for working CXX compiler: /opt/solarisstudio12.4/bin/CC -- broken CMake Error at /usr/u/i051466/INSTALL/share/cmake-3.3/Modules/CMakeTestCXXCompiler.cmake:54 (message): The C++ compiler "/opt/solarisstudio12.4/bin/CC" is not able to compile a simple test program. It fails with the following output: CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:4 (project) -- Configuring incomplete, errors occurred! See also "/usr/u/i051466/tests/cmake/build/CMakeFiles/CMakeOutput.log". See also "/usr/u/i051466/tests/cmake/build/CMakeFiles/CMakeError.log". Unfortunately, there is absolutely nothing in the CMakeError.log file! I have no real idea what is the problem but here are some elements: * Same CMake sources (3.3.2) built with SolarisStudio !2.2 (C++ 5.11) produce a perfectly usable cmake * When SolarisStudio 12.4 is used (C++ 5.13), I notice that cmake bootstrap tool select the most advanced mode of the compiler (I.e. c++11). * May be the problem is linked to the fact that, currently, C++11 mode support is broken for SolarisStudio 12.4 (see a previous mail sent by me on this subject) because if CMake rely on this mode internally for its tests, for sure all will failed. Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From domen.vrankar at gmail.com Fri Sep 25 04:34:02 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Fri, 25 Sep 2015 10:34:02 +0200 Subject: [cmake-developers] [CPack][BUG] Fail to package with CPACK_INSTALLED_DIRECTORIES In-Reply-To: References: <35211127-F170-4181-AA16-59E46FD0D3DE@sap.com> <54E7B154-AFE7-4B8C-81C1-335525D0E73C@sap.com> Message-ID: 2015-09-24 9:06 GMT+02:00 Domen Vrankar : > 2015-09-23 17:00 GMT+02:00 CHEVRIER, Marc : >> Any comments about this problem? There was a bug in file creation time handling. Fix is in cmake git repository on next branch: http://cmake.org/gitweb?p=cmake.git;a=commit;h=39347d3 Could you check if it works for you? Thanks, Domen From Mike.Pagel at bmw.de Fri Sep 25 07:45:09 2015 From: Mike.Pagel at bmw.de (Mike.Pagel at bmw.de) Date: Fri, 25 Sep 2015 11:45:09 +0000 Subject: [cmake-developers] Timestamp of VS-generator rule files In-Reply-To: <55FACC00.9050602@kitware.com> References: <55FD441CAE5A314D8DD773CF40E1048B14E907BB@smucm57b> <55FAC3CF.2040503@kitware.com> <55FD441CAE5A314D8DD773CF40E1048B14E90A2D@smucm57b> <55FACC00.9050602@kitware.com> Message-ID: <55FD441CAE5A314D8DD773CF40E1048B14E928E3@smucm57b> I have a local version working, but want to double-check how to best go about this. As a reminder, I am trying to fix the .rule file handling of CMake's VisualStudio generator, which violates CMakes semantics "custom_commands without dependencies are built only if the outputs don't exist yet". Currently, the rule files have possibly newer timestamps than the output files (depending on when the project was CMake-configured), which would rebuild them. Things I want to run by you: I wrote a small function OutdateFileTime(const std::string& filename), which does what it sounds like. It is called by the VS generator right after rule file creation with Touch. I wasn't sure whether this function, which uses Win32 API should go into the generator code or SystemTools. Since I did not find any direct Win32 API use in the generator, I put it right next to SystemTools::Touch. OK? Am I required to do a non-Windows implementation of this function as well? It is (for now) never needed elsewhere than the VS generator, i.e. Windows. This would actually be an argument to put it into that class directly... If I do the non-Windows implementation, it'll be difficult for me to test. Also, this is dead code, since no Unix-like system would (for now) call it. Dead code will become incorrect... Am I supposed to add a test case for the new function to cmsysTestsCxx.cxx? Sorry for the heap of questions, point me to any docs I may have overlooked! Mike -----Urspr?ngliche Nachricht----- Von: cmake-developers [mailto:cmake-developers-bounces at cmake.org] Im Auftrag von Brad King Gesendet: Donnerstag, 17. September 2015 16:20 An: cmake-developers at cmake.org Betreff: Re: [cmake-developers] Timestamp of VS-generator rule files On 09/17/2015 10:06 AM, Mike.Pagel at bmw.de wrote: > would this mailing list be the right place to ask? Yes, and thanks for offering to work on the patch. You can post it here when finished, as described in CONTRIBUTING.rst. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers From marc.chevrier at sap.com Fri Sep 25 08:17:49 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Fri, 25 Sep 2015 12:17:49 +0000 Subject: [cmake-developers] [CPack][BUG] Fail to package with CPACK_INSTALLED_DIRECTORIES In-Reply-To: References: <35211127-F170-4181-AA16-59E46FD0D3DE@sap.com> <54E7B154-AFE7-4B8C-81C1-335525D0E73C@sap.com> Message-ID: <1C86C9FD-1464-4DBE-ACEC-DE1E05244503@sap.com> Hi Domen, Good news! With your patch, packaging on Windows is now working as expected. Thank you. Marc On 25/09/15 10:34, "Domen Vrankar" wrote: >2015-09-24 9:06 GMT+02:00 Domen Vrankar : >> 2015-09-23 17:00 GMT+02:00 CHEVRIER, Marc : >>> Any comments about this problem? > >There was a bug in file creation time handling. Fix is in cmake git >repository on next branch: >http://cmake.org/gitweb?p=cmake.git;a=commit;h=39347d3 > >Could you check if it works for you? > >Thanks, >Domen From brad.king at kitware.com Fri Sep 25 08:33:59 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 25 Sep 2015 08:33:59 -0400 Subject: [cmake-developers] Timestamp of VS-generator rule files In-Reply-To: <55FD441CAE5A314D8DD773CF40E1048B14E928E3@smucm57b> References: <55FD441CAE5A314D8DD773CF40E1048B14E907BB@smucm57b> <55FAC3CF.2040503@kitware.com> <55FD441CAE5A314D8DD773CF40E1048B14E90A2D@smucm57b> <55FACC00.9050602@kitware.com> <55FD441CAE5A314D8DD773CF40E1048B14E928E3@smucm57b> Message-ID: <56053F37.7020804@kitware.com> On 09/25/2015 07:45 AM, Mike.Pagel at bmw.de wrote: > I wrote a small function OutdateFileTime(const std::string& filename) > which does what it sounds like. It is called by the VS generator right > after rule file creation with Touch. I wasn't sure whether this function, > which uses Win32 API should go into the generator code or SystemTools. Until the functionality is needed elsewhere I see no reason not to just put it right in the generator implementation. If a more general purpose for it is found later it can be refactored over to SystemTools and made to work on more platforms. No need for that yet though. Thanks, -Brad From brad.king at kitware.com Fri Sep 25 08:41:23 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 25 Sep 2015 08:41:23 -0400 Subject: [cmake-developers] [CMake][BUG] Unable to build CMake with SolarisStudio 12.4 In-Reply-To: References: Message-ID: <560540F3.9040305@kitware.com> On 09/25/2015 04:02 AM, CHEVRIER, Marc wrote: > Attached is a patch fixing compilation error which prevent > building CMake with SolarisStudio 12.4. Thanks, applied: jsoncpp: Add missing cast to convert from char to UInt http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7fe4413 -Brad From brad.king at kitware.com Fri Sep 25 08:45:07 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 25 Sep 2015 08:45:07 -0400 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <56046F11.2050501@gmail.com> References: <560407CE.8070703@kitware.com> <56046F11.2050501@gmail.com> Message-ID: <560541D3.3090609@kitware.com> On 09/24/2015 05:45 PM, Michael Scott wrote: > I've created a fix for the issue of -Wno-dev and -Wno-deprecated options > not being honoured, and extended the tests to cover this additional > scenario. Thanks for working on it. > However I'm having an issue with determining if variables are set in > cmake.cxx. The initial fix checked for the variables using the > "GetCacheEntryValue" method in cmState, but I found that this didn't > work when the variable (say CMAKE_WARN_DEPRECATED) was set in a .cmake > file, as is the case for the "RunCMake/message/warnmessage.cmake". The cmake::Configure check for that runs before the scripts run so it is not possible to get script-provided values there. Do you have a check in a new context that occurs later? If so please provide the patch in progress and point out the problem. Thanks, -Brad From marc.chevrier at sap.com Fri Sep 25 09:20:33 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Fri, 25 Sep 2015 13:20:33 +0000 Subject: [cmake-developers] [CMake][BUG] Ensure C based tests do not used C++ syntax Message-ID: <1FB2CE4D-DE6A-48E0-963F-62C9F65D0FC9@sap.com> Hi, I encountered some problems validating a CMake build on AIX using IBM xlc/xlC compilers. The problem comes from the fact that, by default, C compiler does not recognized C++-Style comments. So, attached is a patch ensuring that sources compiling with a C compiler have C-Style comments only. Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-C-Style-comments-in-C-sources-and-headers.patch Type: application/octet-stream Size: 6585 bytes Desc: 0001-Use-C-Style-comments-in-C-sources-and-headers.patch URL: From brad.king at kitware.com Fri Sep 25 09:38:21 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 25 Sep 2015 09:38:21 -0400 Subject: [cmake-developers] generator expression for path slash conversion In-Reply-To: <57EE86D11538B44096C712532DBB6C5A0131C2B7AFAA@DKFZEX01.ad.dkfz-heidelberg.de> References: <57EE86D11538B44096C712532DBB6C5A0131C2B7AA5E@DKFZEX01.ad.dkfz-heidelberg.de> <55FAC667.5000901@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AE4D@DKFZEX01.ad.dkfz-heidelberg.de> <5602AF53.5010601@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AE80@DKFZEX01.ad.dkfz-heidelberg.de> <5602BDC3.1090000@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AF76@DKFZEX01.ad.dkfz-heidelberg.de> <560406F1.6040901@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AFAA@DKFZEX01.ad.dkfz-heidelberg.de> Message-ID: <56054E4D.9010001@kitware.com> On 09/24/2015 11:08 AM, Kislinskiy, Stefan wrote: > Regarding the nice bracket tweak: Maybe the minimum required > version in Tests/GeneratorExpression/CMakeLists.txt should be > updated to 3.0.0 then? The test also covers policy CMP0044 behavior and so cannot require a version new enough to set that policy. It doesn't really matter because we never run the test suite except with the current version of CMake anyway. After nightly testing of the main change I added this fixup: fixup! Genex: Add a SHELL_PATH expression http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d1912e51 which I'll squash in to the final change before merging to 'master'. The problem is that on Windows we support the "Unix Makefiles" generator that uses forward slashes but not MSYS-style drive letter conversion. -Brad From brad.king at kitware.com Fri Sep 25 09:40:11 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 25 Sep 2015 09:40:11 -0400 Subject: [cmake-developers] generator expression for path slash conversion In-Reply-To: <57EE86D11538B44096C712532DBB6C5A0131C2B7AFAA@DKFZEX01.ad.dkfz-heidelberg.de> References: <57EE86D11538B44096C712532DBB6C5A0131C2B7AA5E@DKFZEX01.ad.dkfz-heidelberg.de> <55FAC667.5000901@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AE4D@DKFZEX01.ad.dkfz-heidelberg.de> <5602AF53.5010601@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AE80@DKFZEX01.ad.dkfz-heidelberg.de> <5602BDC3.1090000@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AF76@DKFZEX01.ad.dkfz-heidelberg.de> <560406F1.6040901@kitware.com> <57EE86D11538B44096C712532DBB6C5A0131C2B7AFAA@DKFZEX01.ad.dkfz-heidelberg.de> Message-ID: <56054EBB.1000203@kitware.com> On 09/24/2015 11:08 AM, Kislinskiy, Stefan wrote: > Regarding the ExternalProjectShellPathGenex test [snip] > there is a standard Windows command out there that cannot > handle slashed even if they are quoted (any idea?) Rather than trying to find a command for this you could just have the test build a small binary that actually checks the slashes of its arguments. -Brad From brad.king at kitware.com Fri Sep 25 09:42:05 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 25 Sep 2015 09:42:05 -0400 Subject: [cmake-developers] [CMake][BUG] Ensure C based tests do not used C++ syntax In-Reply-To: <1FB2CE4D-DE6A-48E0-963F-62C9F65D0FC9@sap.com> References: <1FB2CE4D-DE6A-48E0-963F-62C9F65D0FC9@sap.com> Message-ID: <56054F2D.3090008@kitware.com> On 09/25/2015 09:20 AM, CHEVRIER, Marc wrote: > patch ensuring that sources compiling with a C compiler have C-Style comments Thanks, applied: Tests: Use C-Style comments in C sources and headers http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4eb77a1c -Brad From marc.chevrier at sap.com Fri Sep 25 10:15:03 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Fri, 25 Sep 2015 14:15:03 +0000 Subject: [cmake-developers] [CMake][BUG] ProcessorCount is broken on current SunOS systems Message-ID: Hi, Attached is a patch to ensure that ProcessorCount returns correct information on recent SunOS systems (tested on Sunos 5.11 (i.e. Solaris 11.2)). Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Update-ProcessorCount-module-for-recent-SunOS.patch Type: application/octet-stream Size: 2288 bytes Desc: 0001-Update-ProcessorCount-module-for-recent-SunOS.patch URL: From brad.king at kitware.com Fri Sep 25 10:20:36 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 25 Sep 2015 10:20:36 -0400 Subject: [cmake-developers] [CMake][BUG] ProcessorCount is broken on current SunOS systems In-Reply-To: References: Message-ID: <56055834.5020802@kitware.com> On 09/25/2015 10:15 AM, CHEVRIER, Marc wrote: > Attached is a patch to ensure that ProcessorCount returns correct > information on recent SunOS systems Thanks, applied: ProcessorCount: Implement with psrinfo tool on recent SunOS versions http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c0908053 -Brad From brad.king at kitware.com Fri Sep 25 11:24:21 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 25 Sep 2015 11:24:21 -0400 Subject: [cmake-developers] CXX_STANDARD and linking (was: C++11 support broken for SolarisStudio 12.4) In-Reply-To: <333A65FC-B334-4266-83CD-E455823FC8CD@sap.com> References: <333A65FC-B334-4266-83CD-E455823FC8CD@sap.com> Message-ID: <56056725.5050503@kitware.com> Steve, On 09/25/2015 03:58 AM, CHEVRIER, Marc wrote: > * If I add option -std=c++11 in the file .../Test.dir/link.txt, > link is successful Compiling with a -std= flag should link with such a flag too. Flags like this are why CMake has always passed CMAKE_CXX_FLAGS to the C++ compiler when using it to drive the linker. This does not appear to be the case anywhere right now when the flag is added via CXX_STANDARD. Marc, meanwhile you should be able to bootstrap CMake with bootstrap ... -- -DCMake_NO_C_STANDARD=1 -DCMake_NO_CXX_STANDARD to skip trying to use any -std= flags. -Brad From daniel.wirtz at simtech.uni-stuttgart.de Fri Sep 25 11:32:24 2015 From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz) Date: Fri, 25 Sep 2015 17:32:24 +0200 Subject: [cmake-developers] added get_git_revision and get_git_branch commands as follow-up to cmake@cmake.org Message-ID: <56056908.4030203@simtech.uni-stuttgart.de> Hello all, here's my proposal for the git convenience functions, see http://public.kitware.com/pipermail/cmake/2015-September/061516.html i've also created a pull request https://github.com/Kitware/CMake/pull/185 (before i read CONTRIBUTING.rst, sorry) additionally, can someone hint me as to how to build the html-help locally? i want to be able to check the generated help output .. some quick search did not get me any how-to's. cheers, Daniel Signed-off-by: Daniel Wirtz --- Modules/FindGit.cmake | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) diff --git a/Modules/FindGit.cmake b/Modules/FindGit.cmake index b4f7b4b..18f8f59 100644 --- a/Modules/FindGit.cmake +++ b/Modules/FindGit.cmake @@ -20,6 +20,24 @@ # if(GIT_FOUND) # message("git found: ${GIT_EXECUTABLE}") # endif() +# +# For convenience, the package also provides the following functions: +# +# :: +# +# git_get_revision(VARNAME [WORKING_DIRECTORY]) +# git_get_branch(VARNAME [WORKING_DIRECTORY]) +# +# Both functions return the current Git revision (full ID) and branch name, respectively. +# If the functions are invoked but Git was not found, the configure step stops with an error. +# The arguments are +# +# ``VARNAME`` +# Name of the variable to contain the result. +# +# ``WORKING_DIRECTORY`` +# The working directory at which to execute the git commands. +# If not specified, :variable:`CMAKE_CURRENT_SOURCE_DIR` is assumed. #============================================================================= # Copyright 2010 Kitware, Inc. @@ -77,3 +95,43 @@ include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) find_package_handle_standard_args(Git REQUIRED_VARS GIT_EXECUTABLE VERSION_VAR GIT_VERSION_STRING) + +# Convenience Git repo & branch information functions +# Added by Daniel Wirtz +function(git_get_revision VARNAME) + if (NOT GIT_FOUND) + message(FATAL_ERROR "Cannot use git_get_revision: Git was not found.") + endif() + set(WD ${ARGV1}) + if("${WD}" STREQUAL "") + set(WD ${CMAKE_CURRENT_SOURCE_DIR}) + endif() + execute_process(COMMAND ${GIT_EXECUTABLE} rev-list --max-count=1 HEAD + OUTPUT_VARIABLE RES + ERROR_VARIABLE ERR + OUTPUT_STRIP_TRAILING_WHITESPACE + WORKING_DIRECTORY ${WD}) + set(${VARNAME} ${RES} PARENT_SCOPE) + if (ERR) + message(WARNING "Issuing Git command '${GIT_EXECUTABLE} rev-list --max-count=1 HEAD' failed: ${ERR}") + endif() +endfunction() + +function(git_get_branch VARNAME) + if (NOT GIT_FOUND) + message(FATAL_ERROR "Cannot use git_get_branch: Git was not found.") + endif() + set(WD ${ARGV1}) + if("${WD}" STREQUAL "") + set(WD ${CMAKE_CURRENT_SOURCE_DIR}) + endif() + execute_process(COMMAND ${GIT_EXECUTABLE} describe --all + OUTPUT_VARIABLE RES + ERROR_VARIABLE ERR + OUTPUT_STRIP_TRAILING_WHITESPACE + WORKING_DIRECTORY ${WD}) + if (ERR) + message(WARNING "Issuing Git command '${GIT_EXECUTABLE} describe --all' failed: ${ERR}") + endif() + set(${VARNAME} ${RES} PARENT_SCOPE) +endfunction() \ No newline at end of file -- 1.9.1 From brad.king at kitware.com Fri Sep 25 11:46:55 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 25 Sep 2015 11:46:55 -0400 Subject: [cmake-developers] added get_git_revision and get_git_branch commands as follow-up to cmake@cmake.org In-Reply-To: <56056908.4030203@simtech.uni-stuttgart.de> References: <56056908.4030203@simtech.uni-stuttgart.de> Message-ID: <56056C6F.1030903@kitware.com> On 09/25/2015 11:32 AM, Daniel Wirtz wrote: > here's my proposal for the git convenience functions, see > http://public.kitware.com/pipermail/cmake/2015-September/061516.html Thanks for working on this. > additionally, can someone hint me as to how to build the html-help > locally? i want to be able to check the generated help output .. some > quick search did not get me any how-to's. Configure CMake with -DSPHINX_HTML=ON. Be sure you have python-sphinx installed. Point SPHINX_EXECUTABLE at the `sphinx-build` command if needed. > +# git_get_revision(VARNAME [WORKING_DIRECTORY]) > +# git_get_branch(VARNAME [WORKING_DIRECTORY]) Please see the cmake-developer(7) manual section on documenting commands: http://cmake.org/cmake/help/v3.3/manual/cmake-developer.7.html#cmake-domain Run git grep '\.\. command::' -- Modules to see some examples. > +# Added by Daniel Wirtz This information is recorded in the commit history and so is not needed here. You can add a line to the copyright block if you want. Just be sure it passes the ModuleNotices test. > +function(git_get_revision VARNAME) [snip] > + execute_process(COMMAND ${GIT_EXECUTABLE} rev-list --max-count=1 HEAD Perhaps: git rev-parse --verify -q HEAD ? > +function(git_get_branch VARNAME) [snip] > + execute_process(COMMAND ${GIT_EXECUTABLE} describe --all Perhaps: git symbolic-ref -q HEAD ? Thanks, -Brad From ben.boeckel at kitware.com Fri Sep 25 12:14:30 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 25 Sep 2015 12:14:30 -0400 Subject: [cmake-developers] added get_git_revision and get_git_branch commands as follow-up to cmake@cmake.org In-Reply-To: <56056908.4030203@simtech.uni-stuttgart.de> References: <56056908.4030203@simtech.uni-stuttgart.de> Message-ID: <20150925161430.GB5060@megas.khq.kitware.com> On Fri, Sep 25, 2015 at 17:32:24 +0200, Daniel Wirtz wrote: > Hello all, > here's my proposal for the git convenience functions, see > http://public.kitware.com/pipermail/cmake/2015-September/061516.html > > i've also created a pull request > https://github.com/Kitware/CMake/pull/185 (before i read > CONTRIBUTING.rst, sorry) Thanks! One thing that I think should be done is to allow for a format to be specified. Some will want the long hash, short hash, describe output, commit date, etc. However, I think there is a larger issue: this is setting people up for failure if they want the hash of the source tree in their build. These commands really should be run at *build* time because cmake will not necessarily rerun if the git commit changes which makes it easy for the git data to be silently wrong. See this[1] code for what should be done for full "put the git hash in the build" support including tarballs without a .git directory. The sprokit_configure_file basically adds a command which runs a script to configure the file at build time (the list of variables are passed explicitly). > additionally, can someone hint me as to how to build the html-help > locally? i want to be able to check the generated help output .. some > quick search did not get me any how-to's. You need to have sphinx enabled and then set SPHINX_HTML=ON. --Ben [1]https://github.com/Kitware/sprokit/blob/master/src/sprokit/CMakeLists.txt From Gilles.Khouzam at microsoft.com Fri Sep 25 13:00:02 2015 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Fri, 25 Sep 2015 17:00:02 +0000 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: <56045E6C.30904@kitware.com> References: <55E714E1.10505@kitware.com> <55F0496A.1040205@kitware.com> <55F18811.8000400@kitware.com> <55F1D428.4030707@kitware.com> <55F1D516.802@kitware.com> <56001D8D.3070703@kitware.com> <56029D3D.80405@kitware.com> <5602B44E.5030309@kitware.com> <56045E6C.30904@kitware.com> Message-ID: Thanks for the refactor Brad, The patches make sense. >After your change to add a third component to CMAKE_HOST_SYSTEM_VERSION the value of CMAKE_SYSTEM_VERSION on a Windows 10 host may have a third component. >Therefore we should check that the version starts with "10.0" rather than is exactly this version. Actually perhaps we should use >cmSystemTools::VersionCompare to do actual integer version component checks. This was done deliberately to only force a value for CMAKE_WINDOWS_TARGET_PLATFORM_VERSION when the CMAKE_SYSTEM_VERSION is specified as 10.0. Otherwise any Windows 10 machine will use the Windows 10 SDK and not the Windows 8.1 SDK and I'm not sure that there is a way then target the Windows 8.1 SDK. -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Thursday, September 24, 2015 13:35 To: Gilles Khouzam Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/23/2015 06:48 PM, Gilles Khouzam wrote: > This adds only the WINDOWS_TARGET_PLATFORM_VERSION property as it > currently only supports the desktop scenario and is extracted from the > rest of the Windows 10 Store support. Thanks. While reviewing this much simpler patch I realized that the WindowsTargetPlatformVersion is more like PlatformToolset than I previously thought. This led me to another design, perhaps closer to one of your earlier patches, in which the VS 2015+ generators select the WindowsTargetPlatformVersion up front based either on CMAKE_WINDOWS_TARGET_PLATFORM_VERSION or on a computed default. Either way we should set CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION to report the selection to CMakeDetermineCompilerId for use in "CompilerId/VS-10.vcxproj.in". For now I decided to leave out support for per-target WINDOWS_TARGET_PLATFORM_VERSION properties. While testing these changes I found a bug that I've now fixed: cmCoreTryCompile: Fix internal argument vector construction http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=710bde43 Please try out the attached patches based on that version. Then provide fixup patches based on the comments below if needed. > If CMAKE_SYSTEM_VERSION is set to 10.0 then After your change to add a third component to CMAKE_HOST_SYSTEM_VERSION the value of CMAKE_SYSTEM_VERSION on a Windows 10 host may have a third component. Therefore we should check that the version starts with "10.0" rather than is exactly this version. Actually perhaps we should use cmSystemTools::VersionCompare to do actual integer version component checks. > the latest Windows 10 SDK but not more recent than the current build > of Windows. Rather than using VerifyVersionInfo for this, shouldn't the check simply compare the SDK version to the targeted CMAKE_SYSTEM_VERSION? If we are cross-compiling or otherwise specifying a specific target version of Windows then we do not want the SDK to exceed that regardless of what the host is running. Also, the sorting logic in GetWindows10SDKVersion appears to use lexicographic string ordering rather than a component-wise integer comparison. This will not always produce the correct result. This is another candidate for using cmSystemTools::VersionCompare. > There is one thing that I've changed that I want to make sure is the > right thing. As it stands, CMAKE_SYSTEM_VERSION is only valid when > cross-compiling, I've changed the CMakeDetermineSystem.cmake file to > not use the HOST_SYSTEM_VERSION when CMAKE_SYSTEM_VERSION is set. > Otherwise, we can only use this feature through CMAKE_SYSTEM_VERSION > on cross-compiling scenarios. That makes sense. I've split that out into its own commit and explained the motivation in the commit message. See attached patch. > I'm not sure what the best way to test this feature, it can be added > to any desktop project on Windows 10 and it should work properly. I've > tried it with CMake itself and it's working fine and building against > the Win10 SDK. We could have the test suite detect when it is building on a Windows 10 host and then add a test that sets CMAKE_WINDOWS_TARGET_PLATFORM_VERSION and verifies that the value ends up in a generated project file. We already have some tests that parse the generated .sln file to check for specific content. Also just simply by running on a Win 10 host then the entire test suite should build with CMAKE_SYSTEM_VERSION set automatically high enough to enable default SDK selection. Please look at setting up nightly testing submissions to the dashboard from such a host once the changes are integrated. Thanks, -Brad From brad.king at kitware.com Fri Sep 25 14:52:48 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 25 Sep 2015 14:52:48 -0400 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: References: <55F0496A.1040205@kitware.com> <55F18811.8000400@kitware.com> <55F1D428.4030707@kitware.com> <55F1D516.802@kitware.com> <56001D8D.3070703@kitware.com> <56029D3D.80405@kitware.com> <5602B44E.5030309@kitware.com> <56045E6C.30904@kitware.com> Message-ID: <56059800.5050502@kitware.com> On 09/25/2015 01:00 PM, Gilles Khouzam wrote: > This was done deliberately to only force a value for > CMAKE_WINDOWS_TARGET_PLATFORM_VERSION With the approach in my patch that variable is never set by the generator. It chooses a WindowsTargetPlatformVersion value and reports it in CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION. The CMAKE_WINDOWS_TARGET_PLATFORM_VERSION variable is only for the user-defined selection. > when the CMAKE_SYSTEM_VERSION is specified as 10.0. > Otherwise any Windows 10 machine will use the Windows 10 SDK > and not the Windows 8.1 SDK Why is it wrong to target the host's version by default? This is commonly done on other platforms. If one is building only for the current host this makes sense. If one is building for deployment then extra care is needed anyway. > and I'm not sure that there is a way then target the Windows 8.1 SDK. If one wants to build on a Windows 10 host but target an older version of Windows, one can simply do -DCMAKE_SYSTEM_VERSION=6.3 for example. This is thanks to your patch that allows it to be set separately from CMAKE_SYSTEM_NAME. Actually, why do we need a separate setting like CMAKE_WINDOWS_TARGET_PLATFORM_VERSION to select this at all? Why not just take the highest available SDK that does not exceed CMAKE_SYSTEM_VERSION? CMAKE_SYSTEM_VERSION is meant exactly to specify the target OS version. You posted something about this here: https://cmake.org/Bug/view.php?id=15670#c39247 but I do not quite understand it. Thanks, -Brad From michael.scott250 at gmail.com Fri Sep 25 15:44:44 2015 From: michael.scott250 at gmail.com (Michael Scott) Date: Fri, 25 Sep 2015 20:44:44 +0100 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <560541D3.3090609@kitware.com> References: <560541D3.3090609@kitware.com> Message-ID: <5605A42C.8020209@gmail.com> Sorry I'm being a bit slow with this topic, it's release period at my office too :D so a busy time there as well. > The cmake::Configure check for that runs before the scripts run so > it is not possible to get script-provided values there. Do you have > a check in a new context that occurs later? If so please provide the > patch in progress and point out the problem. The checks I'm adding in are in the cmake::PrintMessagePreamble method, I've included an initial version of the patch. This looks correct and seems to behave correctly when either the user uses the -W options, or doesn't change anything relating to warnings or errors. But, when the user sets the variables being checked for, in the CMake file itself, the checks don't pick up the set variables. I'm guessing because its only checking against the cache, and the normal usage of the set command doesn't set the variable in the cache? This change causes the RunCMake.message and RunCMake.ObsoleteQtMacros tests for fail, as they do what is described just above. Cheers, Michael -------------- next part -------------- From 9096cd7f2a0ff42db88c4adb25a403e75e381756 Mon Sep 17 00:00:00 2001 From: Michael Scott Date: Tue, 22 Sep 2015 22:43:24 +0100 Subject: [PATCH] Fix suppressing dev and deprecated messages via -W Examine the dev and deprecated warning and error output variables when printing message preambles, so that messages output outside of the message command, via IssueMessage, are affected by the CMake '-W' options again after the recent changes related to the -W options. --- Source/cmake.cxx | 34 ++++++++++++++++++++++++++++++ Tests/RunCMake/CommandLine/Wdev-stderr.txt | 6 ++++++ Tests/RunCMake/CommandLine/Wdev.cmake | 5 +++++ Tests/RunCMake/CommandLine/Wno-dev.cmake | 5 +++++ 4 files changed, 50 insertions(+) diff --git a/Source/cmake.cxx b/Source/cmake.cxx index f069481..dec254f 100644 --- a/Source/cmake.cxx +++ b/Source/cmake.cxx @@ -2591,18 +2591,52 @@ bool cmake::PrintMessagePreamble(cmake::MessageType t, std::ostream& msg) else if(t == cmake::DEPRECATION_ERROR) { msg << "CMake Deprecation Error"; + + // if CMAKE_ERROR_DEPRECATED is on, show the message, otherwise suppress it + const char* errorDeprecated = this->State->GetCacheEntryValue( + "CMAKE_ERROR_DEPRECATED"); + if(cmSystemTools::IsOff(errorDeprecated)) + { + return false; + } } else if (t == cmake::DEPRECATION_WARNING) { msg << "CMake Deprecation Warning"; + + // if CMAKE_WARN_DEPRECATED is on, show the message, otherwise suppress it + const char* warnDeprecated = this->State->GetInitializedCacheValue( + "CMAKE_WARN_DEPRECATED"); + if(cmSystemTools::IsOff(warnDeprecated)) + { + return false; + } } else if (t == cmake::AUTHOR_WARNING) { msg << "CMake Warning (dev)"; + + // if CMAKE_SUPPRESS_DEVELOPER_WARNINGS is on, suppress the message, + // otherwise show it + const char* suppress = this->State->GetCacheEntryValue( + "CMAKE_SUPPRESS_DEVELOPER_WARNINGS"); + if(cmSystemTools::IsOn(suppress)) + { + return false; + } } else if (t == cmake::AUTHOR_ERROR) { msg << "CMake Error (dev)"; + + // if CMAKE_ERROR_DEVELOPER_WARNINGS is on, show the message, otherwise + // suppress it + const char* devErrors = this->State->GetCacheEntryValue( + "CMAKE_ERROR_DEVELOPER_WARNINGS"); + if(cmSystemTools::IsOff(devErrors)) + { + return false; + } } else { diff --git a/Tests/RunCMake/CommandLine/Wdev-stderr.txt b/Tests/RunCMake/CommandLine/Wdev-stderr.txt index f427303..92c1d23 100644 --- a/Tests/RunCMake/CommandLine/Wdev-stderr.txt +++ b/Tests/RunCMake/CommandLine/Wdev-stderr.txt @@ -2,4 +2,10 @@ Some Author Warning Call Stack \(most recent call first\): CMakeLists.txt:3 \(include\) +This warning is for project developers. Use -Wno-dev to suppress it. + +CMake Warning \(dev\) at Wdev.cmake:6 \(include\): + include\(\) given empty file name \(ignored\). +Call Stack \(most recent call first\): + CMakeLists.txt:3 \(include\) This warning is for project developers. Use -Wno-dev to suppress it.$ diff --git a/Tests/RunCMake/CommandLine/Wdev.cmake b/Tests/RunCMake/CommandLine/Wdev.cmake index 0242086..9d2439b 100644 --- a/Tests/RunCMake/CommandLine/Wdev.cmake +++ b/Tests/RunCMake/CommandLine/Wdev.cmake @@ -1 +1,6 @@ message(AUTHOR_WARNING "Some Author Warning") + +# with -Wdev this will also cause an AUTHOR_WARNING message, checks that +# messages issued outside of the message command, by other CMake commands, also +# are affected by -Wdev +include("") \ No newline at end of file diff --git a/Tests/RunCMake/CommandLine/Wno-dev.cmake b/Tests/RunCMake/CommandLine/Wno-dev.cmake index 0242086..05dcc1e 100644 --- a/Tests/RunCMake/CommandLine/Wno-dev.cmake +++ b/Tests/RunCMake/CommandLine/Wno-dev.cmake @@ -1 +1,6 @@ message(AUTHOR_WARNING "Some Author Warning") + +# without -Wno-dev this will also cause an AUTHOR_WARNING message, checks that +# messages issued outside of the message command, by other CMake commands, also +# are affected by -Wno-dev +include("") \ No newline at end of file -- 2.1.4 From brad.king at kitware.com Fri Sep 25 16:12:14 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 25 Sep 2015 16:12:14 -0400 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <5605A42C.8020209@gmail.com> References: <560541D3.3090609@kitware.com> <5605A42C.8020209@gmail.com> Message-ID: <5605AA9E.3070907@kitware.com> On 09/25/2015 03:44 PM, Michael Scott wrote: > it's release period at my office too so a busy time there as well. Okay, I really don't want to try to rush in a fix for this before the 3.4 deadline, especially when we're both busy with other things. The entire feature was developed under the misconception that -Wdev and -Wno-dev were only about the message() command. The tests only cover that. We've identified that there may be other IssueMessage calls that may not deal well with -Werror=dev. I'm going to proceed with my reversion of the entire feature for 3.4. We can pick this up during post-3.4 development when you have time. Then we can review the all related semantics together. -Brad From brad.king at kitware.com Fri Sep 25 16:25:07 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 25 Sep 2015 16:25:07 -0400 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <5605AA9E.3070907@kitware.com> References: <560541D3.3090609@kitware.com> <5605A42C.8020209@gmail.com> <5605AA9E.3070907@kitware.com> Message-ID: <5605ADA3.6010409@kitware.com> On 09/25/2015 04:12 PM, Brad King wrote: > I'm going to proceed with my reversion of the entire feature for 3.4. > We can pick this up during post-3.4 development when you have time. > Then we can review the all related semantics together. Reverted here: Revert topic 'cmake-W-options' http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=81739e92 Then I added your test case for the previously-regressed behavior: Tests: Add case for -Wdev and -Wno-dev with non-message() warnings http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bc3e1e4b Thanks, -Brad From michael.scott250 at gmail.com Fri Sep 25 16:49:48 2015 From: michael.scott250 at gmail.com (Michael Scott) Date: Fri, 25 Sep 2015 21:49:48 +0100 Subject: [cmake-developers] Add command line options for deprecation message control In-Reply-To: <5605ADA3.6010409@kitware.com> References: <5605ADA3.6010409@kitware.com> Message-ID: <5605B36C.4080707@gmail.com> > I'm going to proceed with my reversion of the entire feature for 3.4. > We can pick this up during post-3.4 development when you have time. > Then we can review the all related semantics together. Okay, that's fair enough, sorry it hasn't been possible to get it into the 3.4 release in time. Cheers, Michael From mantis at public.kitware.com Fri Sep 25 17:38:33 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 25 Sep 2015 17:38:33 -0400 Subject: [cmake-developers] [CMake 0015758]: FindGit does not work when git is installed through SourceTree Message-ID: <84ff6339a6291791e774d7a6edf8ebbd@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15758 ====================================================================== Reported By: Kevin Wojniak Assigned To: ====================================================================== Project: CMake Issue ID: 15758 Category: CMake Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-25 17:38 EDT Last Modified: 2015-09-25 17:38 EDT ====================================================================== Summary: FindGit does not work when git is installed through SourceTree Description: https://www.sourcetreeapp.com SourceTree on Windows can download and setup git. When this happens it places it (at least on my system) at: %USERPROFILE%/AppData/Local/Atlassian/SourceTree/git_local/bin/git.exe But FindGit does not find it in this location. Steps to Reproduce: 1. Make sure no git version is installed in Windows 2. Install SourceTree and when prompted install git 3. In CMake - include(FindGit) 4. GIT_FOUND will be false ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-25 17:38 Kevin Wojniak New Issue ====================================================================== From Gilles.Khouzam at microsoft.com Fri Sep 25 17:55:09 2015 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Fri, 25 Sep 2015 21:55:09 +0000 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: <56059800.5050502@kitware.com> References: <55F0496A.1040205@kitware.com> <55F18811.8000400@kitware.com> <55F1D428.4030707@kitware.com> <55F1D516.802@kitware.com> <56001D8D.3070703@kitware.com> <56029D3D.80405@kitware.com> <5602B44E.5030309@kitware.com> <56045E6C.30904@kitware.com> <56059800.5050502@kitware.com> Message-ID: You're right, by targeting another version (8.1 or 6.3), the tag would not be written. Leveraging CMAKE_SYSTEM_VERSION is an interesting idea. Let me mull it over a little bit more and see how I would apply to newer SDKs as they come out, as I would like to minimize the required changes to CMake to support things when they come out (I'm gathering some information on that). -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Friday, September 25, 2015 11:53 To: Gilles Khouzam Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/25/2015 01:00 PM, Gilles Khouzam wrote: > This was done deliberately to only force a value for > CMAKE_WINDOWS_TARGET_PLATFORM_VERSION With the approach in my patch that variable is never set by the generator. It chooses a WindowsTargetPlatformVersion value and reports it in CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION. The CMAKE_WINDOWS_TARGET_PLATFORM_VERSION variable is only for the user-defined selection. > when the CMAKE_SYSTEM_VERSION is specified as 10.0. > Otherwise any Windows 10 machine will use the Windows 10 SDK and not > the Windows 8.1 SDK Why is it wrong to target the host's version by default? This is commonly done on other platforms. If one is building only for the current host this makes sense. If one is building for deployment then extra care is needed anyway. > and I'm not sure that there is a way then target the Windows 8.1 SDK. If one wants to build on a Windows 10 host but target an older version of Windows, one can simply do -DCMAKE_SYSTEM_VERSION=6.3 for example. This is thanks to your patch that allows it to be set separately from CMAKE_SYSTEM_NAME. Actually, why do we need a separate setting like CMAKE_WINDOWS_TARGET_PLATFORM_VERSION to select this at all? Why not just take the highest available SDK that does not exceed CMAKE_SYSTEM_VERSION? CMAKE_SYSTEM_VERSION is meant exactly to specify the target OS version. You posted something about this here: https://cmake.org/Bug/view.php?id=15670#c39247 but I do not quite understand it. Thanks, -Brad From mantis at public.kitware.com Mon Sep 28 02:49:31 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 28 Sep 2015 02:49:31 -0400 Subject: [cmake-developers] [CMake 0015759]: Error running cmake Message-ID: <249ceebcc5b202006ecf7ace26b8b81e@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15759 ====================================================================== Reported By: Vishnu Makkapati Assigned To: ====================================================================== Project: CMake Issue ID: 15759 Category: CMake Reproducibility: always Severity: major Priority: urgent Status: new ====================================================================== Date Submitted: 2015-09-28 02:49 EDT Last Modified: 2015-09-28 02:49 EDT ====================================================================== Summary: Error running cmake Description: I get the following error when I run cmake. Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed! ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-28 02:49 Vishnu MakkapatiNew Issue ====================================================================== From marc.chevrier at sap.com Mon Sep 28 03:55:01 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Mon, 28 Sep 2015 07:55:01 +0000 Subject: [cmake-developers] CXX_STANDARD and linking (was: C++11 support broken for SolarisStudio 12.4) In-Reply-To: <56056725.5050503@kitware.com> References: <333A65FC-B334-4266-83CD-E455823FC8CD@sap.com> <56056725.5050503@kitware.com> Message-ID: <8772E487-A7D5-4C13-A4C9-1711380D7A20@sap.com> Hi, Bootstrapping CMake with the flags you specify and SOlarisStudio 12.4 enable to generate a usable Cmake but some tests are failing with error related to CXX standard. For example, test 32, CompileFeatures generates error: 32: CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. 32: Missing variable is: 32: CMAKE_CXX98_EXTENSION_COMPILE_OPTION In the meantime, I am using SolarisStudio 12.2 for CMake bootstrapping. Anyway, the main problem is the fact that, currently, C++ standard handling is not usable on Solaris. Do have any plan to fix this problem anytime soon? After this problem fixed, I hope CMake bootstrapping will be solved as well? Thank you for your help. Marc On 25/09/15 17:24, "Brad King" wrote: >Steve, > >On 09/25/2015 03:58 AM, CHEVRIER, Marc wrote: >> * If I add option -std=c++11 in the file .../Test.dir/link.txt, >> link is successful > >Compiling with a -std= flag should link with such a flag too. >Flags like this are why CMake has always passed CMAKE_CXX_FLAGS >to the C++ compiler when using it to drive the linker. This does >not appear to be the case anywhere right now when the flag is added >via CXX_STANDARD. > >Marc, meanwhile you should be able to bootstrap CMake with > > bootstrap ... -- -DCMake_NO_C_STANDARD=1 -DCMake_NO_CXX_STANDARD > >to skip trying to use any -std= flags. > >-Brad > From mantis at public.kitware.com Mon Sep 28 05:43:24 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 28 Sep 2015 05:43:24 -0400 Subject: [cmake-developers] [CMake 0015760]: Generating project files fails, if compiler path has spaces Message-ID: <82439aeaef6db5d4cd938acf63980aed@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=15760 ====================================================================== Reported By: leandros Assigned To: ====================================================================== Project: CMake Issue ID: 15760 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-28 05:43 EDT Last Modified: 2015-09-28 05:43 EDT ====================================================================== Summary: Generating project files fails, if compiler path has spaces Description: Generating Unix Makefiles fails, if the compiler path has a space. /usr/bin/clang and /usr/bin/clang++ are not symlinked. $ CC=/usr/bin/clang CXX=/usr/bin/clang++ cmake -G "Unix Makefiles" .. -- The C compiler identification is AppleClang 7.0.0.7000072 -- The CXX compiler identification is AppleClang 7.0.0.7000072 -- Check for working C compiler: /Applications/Xcode 7.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- Check for working C compiler: /Applications/Xcode 7.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- broken CMake Error at /usr/local/Cellar/cmake/3.3.2/share/cmake/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "/Applications/Xcode 7.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" is not able to compile a simple test program. It fails with the following output: Change Dir: /Users/arvidgerstmann/cocos2d-x-3.6/external/flatbuffers/build/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/make" "cmTC_d0237/fast" /Applications/Xcode 7.app/Contents/Developer/usr/bin/make -f CMakeFiles/cmTC_d0237.dir/build.make CMakeFiles/cmTC_d0237.dir/build make: /Applications/Xcode: No such file or directory make: *** [cmTC_d0237/fast] Error 1 CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMake Warning (dev) in CMakeLists.txt: No cmake_minimum_required command is present. A line of code such as cmake_minimum_required(VERSION 3.3) should be added at the top of the file. The version specified may be lower if you wish to support older CMake versions for this project. For more information run "cmake --help-policy CMP0000". This warning is for project developers. Use -Wno-dev to suppress it. -- Configuring incomplete, errors occurred! See also "/build/CMakeFiles/CMakeOutput.log". See also "/build/CMakeFiles/CMakeError.log". Steps to Reproduce: - Rename "Xcode.app" to "Xcode Test.app" - Run "sudo xcode-select -switch /Applications/Xcode\ Test.app - Run cmake, with "Unix Makefiles" generator Additional Information: The "Xcode" generator seems to work, I just have to specify the "CMAKE_C_COMPILER" and "CMAKE_CXX_COMPILER" defines, due to cmake not yet supporting Xcode 7 (? works fine with 6). ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-28 05:43 leandros New Issue ====================================================================== From Mike.Pagel at bmw.de Mon Sep 28 09:45:44 2015 From: Mike.Pagel at bmw.de (Mike.Pagel at bmw.de) Date: Mon, 28 Sep 2015 13:45:44 +0000 Subject: [cmake-developers] [Patch] Timestamp of VS-generator rule files Message-ID: <55FD441CAE5A314D8DD773CF40E1048B14E9348A@smucm57b> As requested, I put the patch right into the VS10 target generator. Please note that this requires a new dependency on , which was _not_ there before. I tried to stick to the existing style. Please let me know if I need to use different APIs or anything else needs to be improved. Thanks, Mike -----Urspr?ngliche Nachricht----- Von: cmake-developers [mailto:cmake-developers-bounces at cmake.org] Im Auftrag von Brad King Gesendet: Freitag, 25. September 2015 14:34 An: cmake-developers at cmake.org Betreff: Re: [cmake-developers] Timestamp of VS-generator rule files On 09/25/2015 07:45 AM, Mike.Pagel at bmw.de wrote: > I wrote a small function OutdateFileTime(const std::string& filename) > which does what it sounds like. It is called by the VS generator right > after rule file creation with Touch. I wasn't sure whether this function, > which uses Win32 API should go into the generator code or SystemTools. Until the functionality is needed elsewhere I see no reason not to just put it right in the generator implementation. If a more general purpose for it is found later it can be refactored over to SystemTools and made to work on more platforms. No need for that yet though. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers -------------- next part -------------- A non-text attachment was scrubbed... Name: vs-old-rule-files.patch Type: application/octet-stream Size: 3389 bytes Desc: vs-old-rule-files.patch URL: From brad.king at kitware.com Mon Sep 28 11:34:28 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Sep 2015 11:34:28 -0400 Subject: [cmake-developers] [Patch] Timestamp of VS-generator rule files In-Reply-To: <55FD441CAE5A314D8DD773CF40E1048B14E9348A@smucm57b> References: <55FD441CAE5A314D8DD773CF40E1048B14E9348A@smucm57b> Message-ID: <56095E04.9050909@kitware.com> On 09/28/2015 09:45 AM, Mike.Pagel at bmw.de wrote: > As requested, I put the patch right into the VS10 target generator. Thanks. Applied with minor tweaks: VS: Prevent generated "rule" files from causing rebuilds http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fa5284f0 -Brad From brad.king at kitware.com Mon Sep 28 13:42:46 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Sep 2015 13:42:46 -0400 Subject: [cmake-developers] CXX_STANDARD and linking In-Reply-To: <8772E487-A7D5-4C13-A4C9-1711380D7A20@sap.com> References: <333A65FC-B334-4266-83CD-E455823FC8CD@sap.com> <56056725.5050503@kitware.com> <8772E487-A7D5-4C13-A4C9-1711380D7A20@sap.com> Message-ID: <56097C16.3020301@kitware.com> On 09/28/2015 03:55 AM, CHEVRIER, Marc wrote: > Anyway, the main problem is the fact that, currently, C++ standard handling > is not usable on Solaris. Do have any plan to fix this problem anytime soon? > > On 25/09/15 17:24, "Brad King" wrote: >> Compiling with a -std= flag should link with such a flag too. >> Flags like this are why CMake has always passed CMAKE_CXX_FLAGS >> to the C++ compiler when using it to drive the linker. This does >> not appear to be the case anywhere right now when the flag is added >> via CXX_STANDARD. Steve? According to cmake-compile-features(7) you tested this with Oracle SolarisStudio version 12.4. However, our dashboard covered only up through 12.3. The logic in cmLocalGenerator::AddCompileOptions that selects the final _STANDARD level and adds a flag for it may need to be factored out into a separate step (in Compute?) that selects the level. Then AddCompileOptions can continue to add the compiler flag and we'll need new code to add link-time compiler-driver flags based on the selected standard level. Thanks, -Brad From steveire at gmail.com Mon Sep 28 14:34:04 2015 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 28 Sep 2015 20:34:04 +0200 Subject: [cmake-developers] CXX_STANDARD and linking References: <333A65FC-B334-4266-83CD-E455823FC8CD@sap.com> <56056725.5050503@kitware.com> <8772E487-A7D5-4C13-A4C9-1711380D7A20@sap.com> <56097C16.3020301@kitware.com> Message-ID: Brad King wrote: > On 09/28/2015 03:55 AM, CHEVRIER, Marc wrote: >> Anyway, the main problem is the fact that, currently, C++ standard >> handling is not usable on Solaris. Do have any plan to fix this problem >> anytime soon? >> >> On 25/09/15 17:24, "Brad King" wrote: >>> Compiling with a -std= flag should link with such a flag too. >>> Flags like this are why CMake has always passed CMAKE_CXX_FLAGS >>> to the C++ compiler when using it to drive the linker. This does >>> not appear to be the case anywhere right now when the flag is added >>> via CXX_STANDARD. > > Steve? According to cmake-compile-features(7) you tested this with > Oracle SolarisStudio version 12.4. However, our dashboard covered > only up through 12.3. Yes, I tested it on SolarisStudio 12.4, but on linux (Ubuntu). Perhaps that's a relevant difference from 'real' Solaris. Thanks, Steve. From brad.king at kitware.com Mon Sep 28 15:20:03 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Sep 2015 15:20:03 -0400 Subject: [cmake-developers] CXX_STANDARD and linking In-Reply-To: References: <333A65FC-B334-4266-83CD-E455823FC8CD@sap.com> <56056725.5050503@kitware.com> <8772E487-A7D5-4C13-A4C9-1711380D7A20@sap.com> <56097C16.3020301@kitware.com> Message-ID: <560992E3.2070907@kitware.com> On 09/28/2015 02:34 PM, Stephen Kelly wrote: >> Steve? According to cmake-compile-features(7) you tested this with >> Oracle SolarisStudio version 12.4. > > Yes, I tested it on SolarisStudio 12.4, but on linux (Ubuntu). Perhaps > that's a relevant difference from 'real' Solaris. That seems to be the case. The interaction with C++ runtime library selection may differ. Although we had dashboard builds for SolarisStudio 12.3 on SunOS the compiler feature/standard logic is enabled only for SunPro 5.13 and above which do not appear until SolarisStudio 12.4. On 09/28/2015 01:42 PM, Brad King wrote: > The logic in cmLocalGenerator::AddCompileOptions that selects the final > _STANDARD level and adds a flag for it may need to be factored > out into a separate step (in Compute?) that selects the level. Then > AddCompileOptions can continue to add the compiler flag and we'll need > new code to add link-time compiler-driver flags based on the selected > standard level. Steve, does using _STANDARD to put -std= flags on the link line seem like the right approach to fix this? This won't be done before CMake 3.4 so for now we should look at turning off all language standard and compile feature support for SolarisStudio when not hosted on Linux. Thanks, -Brad From Gilles.Khouzam at microsoft.com Mon Sep 28 17:35:18 2015 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Mon, 28 Sep 2015 21:35:18 +0000 Subject: [cmake-developers] [Patch] Adding Windows 10 support References: <55F0496A.1040205@kitware.com> <55F18811.8000400@kitware.com> <55F1D428.4030707@kitware.com> <55F1D516.802@kitware.com> <56001D8D.3070703@kitware.com> <56029D3D.80405@kitware.com> <5602B44E.5030309@kitware.com> <56045E6C.30904@kitware.com> <56059800.5050502@kitware.com> Message-ID: The more I think about it, the more this makes sense and should work out well. Let me take your current changes and adapt them for this and test them out. -----Original Message----- From: Gilles Khouzam Sent: Friday, September 25, 2015 14:55 To: 'Brad King' Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] [Patch] Adding Windows 10 support You're right, by targeting another version (8.1 or 6.3), the tag would not be written. Leveraging CMAKE_SYSTEM_VERSION is an interesting idea. Let me mull it over a little bit more and see how I would apply to newer SDKs as they come out, as I would like to minimize the required changes to CMake to support things when they come out (I'm gathering some information on that). -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Friday, September 25, 2015 11:53 To: Gilles Khouzam Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/25/2015 01:00 PM, Gilles Khouzam wrote: > This was done deliberately to only force a value for > CMAKE_WINDOWS_TARGET_PLATFORM_VERSION With the approach in my patch that variable is never set by the generator. It chooses a WindowsTargetPlatformVersion value and reports it in CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION. The CMAKE_WINDOWS_TARGET_PLATFORM_VERSION variable is only for the user-defined selection. > when the CMAKE_SYSTEM_VERSION is specified as 10.0. > Otherwise any Windows 10 machine will use the Windows 10 SDK and not > the Windows 8.1 SDK Why is it wrong to target the host's version by default? This is commonly done on other platforms. If one is building only for the current host this makes sense. If one is building for deployment then extra care is needed anyway. > and I'm not sure that there is a way then target the Windows 8.1 SDK. If one wants to build on a Windows 10 host but target an older version of Windows, one can simply do -DCMAKE_SYSTEM_VERSION=6.3 for example. This is thanks to your patch that allows it to be set separately from CMAKE_SYSTEM_NAME. Actually, why do we need a separate setting like CMAKE_WINDOWS_TARGET_PLATFORM_VERSION to select this at all? Why not just take the highest available SDK that does not exceed CMAKE_SYSTEM_VERSION? CMAKE_SYSTEM_VERSION is meant exactly to specify the target OS version. You posted something about this here: https://cmake.org/Bug/view.php?id=15670#c39247 but I do not quite understand it. Thanks, -Brad From cmake-2015 at ryandesign.com Mon Sep 28 22:38:33 2015 From: cmake-2015 at ryandesign.com (Ryan Schmidt) Date: Mon, 28 Sep 2015 21:38:33 -0500 Subject: [cmake-developers] cmake fails to identify C and CXX compiler when building universal Message-ID: <9D4244DF-2133-421C-B858-40E4E99115E0@ryandesign.com> Hello, I am a developer with the MacPorts package management system, and I want to report to you a bug in cmake 3.3.2 that affects OS X. I was going to file a bug report in your issue tracker, but the bright yellow box at the top of the "report issue" page made it sound like I should send my report here instead. The problem is that cmake cannot identify the compiler, when compiling any project (that uses cmake) universally (i.e. for more than one architecture, e.g. for both x86_64 and i386): -- cmake version 3.3.2 -- The C compiler identification is unknown -- The CXX compiler identification is unknown This could cause programs that rely on identifying the compiler to either build incorrectly or even (e.g. in the case of x265) to fail to build at all. For cross-referencing purposes, this problem was previously reported to the MacPorts project here: https://trac.macports.org/ticket/48331 The problem does not occur when compiling non-universally (i.e. for only a single architecture, e.g. for only x86_64): -- The C compiler identification is AppleClang 7.0.0.7000072 -- The CXX compiler identification is AppleClang 7.0.0.7000072 I found that in CMakeDetermineCompilerId.cmake, cmake compiles a test program (CMAKE_DETERMINE_COMPILER_ID_BUILD) which defines certain strings that describe the compiler, and then examines the strings in the compiled a.out file (CMAKE_DETERMINE_COMPILER_ID_CHECK). If the file contains more than one "INFO:compiler[...]" string, cmake assumes something went wrong and sets COMPILER_ID_TWICE to 1 which causes the compiler id to be forgotten. The problem is that when building universal, the a.out file produced by the test will contain multiple copies of the strings -- once for each architecture. What the compiler does for you when you use multiple -arch flags is to compile the file separately, once for each architecture, then glue the separate files together into a single file (using the lipo program), so naturally such a file will contain multiple copies of any strings. This is not a bug; this is how universal binaries work. The bug is that cmake considers this valid condition to be erroneous. Here is an example of the duplicated strings: $ lipo -info build/CMakeFiles/3.3.2/CompilerIdC/a.out Architectures in the fat file: work/build/CMakeFiles/3.3.2/CompilerIdC/a.out are: x86_64 i386 $ strings -arch all build/CMakeFiles/3.3.2/CompilerIdC/a.out INFO:compiler[AppleClang] INFO:platform[Darwin] INFO:arch[] INFO:compiler_version[00000007.00000000.00000000.07000072] INFO:compiler[AppleClang] INFO:platform[Darwin] INFO:arch[] INFO:compiler_version[00000007.00000000.00000000.07000072] (I know cmake uses its internal FILE(STRINGS) command, not the strings program, but I presume they are similar.) I was able to get cmake to correctly identify the compilers even when building universal by simply removing the COMPILER_ID_TWICE stuff from CMakeDetermineCompilerId.cmake, but perhaps you want something more elegant that verifies that if there are multiple definitions of a particular info line, all the definitions are the same. From konstantin at podsvirov.pro Tue Sep 29 01:19:22 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Tue, 29 Sep 2015 08:19:22 +0300 Subject: [cmake-developers] [PATCH] FindOpenSSL: Imported Targets Release Note Message-ID: <1233101443503962@web4j.yandex.ru> Hello, dear developers! With this commit the module provides : http://cmake.org/gitweb?p=cmake.git;a=commit;h=a0dab7b774d5b7a619fd26926c2faf11f9d70309 Then I forgot to reflect this in the release notes. Patch attached. -- Regards, Konstantin Podsvirov -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindOpenSSL-Imported-Targets-Release-Note.patch Type: text/x-diff Size: 783 bytes Desc: not available URL: From nilsgladitz at gmail.com Tue Sep 29 02:54:01 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 29 Sep 2015 08:54:01 +0200 Subject: [cmake-developers] cmake fails to identify C and CXX compiler when building universal In-Reply-To: <9D4244DF-2133-421C-B858-40E4E99115E0@ryandesign.com> References: <9D4244DF-2133-421C-B858-40E4E99115E0@ryandesign.com> Message-ID: <560A3589.8090705@gmail.com> On 09/29/2015 04:38 AM, Ryan Schmidt wrote: > Hello, I am a developer with the MacPorts package management system, and I want to report to you a bug in cmake 3.3.2 that affects OS X. > > I was going to file a bug report in your issue tracker, but the bright yellow box at the top of the "report issue" page made it sound like I should send my report here instead. > > The problem is that cmake cannot identify the compiler, when compiling any project (that uses cmake) universally (i.e. for more than one architecture, e.g. for both x86_64 and i386): > > -- cmake version 3.3.2 > -- The C compiler identification is unknown > -- The CXX compiler identification is unknown > > This could cause programs that rely on identifying the compiler to either build incorrectly or even (e.g. in the case of x265) to fail to build at all. For cross-referencing purposes, this problem was previously reported to the MacPorts project here: > > https://trac.macports.org/ticket/48331 Is it possible that beyond setting CMAKE_OSX_ARCHITECTURES the project also tries to manually add -arch flags to CFLAGS/CXXFLAGS? The test binary produced for compiler identification with just CMAKE_OSX_ARCHITECTURES set is not a fat binary for me and identification is successful (CMake 3.3.2). Manually adding "-arch x86_64 -arch i386" to the compiler flags breaks this since now the test binary itself is also fat. Nils From marc.chevrier at sap.com Tue Sep 29 03:04:53 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Tue, 29 Sep 2015 07:04:53 +0000 Subject: [cmake-developers] CXX_STANDARD and linking In-Reply-To: <560992E3.2070907@kitware.com> References: <333A65FC-B334-4266-83CD-E455823FC8CD@sap.com> <56056725.5050503@kitware.com> <8772E487-A7D5-4C13-A4C9-1711380D7A20@sap.com> <56097C16.3020301@kitware.com> <560992E3.2070907@kitware.com> Message-ID: On Solaris, activating C++11 standard switch the compiler into a completely different mode: * Mangling is different * C++ runtime is the GNU one, delivered as part of SolarisStudio 12.4 (Sun C++ runtime is no longer supported) This is why the flag -std=c++11 must be passed to the link step to enable compiler to select the correct runtime? Marc On 28/09/15 21:20, "cmake-developers on behalf of Brad King" wrote: >On 09/28/2015 02:34 PM, Stephen Kelly wrote: >>> Steve? According to cmake-compile-features(7) you tested this with >>> Oracle SolarisStudio version 12.4. >> >> Yes, I tested it on SolarisStudio 12.4, but on linux (Ubuntu). Perhaps >> that's a relevant difference from 'real' Solaris. > >That seems to be the case. The interaction with C++ runtime library >selection may differ. > >Although we had dashboard builds for SolarisStudio 12.3 on SunOS the >compiler feature/standard logic is enabled only for SunPro 5.13 and >above which do not appear until SolarisStudio 12.4. > >On 09/28/2015 01:42 PM, Brad King wrote: >> The logic in cmLocalGenerator::AddCompileOptions that selects the final >> _STANDARD level and adds a flag for it may need to be factored >> out into a separate step (in Compute?) that selects the level. Then >> AddCompileOptions can continue to add the compiler flag and we'll need >> new code to add link-time compiler-driver flags based on the selected >> standard level. > >Steve, does using _STANDARD to put -std= flags on the link line >seem like the right approach to fix this? > >This won't be done before CMake 3.4 so for now we should look at >turning off all language standard and compile feature support for >SolarisStudio when not hosted on Linux. > >Thanks, >-Brad >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For more information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > >Follow this link to subscribe/unsubscribe: >http://public.kitware.com/mailman/listinfo/cmake-developers From mantis at public.kitware.com Tue Sep 29 13:13:06 2015 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 29 Sep 2015 13:13:06 -0400 Subject: [cmake-developers] [CMake 0015761]: CMake should provide a variable to get arguments used to configure. Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=15761 ====================================================================== Reported By: Ilya Assigned To: ====================================================================== Project: CMake Issue ID: 15761 Category: CMake Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2015-09-29 13:13 EDT Last Modified: 2015-09-29 13:13 EDT ====================================================================== Summary: CMake should provide a variable to get arguments used to configure. Description: When making a build on CI, it's often convenient to embed a file into artifact that contains information about how cmake was configured. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2015-09-29 13:13 Ilya New Issue ====================================================================== From brad.king at kitware.com Tue Sep 29 15:56:13 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 29 Sep 2015 15:56:13 -0400 Subject: [cmake-developers] [PATCH] FindOpenSSL: Imported Targets Release Note In-Reply-To: <1233101443503962@web4j.yandex.ru> References: <1233101443503962@web4j.yandex.ru> Message-ID: <560AECDD.9010103@kitware.com> On 9/29/2015 1:19 AM, Konstantin Podsvirov wrote: > reflect this in the release notes. Good catch. Applied, thanks: Help: Add notes for topic 'FindOpenSSL-imported-targets' https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0429c384 -Brad From konstantin at podsvirov.pro Tue Sep 29 16:04:55 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Tue, 29 Sep 2015 23:04:55 +0300 Subject: [cmake-developers] [PATCH] FindOpenSSL: Imported Targets Release Note In-Reply-To: <560AECDD.9010103@kitware.com> References: <1233101443503962@web4j.yandex.ru> <560AECDD.9010103@kitware.com> Message-ID: <2357831443557095@web10g.yandex.ru> Hi, Brad! 29.09.2015, 22:56, "Brad King" : > On 9/29/2015 1:19 AM, Konstantin Podsvirov wrote: >> reflect this in the release notes. > > Good catch. Applied, thanks: > > Help: Add notes for topic 'FindOpenSSL-imported-targets' > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0429c384 > > -Brad Had to do it immediately. I understand it now. For my contributions on the topic CPackIFW you made notes. Now I have learned and try to follow the changes notes. Done before freeze :-) -- Regards, Konstantin Podsvirov From cmake-2015 at ryandesign.com Tue Sep 29 17:13:08 2015 From: cmake-2015 at ryandesign.com (Ryan Schmidt) Date: Tue, 29 Sep 2015 16:13:08 -0500 Subject: [cmake-developers] cmake fails to identify C and CXX compiler when building universal In-Reply-To: <560A3589.8090705@gmail.com> References: <9D4244DF-2133-421C-B858-40E4E99115E0@ryandesign.com> <560A3589.8090705@gmail.com> Message-ID: On Sep 29, 2015, at 1:54 AM, Nils Gladitz wrote: > Is it possible that beyond setting CMAKE_OSX_ARCHITECTURES the project also tries to manually add -arch flags to CFLAGS/CXXFLAGS? > > The test binary produced for compiler identification with just CMAKE_OSX_ARCHITECTURES set is not a fat binary for me and identification is successful (CMake 3.3.2). > > Manually adding "-arch x86_64 -arch i386" to the compiler flags breaks this since now the test binary itself is also fat. You are correct: in addition to giving cmake the -DCMAKE_OSX_ARCHITECTURES="x86_64;i386" argument, MacPorts includes "-arch x86_64 -arch i386" in the CFLAGS, CXXFLAGS, and LDFLAGS environment variables. I am not certain, but I think the only reason why we are doing this for cmake-using ports is that we do this for all ports, and no code was ever added to override this for cmake-using ports. Perhaps this didn't cause problems before, or we never noticed it caused problems before. I will work adding code to MacPorts to remove these flags for cmake-using ports. Thanks for the suggestion. From pasanen.tuukka at gmail.com Wed Sep 30 02:34:25 2015 From: pasanen.tuukka at gmail.com (Tuukka Pasanen) Date: Wed, 30 Sep 2015 09:34:25 +0300 Subject: [cmake-developers] CMake Find modules out of the CMake tree Message-ID: <560B8271.4090306@gmail.com> Hello, I've been using successfully CMake for years and one can find almost Find-functions for everything (SDL2 for example) from dark corners net but then comes the question. Is there any project that tracks down these out of tree modules and makes them easily install because now I have to keep them in tree and find 'best' version of script (because there is several in-tree version available). So do anyone know is there coordinated effort to do this kind of 'Incubator' modules repository? Sincerely, Tuukka From brad.king at kitware.com Wed Sep 30 10:01:26 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Sep 2015 10:01:26 -0400 Subject: [cmake-developers] CXX_STANDARD and linking In-Reply-To: <560992E3.2070907@kitware.com> References: <333A65FC-B334-4266-83CD-E455823FC8CD@sap.com> <56056725.5050503@kitware.com> <8772E487-A7D5-4C13-A4C9-1711380D7A20@sap.com> <56097C16.3020301@kitware.com> <560992E3.2070907@kitware.com> Message-ID: <560BEB36.1050504@kitware.com> On 09/28/2015 03:20 PM, Brad King wrote: > for now we should look at turning off all language standard and > compile feature support for SolarisStudio when not hosted on Linux. Done here: Features: Disable support for Oracle SolarisStudio on non-Linux https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=61bc0f73 Tests: Suppress WriteCompilerDetectionHeader failure on SunPro https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5fdf7594 I also made a fix for Linux: Features: Fix C++98 flags on Oracle SolarisStudio 12.4 on Linux https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c824b23d Steve, please review these changes. Thanks, -Brad From brad.king at kitware.com Wed Sep 30 10:22:47 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Sep 2015 10:22:47 -0400 Subject: [cmake-developers] CMake Find modules out of the CMake tree In-Reply-To: <560B8271.4090306@gmail.com> References: <560B8271.4090306@gmail.com> Message-ID: <560BF037.8070203@kitware.com> On 09/30/2015 02:34 AM, Tuukka Pasanen wrote: > I've been using successfully CMake for years and one can find almost > Find-functions for everything (SDL2 for example) from dark corners net > but then comes the question. Is there any project that tracks down these > out of tree modules and makes them easily install because now I have to > keep them in tree and find 'best' version of script (because there is > several in-tree version available). So do anyone know is there > coordinated effort to do this kind of 'Incubator' modules repository? I'm not aware of a project with that specific purpose off the top of my head. The closest project may be KDE's extra-cmake-modules: https://community.kde.org/Frameworks/Building/Details#Extra_CMake_Modules http://api.kde.org/ecm/manual/ecm.7.html With regard to SDL2, the proper way to make it find-able with CMake is for SDL2 to provide a CMake packaging files themselves as part of their own distribution (since they build with CMake): https://cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html This is why upstream CMake does not have a find module for SDL2. We cannot possibly maintain a find module with deep awareness of libraries/versions/etc. for every project out there. -Brad From marc.chevrier at sap.com Wed Sep 30 10:23:04 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Wed, 30 Sep 2015 14:23:04 +0000 Subject: [cmake-developers] CXX_STANDARD and linking In-Reply-To: <560BEB36.1050504@kitware.com> References: <333A65FC-B334-4266-83CD-E455823FC8CD@sap.com> <56056725.5050503@kitware.com> <8772E487-A7D5-4C13-A4C9-1711380D7A20@sap.com> <56097C16.3020301@kitware.com> <560992E3.2070907@kitware.com> <560BEB36.1050504@kitware.com> Message-ID: Seems OK for me? But my personal situation is even worst now! :) The situation evolved from a buggy support of C++11 on Solaris to no support at all. Do you have any idea (and schedule) for re-introduction of this feature, knowing that the key point is the lack of propagating of c++11 compile option to the link command. Thank you for your help. Marc On 30/09/15 16:01, "Brad King" wrote: >On 09/28/2015 03:20 PM, Brad King wrote: >> for now we should look at turning off all language standard and >> compile feature support for SolarisStudio when not hosted on Linux. > >Done here: > > Features: Disable support for Oracle SolarisStudio on non-Linux > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=61bc0f73 > > Tests: Suppress WriteCompilerDetectionHeader failure on SunPro > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5fdf7594 > >I also made a fix for Linux: > > Features: Fix C++98 flags on Oracle SolarisStudio 12.4 on Linux > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c824b23d > >Steve, please review these changes. > >Thanks, >-Brad From ben.boeckel at kitware.com Wed Sep 30 11:11:37 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 30 Sep 2015 11:11:37 -0400 Subject: [cmake-developers] CMake Find modules out of the CMake tree In-Reply-To: <560BF037.8070203@kitware.com> References: <560B8271.4090306@gmail.com> <560BF037.8070203@kitware.com> Message-ID: <20150930151137.GA30573@megas.khq.kitware.com> On Wed, Sep 30, 2015 at 10:22:47 -0400, Brad King wrote: > With regard to SDL2, the proper way to make it find-able with CMake is > for SDL2 to provide a CMake packaging files themselves as part of their > own distribution (since they build with CMake): Just to note, SDL2 also has build systems for ~every buildsystem out there (VS projects, Xcode projects, Android.mk, autotools, premake, etc.). I *think* those are for ease-of-embedding, but I doubt the non-CMake ones generate SDL2Config.cmake files. --Ben From tamas.kenez at gmail.com Wed Sep 30 11:45:37 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Wed, 30 Sep 2015 17:45:37 +0200 Subject: [cmake-developers] CMake Find modules out of the CMake tree In-Reply-To: <20150930151137.GA30573@megas.khq.kitware.com> References: <560B8271.4090306@gmail.com> <560BF037.8070203@kitware.com> <20150930151137.GA30573@megas.khq.kitware.com> Message-ID: > but I doubt the non-CMake ones generate SDL2Config.cmake files. neither of them generates, not even the CMake one On Wed, Sep 30, 2015 at 5:11 PM, Ben Boeckel wrote: > On Wed, Sep 30, 2015 at 10:22:47 -0400, Brad King wrote: > > With regard to SDL2, the proper way to make it find-able with CMake is > > for SDL2 to provide a CMake packaging files themselves as part of their > > own distribution (since they build with CMake): > > Just to note, SDL2 also has build systems for ~every buildsystem out > there (VS projects, Xcode projects, Android.mk, autotools, premake, > etc.). I *think* those are for ease-of-embedding, but I doubt the > non-CMake ones generate SDL2Config.cmake files. > > --Ben > -- > > 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 Gilles.Khouzam at microsoft.com Wed Sep 30 17:05:45 2015 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Wed, 30 Sep 2015 21:05:45 +0000 Subject: [cmake-developers] [Patch] Adding Windows 10 support In-Reply-To: References: <55F0496A.1040205@kitware.com> <55F18811.8000400@kitware.com> <55F1D428.4030707@kitware.com> <55F1D516.802@kitware.com> <56001D8D.3070703@kitware.com> <56029D3D.80405@kitware.com> <5602B44E.5030309@kitware.com> <56045E6C.30904@kitware.com> <56059800.5050502@kitware.com> Message-ID: Hi Brad, I've changed the code of the 3rd patch to remove the WINDOWS_TARGET_PLATFORM_VERSION and CMAKE_WINDOWS_TARGET_PLATFORM_VERSION and simply use the SystemVersion to determine the version of the Windows 10 SDK to use. Now, by default on Windows 10 host devices with Visual Studio 2015, the latest SDK will be used. I've also changed the sorting of the SDKs and comparison checks to use cmSystemTools::VersionCompare. -----Original Message----- From: Gilles Khouzam Sent: Monday, September 28, 2015 14:35 To: Brad King Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] [Patch] Adding Windows 10 support The more I think about it, the more this makes sense and should work out well. Let me take your current changes and adapt them for this and test them out. -----Original Message----- From: Gilles Khouzam Sent: Friday, September 25, 2015 14:55 To: 'Brad King' Cc: cmake-developers at cmake.org Subject: RE: [cmake-developers] [Patch] Adding Windows 10 support You're right, by targeting another version (8.1 or 6.3), the tag would not be written. Leveraging CMAKE_SYSTEM_VERSION is an interesting idea. Let me mull it over a little bit more and see how I would apply to newer SDKs as they come out, as I would like to minimize the required changes to CMake to support things when they come out (I'm gathering some information on that). -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Friday, September 25, 2015 11:53 To: Gilles Khouzam Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support On 09/25/2015 01:00 PM, Gilles Khouzam wrote: > This was done deliberately to only force a value for > CMAKE_WINDOWS_TARGET_PLATFORM_VERSION With the approach in my patch that variable is never set by the generator. It chooses a WindowsTargetPlatformVersion value and reports it in CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION. The CMAKE_WINDOWS_TARGET_PLATFORM_VERSION variable is only for the user-defined selection. > when the CMAKE_SYSTEM_VERSION is specified as 10.0. > Otherwise any Windows 10 machine will use the Windows 10 SDK and not > the Windows 8.1 SDK Why is it wrong to target the host's version by default? This is commonly done on other platforms. If one is building only for the current host this makes sense. If one is building for deployment then extra care is needed anyway. > and I'm not sure that there is a way then target the Windows 8.1 SDK. If one wants to build on a Windows 10 host but target an older version of Windows, one can simply do -DCMAKE_SYSTEM_VERSION=6.3 for example. This is thanks to your patch that allows it to be set separately from CMAKE_SYSTEM_NAME. Actually, why do we need a separate setting like CMAKE_WINDOWS_TARGET_PLATFORM_VERSION to select this at all? Why not just take the highest available SDK that does not exceed CMAKE_SYSTEM_VERSION? CMAKE_SYSTEM_VERSION is meant exactly to specify the target OS version. You posted something about this here: https://cmake.org/Bug/view.php?id=15670#c39247 but I do not quite understand it. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-VS-Add-support-for-selecting-the-Windows-10-SDK.PATCH Type: application/octet-stream Size: 11459 bytes Desc: 0003-VS-Add-support-for-selecting-the-Windows-10-SDK.PATCH URL: