From mantis at public.kitware.com Fri Apr 1 05:57:38 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 1 Apr 2016 05:57:38 -0400 Subject: [cmake-developers] [CMake 0016044]: cmake crashed with SIGSEGV in cmTarget::GetProperty() Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16044 ====================================================================== Reported By: Gianfranco Assigned To: ====================================================================== Project: CMake Issue ID: 16044 Category: CMake Reproducibility: have not tried Severity: crash Priority: high Status: new ====================================================================== Date Submitted: 2016-04-01 05:57 EDT Last Modified: 2016-04-01 05:57 EDT ====================================================================== Summary: cmake crashed with SIGSEGV in cmTarget::GetProperty() Description: https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/1564741 As reported on the Ubuntu bug, the culprit seems to be commit a67231ac114235f0af4673235c4c07fa896c8ab6. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-01 05:57 Gianfranco New Issue ====================================================================== From me at rmz.io Fri Apr 1 05:58:50 2016 From: me at rmz.io (Samir Benmendil) Date: Fri, 1 Apr 2016 10:58:50 +0100 Subject: [cmake-developers] [PATCH] ExternalProject: Allow TLS_VERIFY for git clones Message-ID: <1459504730-14234-1-git-send-email-me@rmz.io> Use the git config `http.sslVerify=false` to disable strict ssl for git commands. --- Modules/ExternalProject.cmake | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake index 1185a81..04e35da 100644 --- a/Modules/ExternalProject.cmake +++ b/Modules/ExternalProject.cmake @@ -499,7 +499,7 @@ define_property(DIRECTORY PROPERTY "EP_UPDATE_DISCONNECTED" INHERITED "ExternalProject module." ) -function(_ep_write_gitclone_script script_filename source_dir git_EXECUTABLE git_repository git_tag git_remote_name git_submodules src_name work_dir gitclone_infofile gitclone_stampfile) +function(_ep_write_gitclone_script script_filename source_dir git_EXECUTABLE git_repository git_tag git_remote_name git_submodules src_name work_dir gitclone_infofile gitclone_stampfile tls_verify) file(WRITE ${script_filename} "if(\"${git_tag}\" STREQUAL \"\") message(FATAL_ERROR \"Tag for git checkout should not be empty.\") @@ -524,12 +524,17 @@ if(error_code) message(FATAL_ERROR \"Failed to remove directory: '${source_dir}'\") endif() +# set git_options +if(NOT tls_verify) + set(git_options -c http.sslVerify=false) +endif() + # try the clone 3 times incase there is an odd git clone issue set(error_code 1) set(number_of_tries 0) while(error_code AND number_of_tries LESS 3) execute_process( - COMMAND \"${git_EXECUTABLE}\" clone --origin \"${git_remote_name}\" \"${git_repository}\" \"${src_name}\" + COMMAND \"${git_EXECUTABLE}\" \${git_options} clone --origin \"${git_remote_name}\" \"${git_repository}\" \"${src_name}\" WORKING_DIRECTORY \"${work_dir}\" RESULT_VARIABLE error_code ) @@ -544,7 +549,7 @@ if(error_code) endif() execute_process( - COMMAND \"${git_EXECUTABLE}\" checkout ${git_tag} + COMMAND \"${git_EXECUTABLE}\" \${git_options} checkout ${git_tag} WORKING_DIRECTORY \"${work_dir}/${src_name}\" RESULT_VARIABLE error_code ) @@ -553,7 +558,7 @@ if(error_code) endif() execute_process( - COMMAND \"${git_EXECUTABLE}\" submodule init ${git_submodules} + COMMAND \"${git_EXECUTABLE}\" \${git_options} submodule init ${git_submodules} WORKING_DIRECTORY \"${work_dir}/${src_name}\" RESULT_VARIABLE error_code ) @@ -562,7 +567,7 @@ if(error_code) endif() execute_process( - COMMAND \"${git_EXECUTABLE}\" submodule update --recursive ${git_submodules} + COMMAND \"${git_EXECUTABLE}\" \${git_options} submodule update --recursive ${git_submodules} WORKING_DIRECTORY \"${work_dir}/${src_name}\" RESULT_VARIABLE error_code ) @@ -1777,6 +1782,11 @@ function(_ep_add_download_command name) set(git_remote_name "origin") endif() + get_property(tls_verify TARGET ${name} PROPERTY _EP_TLS_VERIFY) + if(NOT tls_verify) + set(tls_verify OFF) + endif() + # For the download step, and the git clone operation, only the repository # should be recorded in a configured RepositoryInfo file. If the repo # changes, the clone script should be run again. But if only the tag @@ -1801,7 +1811,7 @@ function(_ep_add_download_command name) # _ep_write_gitclone_script(${tmp_dir}/${name}-gitclone.cmake ${source_dir} ${GIT_EXECUTABLE} ${git_repository} ${git_tag} ${git_remote_name} "${git_submodules}" ${src_name} ${work_dir} - ${stamp_dir}/${name}-gitinfo.txt ${stamp_dir}/${name}-gitclone-lastrun.txt + ${stamp_dir}/${name}-gitinfo.txt ${stamp_dir}/${name}-gitclone-lastrun.txt ${tls_verify} ) set(comment "Performing download step (git clone) for '${name}'") set(cmd ${CMAKE_COMMAND} -P ${tmp_dir}/${name}-gitclone.cmake) -- 2.8.0 From mantis at public.kitware.com Fri Apr 1 08:31:42 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 1 Apr 2016 08:31:42 -0400 Subject: [cmake-developers] [CMake 0016045]: OS X system GLUT should always be preferred to X11's Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=16045 ====================================================================== Reported By: ilovezfs Assigned To: ====================================================================== Project: CMake Issue ID: 16045 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-01 08:31 EDT Last Modified: 2016-04-01 08:31 EDT ====================================================================== Summary: OS X system GLUT should always be preferred to X11's Description: The Homebrew "bottle" build server happens to have X11 installed, but we'd prefer not to force an unnecessary X11 dependency on users. However, by default gl2ps will automatically link against X11's libglut.dylib if X11 happens to be installed. Therefore, I'm having to pass "-DGLUT_glut_LIBRARY=/System/Library/Frameworks/GLUT.framework" to cmake to avoid creating bottles that break on systems without X11. It would be nice if gl2ps used the system GLUT by default even if X11 happens to be installed without our having to manually intervene. This is caused by cmake's find_package(GLUT) which prefers X11's GLUT to the system GLUT if X11 happens to be installed. Instead CMake should always using the system GLUT unless someone deliberately intervenes to choose X11's, regardless of whether X11 is installed or not installed. Steps to Reproduce: Use find_package(GLUT) on a system that happens to have Xquartz (X11) installed. Additional Information: https://github.com/Homebrew/homebrew/pull/50601/ http://www.geuz.org/pipermail/gl2ps/2016/000433.html ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-01 08:31 ilovezfs New Issue ====================================================================== From Melven.Roehrig-Zoellner at dlr.de Fri Apr 1 08:44:29 2016 From: Melven.Roehrig-Zoellner at dlr.de (Melven.Roehrig-Zoellner at dlr.de) Date: Fri, 1 Apr 2016 12:44:29 +0000 Subject: [cmake-developers] [PATCH] language detection in FindBLAS and FindLAPACK (#0016039) Message-ID: <6CCDA91481A9E4418A996AE30C227810021808B9@DLREXMBX01.intra.dlr.de> Patch for a problem with find_package(BLAS/LAPACK) on Windows for pure Fortran projects reported by me in https://cmake.org/Bug/view.php?id=16039. Regards, Melven -------------------------- Deutsches Zentrum f?r Luft- und Raumfahrt e.V. (DLR) German Aerospace Center Simulation and Software Technology | Linder Hoehe | 51147 Cologne | Germany Melven R?hrig-Z?llner Telephone +492203 / 601 - 2574 www.DLR.de -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-for-pure-Fortran-projects-with-BLAS-LAPACK-00160.patch Type: application/octet-stream Size: 4074 bytes Desc: 0001-Fix-for-pure-Fortran-projects-with-BLAS-LAPACK-00160.patch URL: From mantis at public.kitware.com Fri Apr 1 08:56:41 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 1 Apr 2016 08:56:41 -0400 Subject: [cmake-developers] [CMake 0016046]: GHS Multi Generator: duplicate object file names Message-ID: <227453b038df7739d445925ce0cbc241@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16046 ====================================================================== Reported By: stw_sesa Assigned To: ====================================================================== Project: CMake Issue ID: 16046 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-01 08:56 EDT Last Modified: 2016-04-01 08:56 EDT ====================================================================== Summary: GHS Multi Generator: duplicate object file names Description: When a target contains multiple files with the same name (in different (sub)folders) the generated object files will have the same names too. Normally this isn't a problem at all, but for GHS MULTI it is as the duplicates are ignored. Steps to Reproduce: Create a project with a target containing at least two files with the same name like this: add_library(libdemo test.c subfolder/test.c ) Expected result: The library contains both test.o and subfolder/test.o Actual result: Only one of these source files is compiled and archived in the library due to their name equality. A sample project is attached, that will build successfully using other C project generators (e.g Makefile), but won't when using GHS MULTI toolchain. Additional Information: This could also be either a bug in MULTI Project Manager or intended behaviour. However, from the CMake perspective the results are unexpected. A workaround for the generator would be to rename the generated object file by emitting a unique object file name with the option "-o .o" in the generated project files (.gpj). Is there any CMake workaround? (which doesn't require changing CMake itself) Maybe there is an project file option that changes that behaviour? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-01 08:56 stw_sesa New Issue 2016-04-01 08:56 stw_sesa File Added: dup_objname_test.zip ====================================================================== From ben.boeckel at kitware.com Fri Apr 1 10:06:48 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 1 Apr 2016 10:06:48 -0400 Subject: [cmake-developers] [PATCH] language detection in FindBLAS and FindLAPACK (#0016039) In-Reply-To: <6CCDA91481A9E4418A996AE30C227810021808B9@DLREXMBX01.intra.dlr.de> References: <6CCDA91481A9E4418A996AE30C227810021808B9@DLREXMBX01.intra.dlr.de> Message-ID: <20160401140648.GB6589@megas.khq.kitware.com> On Fri, Apr 01, 2016 at 12:44:29 +0000, Melven.Roehrig-Zoellner at dlr.de wrote: > Patch for a problem with find_package(BLAS/LAPACK) on Windows for pure > Fortran projects reported by me in > https://cmake.org/Bug/view.php?id=16039. Thanks. My patch looks similar (differs in variable names basically), but I hadn't gotten around to testing it. --Ben From ben.boeckel at kitware.com Fri Apr 1 10:13:53 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 1 Apr 2016 10:13:53 -0400 Subject: [cmake-developers] [PATCH] ExternalProject: Allow TLS_VERIFY for git clones In-Reply-To: <1459504730-14234-1-git-send-email-me@rmz.io> References: <1459504730-14234-1-git-send-email-me@rmz.io> Message-ID: <20160401141353.GC6589@megas.khq.kitware.com> On Fri, Apr 01, 2016 at 10:58:50 +0100, Samir Benmendil wrote: > +# set git_options > +if(NOT tls_verify) > + set(git_options -c http.sslVerify=false) > +endif() Looks good overall, but could this be turned into a pattern like: set(git_options) if (NOT tls_verify) list(APPEND git_options -c http.sslVerify=false) endif () to help out future options which might make sense? Thanks, --Ben From nilsgladitz at gmail.com Fri Apr 1 10:20:10 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 1 Apr 2016 16:20:10 +0200 Subject: [cmake-developers] [PATCH] language detection in FindBLAS and FindLAPACK (#0016039) In-Reply-To: <6CCDA91481A9E4418A996AE30C227810021808B9@DLREXMBX01.intra.dlr.de> References: <6CCDA91481A9E4418A996AE30C227810021808B9@DLREXMBX01.intra.dlr.de> Message-ID: <56FE839A.6080707@gmail.com> On 04/01/2016 02:44 PM, Melven.Roehrig-Zoellner at dlr.de wrote: > Patch for a problem with find_package(BLAS/LAPACK) on Windows for pure Fortran projects reported by me in https://cmake.org/Bug/view.php?id=16039. > > This might be a use case for the newish IN_LIST operator? e.g. if(Fortran IN_LIST _LANGUAGES_) Nils From me at rmz.io Fri Apr 1 10:39:26 2016 From: me at rmz.io (Samir Benmendil) Date: Fri, 1 Apr 2016 15:39:26 +0100 Subject: [cmake-developers] [PATCH v2] ExternalProject: Allow TLS_VERIFY for git clones Message-ID: <1459521566-11239-1-git-send-email-me@rmz.io> Use the git config `http.sslVerify=false` to disable strict ssl for git commands. --- Changes in v2: - git_options is now a list Modules/ExternalProject.cmake | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake index 1185a81..8d8382f 100644 --- a/Modules/ExternalProject.cmake +++ b/Modules/ExternalProject.cmake @@ -499,7 +499,7 @@ define_property(DIRECTORY PROPERTY "EP_UPDATE_DISCONNECTED" INHERITED "ExternalProject module." ) -function(_ep_write_gitclone_script script_filename source_dir git_EXECUTABLE git_repository git_tag git_remote_name git_submodules src_name work_dir gitclone_infofile gitclone_stampfile) +function(_ep_write_gitclone_script script_filename source_dir git_EXECUTABLE git_repository git_tag git_remote_name git_submodules src_name work_dir gitclone_infofile gitclone_stampfile tls_verify) file(WRITE ${script_filename} "if(\"${git_tag}\" STREQUAL \"\") message(FATAL_ERROR \"Tag for git checkout should not be empty.\") @@ -524,12 +524,18 @@ if(error_code) message(FATAL_ERROR \"Failed to remove directory: '${source_dir}'\") endif() +set(git_options) +if(NOT tls_verify) + list(APPEND git_options + -c http.sslVerify=false) +endif() + # try the clone 3 times incase there is an odd git clone issue set(error_code 1) set(number_of_tries 0) while(error_code AND number_of_tries LESS 3) execute_process( - COMMAND \"${git_EXECUTABLE}\" clone --origin \"${git_remote_name}\" \"${git_repository}\" \"${src_name}\" + COMMAND \"${git_EXECUTABLE}\" \${git_options} clone --origin \"${git_remote_name}\" \"${git_repository}\" \"${src_name}\" WORKING_DIRECTORY \"${work_dir}\" RESULT_VARIABLE error_code ) @@ -544,7 +550,7 @@ if(error_code) endif() execute_process( - COMMAND \"${git_EXECUTABLE}\" checkout ${git_tag} + COMMAND \"${git_EXECUTABLE}\" \${git_options} checkout ${git_tag} WORKING_DIRECTORY \"${work_dir}/${src_name}\" RESULT_VARIABLE error_code ) @@ -553,7 +559,7 @@ if(error_code) endif() execute_process( - COMMAND \"${git_EXECUTABLE}\" submodule init ${git_submodules} + COMMAND \"${git_EXECUTABLE}\" \${git_options} submodule init ${git_submodules} WORKING_DIRECTORY \"${work_dir}/${src_name}\" RESULT_VARIABLE error_code ) @@ -562,7 +568,7 @@ if(error_code) endif() execute_process( - COMMAND \"${git_EXECUTABLE}\" submodule update --recursive ${git_submodules} + COMMAND \"${git_EXECUTABLE}\" \${git_options} submodule update --recursive ${git_submodules} WORKING_DIRECTORY \"${work_dir}/${src_name}\" RESULT_VARIABLE error_code ) @@ -1777,6 +1783,11 @@ function(_ep_add_download_command name) set(git_remote_name "origin") endif() + get_property(tls_verify TARGET ${name} PROPERTY _EP_TLS_VERIFY) + if(NOT tls_verify) + set(tls_verify OFF) + endif() + # For the download step, and the git clone operation, only the repository # should be recorded in a configured RepositoryInfo file. If the repo # changes, the clone script should be run again. But if only the tag @@ -1801,7 +1812,7 @@ function(_ep_add_download_command name) # _ep_write_gitclone_script(${tmp_dir}/${name}-gitclone.cmake ${source_dir} ${GIT_EXECUTABLE} ${git_repository} ${git_tag} ${git_remote_name} "${git_submodules}" ${src_name} ${work_dir} - ${stamp_dir}/${name}-gitinfo.txt ${stamp_dir}/${name}-gitclone-lastrun.txt + ${stamp_dir}/${name}-gitinfo.txt ${stamp_dir}/${name}-gitclone-lastrun.txt ${tls_verify} ) set(comment "Performing download step (git clone) for '${name}'") set(cmd ${CMAKE_COMMAND} -P ${tmp_dir}/${name}-gitclone.cmake) -- 2.8.0 From ben.boeckel at kitware.com Fri Apr 1 10:41:24 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 1 Apr 2016 10:41:24 -0400 Subject: [cmake-developers] [PATCH] language detection in FindBLAS and FindLAPACK (#0016039) In-Reply-To: <56FE839A.6080707@gmail.com> References: <6CCDA91481A9E4418A996AE30C227810021808B9@DLREXMBX01.intra.dlr.de> <56FE839A.6080707@gmail.com> Message-ID: <20160401144124.GB26944@megas.khq.kitware.com> On Fri, Apr 01, 2016 at 16:20:10 +0200, Nils Gladitz wrote: > This might be a use case for the newish IN_LIST operator? > > e.g. if(Fortran IN_LIST _LANGUAGES_) How have I missed this? *goes and makes minimum version of all CMake projects 3.3* ;) --Ben From eike at sf-mail.de Fri Apr 1 11:25:27 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 01 Apr 2016 17:25:27 +0200 Subject: [cmake-developers] [PATCH] language detection in FindBLAS and FindLAPACK (#0016039) In-Reply-To: <56FE839A.6080707@gmail.com> References: <6CCDA91481A9E4418A996AE30C227810021808B9@DLREXMBX01.intra.dlr.de> <56FE839A.6080707@gmail.com> Message-ID: <2418797.i8xVxPebZm@caliban.sf-tec.de> Am Freitag, 1. April 2016, 16:20:10 schrieb Nils Gladitz: > On 04/01/2016 02:44 PM, Melven.Roehrig-Zoellner at dlr.de wrote: > > Patch for a problem with find_package(BLAS/LAPACK) on Windows for pure > > Fortran projects reported by me in > > https://cmake.org/Bug/view.php?id=16039. > This might be a use case for the newish IN_LIST operator? > > e.g. if(Fortran IN_LIST _LANGUAGES_) Why not simply: if (CMAKE_Fortran_COMPILER_LOADED) Greetings, Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From ben.boeckel at kitware.com Fri Apr 1 13:18:03 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 1 Apr 2016 13:18:03 -0400 Subject: [cmake-developers] [PATCH v2] ExternalProject: Allow TLS_VERIFY for git clones In-Reply-To: <1459521566-11239-1-git-send-email-me@rmz.io> References: <1459521566-11239-1-git-send-email-me@rmz.io> Message-ID: <20160401171803.GA6250@megas.khq.kitware.com> On Fri, Apr 01, 2016 at 15:39:26 +0100, Samir Benmendil wrote: > Use the git config `http.sslVerify=false` to disable strict ssl for git > commands. > --- > Changes in v2: > - git_options is now a list Thanks. I've pushed this into next for testing. --Ben From brad.king at kitware.com Fri Apr 1 13:20:35 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 1 Apr 2016 13:20:35 -0400 Subject: [cmake-developers] Fix for re-running FindPythonLibs with multiple configurations In-Reply-To: <1587FF3C24433248A7CC5FEC37270DC1D7B505D0@uxcn10-tdc01.UoA.auckland.ac.nz> References: <1587FF3C24433248A7CC5FEC37270DC1D7B505D0@uxcn10-tdc01.UoA.auckland.ac.nz> Message-ID: <56FEADE3.10405@kitware.com> On 03/31/2016 10:31 PM, Richard Christie wrote: > So I've attached an improved fix, which is much simpler: > it determines whether PYTHON_LIBRARY is a list and extracts > the optimized library out of it. Thanks. Please try this code instead: # If we ran before and reported multiple configurations then PYTHON_LIBRARY # is a list "optimized;PYTHON_LIBRARY;debug;PYTHON_LIBRARY_DEBUG". Extract # the original value so we can re-construct the list properly later. if(";${PYTHON_LIBRARY};" MATCHES ";optimized;([^;]+);") set(PYTHON_LIBRARY "${CMAKE_MATCH_1}") endif() Thanks, -Brad From mantis at public.kitware.com Fri Apr 1 13:36:36 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 1 Apr 2016 13:36:36 -0400 Subject: [cmake-developers] [CMake 0016047]: automoc generates wrong #includes for projects in a symlinked path Message-ID: <7bcf479cc4a8ff903a38d5c541de8b5b@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16047 ====================================================================== Reported By: Maurizio Paolini Assigned To: ====================================================================== Project: CMake Issue ID: 16047 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-01 13:36 EDT Last Modified: 2016-04-01 13:36 EDT ====================================================================== Summary: automoc generates wrong #includes for projects in a symlinked path Description: project "kig" uses cmake and automoc. My local copy of the git sources are located in a folder that I reach following a symlink (it resides in a local partition whereas my home is on an NFS-mounted filesystem). after a cmake and then a "make", the generated "moc*" files contain an "#include" like this: #include "../../../../../misc/euclide/paolini/Git/kdeedu/kig/modes/popup/popup.h" There is a wrong number of ".." and the path does not work. using "make VERBOSE=1 kigpart_automoc" it turns out that the following command is issued: /usr/lib/qt5/bin/moc -I/home/matem/paolini/Git/kdeedu/kig/modes [...] -o /home/matem/paolini/Git/kdeedu/kig/moc_popup.cpp /home/misc/euclide/paolini/Git/kdeedu/kig/modes/popup/popup.h where the [...] part contains many more -I and various options. Notice that "/home/matem/paolini/Git/" and "/home/misc/euclide/paolini/Git/" point to the same place, the first through the symlink "Git", the second is the physical path. I guess that then "moc" tries hard to walk (with a relative path) from one path to the other, but there is no way to successfully climb up a path with a symlink in it using the ".." directory. This problem was previously reported in the QT bug tracker https://bugreports.qt.io/browse/QTBUG-51964 Steps to Reproduce: $ mkdir -p a/b $ ln -s a/b a.lnk $ cd a.lnk $ $ cd $ cmake . [...] $ make ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-01 13:36 Maurizio PaoliniNew Issue ====================================================================== From mantis at public.kitware.com Fri Apr 1 15:22:37 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 1 Apr 2016 15:22:37 -0400 Subject: [cmake-developers] [CMake 0016048]: Segfault on target_link_libraries() with aliased target from another subdirectory Message-ID: <7a70249dd685ba28585bfeed683b26db@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=16048 ====================================================================== Reported By: arlbranch Assigned To: ====================================================================== Project: CMake Issue ID: 16048 Category: CMake Reproducibility: always Severity: crash Priority: high Status: new ====================================================================== Date Submitted: 2016-04-01 15:22 EDT Last Modified: 2016-04-01 15:22 EDT ====================================================================== Summary: Segfault on target_link_libraries() with aliased target from another subdirectory Description: CMake crashes with a segfault when target_link_libraries is used to add a dependency on an alias of a target that was added in a different subdirectory. Complete Example ================ [branch at fortuna on /dev/pts/1] 1150 ~/repositories/test/cmake_segfault $ cmake --version cmake version 3.5.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). [branch at fortuna on /dev/pts/1] 1151 ~/repositories/test/cmake_segfault $ ls -lR .: total 12 drwxr-xr-x 2 branch atlsdd 4096 Apr 1 13:37 alib/ drwxr-xr-x 2 branch atlsdd 4096 Apr 1 14:14 blib/ -rw-r--r-- 1 branch atlsdd 98 Apr 1 13:18 CMakeLists.txt ./alib: total 4 -rw-r--r-- 1 branch atlsdd 87 Apr 1 13:24 CMakeLists.txt ./blib: total 4 -rw-r--r-- 1 branch atlsdd 162 Apr 1 13:38 CMakeLists.txt [branch at fortuna on /dev/pts/1] 1152 ~/repositories/test/cmake_segfault $ cat CMakeLists.txt cmake_minimum_required(VERSION 2.8.11) project(top) add_subdirectory(alib) add_subdirectory(blib) [branch at fortuna on /dev/pts/1] 1153 ~/repositories/test/cmake_segfault $ cat alib/CMakeLists.txt add_library(alib alib.c) set_source_files_properties(alib.c PROPERTIES GENERATED TRUE) [branch at fortuna on /dev/pts/1] 1154 ~/repositories/test/cmake_segfault $ cat blib/CMakeLists.txt add_library(blib blib.c) set_source_files_properties(blib.c PROPERTIES GENERATED TRUE) add_library(alib::alib ALIAS alib) target_link_libraries(blib alib::alib) [branch at fortuna on /dev/pts/1] 1155 ~/repositories/test/cmake_segfault $ mkdir build && cd build [branch at fortuna on /dev/pts/1] 1156 ~/repositories/test/cmake_segfault/build $ cmake .. -- The C compiler identification is GNU 5.3.0 -- The CXX compiler identification is GNU 5.3.0 -- 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 Segmentation fault (core dumped) Steps to Reproduce: 1) create the project in the Description 2) run cmake against it Additional Information: Also seen on MacOS. This is a regression, cmake 3.4 does not crash. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-01 15:22 arlbranch New Issue ====================================================================== From Melven.Roehrig-Zoellner at dlr.de Sun Apr 3 17:21:35 2016 From: Melven.Roehrig-Zoellner at dlr.de (Melven.Roehrig-Zoellner at dlr.de) Date: Sun, 3 Apr 2016 21:21:35 +0000 Subject: [cmake-developers] [PATCH v2] language detection in FindBLAS and FindLAPACK (#0016039) Message-ID: <6CCDA91481A9E4418A996AE30C227810021809A0@DLREXMBX01.intra.dlr.de> Updated patch for a problem with find_package(BLAS/LAPACK) on Windows for pure Fortran projects. Now simply uses CMAKE__COMPILER_LOADED... Regards, Melven -------------------------- Deutsches Zentrum f?r Luft- und Raumfahrt e.V. (DLR) German Aerospace Center Simulation and Software Technology | Linder Hoehe | 51147 Cologne | Germany Melven R?hrig-Z?llner Telephone +492203 / 601 - 2574 www.DLR.de -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-for-pure-Fortran-projects-with-BLAS-LAPACK-00160.patch Type: application/octet-stream Size: 4009 bytes Desc: 0001-Fix-for-pure-Fortran-projects-with-BLAS-LAPACK-00160.patch URL: From Melven.Roehrig-Zoellner at dlr.de Sun Apr 3 17:41:41 2016 From: Melven.Roehrig-Zoellner at dlr.de (Melven.Roehrig-Zoellner at dlr.de) Date: Sun, 3 Apr 2016 21:41:41 +0000 Subject: [cmake-developers] [PATCH] Fix CMAKE_Fortran_PLATFORM_ID on mingw-w64 Message-ID: <6CCDA91481A9E4418A996AE30C227810021809BF@DLREXMBX01.intra.dlr.de> Just use the existing fallback if CMAKE_Fortran_PLATFORM_ID is not detected. I hope this doesn't break any other compiler variants, but the compiler id and the platform id are needed... (so they are already half-broken if this patch changes their behavior, right?) Regards Melven -------------------------- Deutsches Zentrum f?r Luft- und Raumfahrt e.V. (DLR) German Aerospace Center Simulation and Software Technology | Linder Hoehe | 51147 Cologne | Germany Melven R?hrig-Z?llner Telephone +492203 / 601 - 2574 www.DLR.de -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-CMAKE_Fortran_PLATFORM_ID-e.g.-mingw-w64.patch Type: application/octet-stream Size: 1252 bytes Desc: 0002-Fix-CMAKE_Fortran_PLATFORM_ID-e.g.-mingw-w64.patch URL: From Melven.Roehrig-Zoellner at dlr.de Mon Apr 4 05:07:09 2016 From: Melven.Roehrig-Zoellner at dlr.de (Melven.Roehrig-Zoellner at dlr.de) Date: Mon, 4 Apr 2016 09:07:09 +0000 Subject: [cmake-developers] [PATCH] Fix CMAKE_Fortran_PLATFORM_ID on mingw-w64 Message-ID: <6CCDA91481A9E4418A996AE30C22781002180A3C@DLREXMBX01.intra.dlr.de> After thinking about my patch I worried it could break other compilers. So, here is a more defensive version that shouldn't interfere with anything else. Explanation: CMAKE_Fortran_COMPILER_ID was correctly set to "GNU"; If CMAKE_Fortran_PLATFORM_IS is missing, run gfortran with a C file -> fallback to C which has appropriate preprocessor definitions to recognize MINGW. Regards Melven -------------------------- Deutsches Zentrum f?r Luft- und Raumfahrt e.V. (DLR) German Aerospace Center Simulation and Software Technology | Linder Hoehe | 51147 Cologne | Germany Melven R?hrig-Z?llner Telephone +492203 / 601 - 2574 www.DLR.de -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-CMAKE_Fortran_PLATFORM_ID-e.g.-mingw-w64.patch Type: application/octet-stream Size: 1810 bytes Desc: 0002-Fix-CMAKE_Fortran_PLATFORM_ID-e.g.-mingw-w64.patch URL: From ben.boeckel at kitware.com Mon Apr 4 10:33:59 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 4 Apr 2016 10:33:59 -0400 Subject: [cmake-developers] [PATCH] Fix CMAKE_Fortran_PLATFORM_ID on mingw-w64 In-Reply-To: <6CCDA91481A9E4418A996AE30C22781002180A3C@DLREXMBX01.intra.dlr.de> References: <6CCDA91481A9E4418A996AE30C22781002180A3C@DLREXMBX01.intra.dlr.de> Message-ID: <20160404143359.GC6250@megas.khq.kitware.com> On Mon, Apr 04, 2016 at 09:07:09 +0000, Melven.Roehrig-Zoellner at dlr.de wrote: > After thinking about my patch I worried it could break other compilers. > So, here is a more defensive version that shouldn't interfere with anything else. > > Explanation: > CMAKE_Fortran_COMPILER_ID was correctly set to "GNU"; > If CMAKE_Fortran_PLATFORM_IS is missing, run gfortran with a C file > -> fallback to C which has appropriate preprocessor definitions to recognize MINGW. + exec_program(${CMAKE_Fortran_COMPILER} + ARGS ${CMAKE_Fortran_COMPILER_ID_FLAGS_LIST} -E +"\"${CMAKE_ROOT}/Modules/CMakeTestGNU.c\"" + OUTPUT_VARIABLE CMAKE_COMPILER_OUTPUT RETURN_VALUE +CMAKE_COMPILER_RETURN) Please use `execute_process` instead. + if(NOT CMAKE_COMPILER_RETURN) + if(NOT CMAKE_Fortran_PLATFORM_ID) Is this not always true inside this block? + if("${CMAKE_COMPILER_OUTPUT}" MATCHES "THIS_IS_MINGW") Use: if (CMAKE_COMPILER_OUTPUT MATCHES "THIS_IS_MINGW") + set(CMAKE_Fortran_PLATFORM_ID "MinGW") + endif() + if("${CMAKE_COMPILER_OUTPUT}" MATCHES "THIS_IS_CYGWIN") elseif? Similar transformation as above. + set(CMAKE_Fortran_PLATFORM_ID "Cygwin") + endif() + endif() + endif() --Ben From Dmitry.Ivanov at king.com Mon Apr 4 11:59:30 2016 From: Dmitry.Ivanov at king.com (Dmitry Ivanov) Date: Mon, 4 Apr 2016 15:59:30 +0000 Subject: [cmake-developers] ninja/make compilation response file Message-ID: Hi everyone, We have a strange situation where we do have too many include paths, which makes command line for obj compilation too long on windows (more 32kb). I've tried using set(CMAKE_NINJA_FORCE_RESPONSE_FILE 1), but apparently after checking cmake upstream I've realized that it's only implemented for linking, and not compilation. What we should do (other than fixing "the problem" with too many paths) ? Would be nice to have this feature working for makefiles and ninja. PS. Can we do something about bloated cmake ninja generator ? in our case cmake generates 1.8 Mb Makefile and 84 Mb build.ninja, though ninja is still faster than make even in this case. Best, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Mon Apr 4 12:38:39 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 4 Apr 2016 18:38:39 +0200 Subject: [cmake-developers] ninja/make compilation response file In-Reply-To: References: Message-ID: <5702988F.2000408@gmail.com> On 04.04.2016 17:59, Dmitry Ivanov wrote: > > PS. Can we do something about bloated cmake ninja generator ? in our > case cmake generates 1.8 Mb Makefile and 84 Mb build.ninja, though > ninja is still faster than make even in this case. > Curious. Did you count the accumulative size of all Makefile and Makefile2 files (also in sub-directories)? For a project of mine the ninja files are only half in size of what is generated for the Makefile generator (CMake 3.5.1). Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Mon Apr 4 12:56:50 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 4 Apr 2016 18:56:50 +0200 Subject: [cmake-developers] ninja/make compilation response file In-Reply-To: <5702988F.2000408@gmail.com> References: <5702988F.2000408@gmail.com> Message-ID: <57029CD2.2020105@gmail.com> On 04.04.2016 18:38, Nils Gladitz wrote: > On 04.04.2016 17:59, Dmitry Ivanov wrote: >> >> PS. Can we do something about bloated cmake ninja generator ? in our >> case cmake generates 1.8 Mb Makefile and 84 Mb build.ninja, though >> ninja is still faster than make even in this case. >> > > Curious. Did you count the accumulative size of all Makefile and > Makefile2 files (also in sub-directories)? > For a project of mine the ninja files are only half in size of what is > generated for the Makefile generator (CMake 3.5.1). Oh and the Makefile generator also uses build.make files which actually seem to be where most of the size goes. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Apr 4 13:01:02 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 4 Apr 2016 13:01:02 -0400 Subject: [cmake-developers] ninja/make compilation response file In-Reply-To: References: Message-ID: <20160404170102.GA878@megas.khq.kitware.com> On Mon, Apr 04, 2016 at 15:59:30 +0000, Dmitry Ivanov wrote: > We have a strange situation where we do have too many include paths, > which makes command line for obj compilation too long on windows (more > 32kb). > I've tried using set(CMAKE_NINJA_FORCE_RESPONSE_FILE 1), but > apparently after checking cmake upstream I've realized that it's only > implemented for linking, and not compilation. Hmm. I know that RC compilation doesn't support response files (though the rc compiler does on Windows). Haven't had a problem with source compilation though (and I've had to deal with *long* paths before). > What we should do (other than fixing "the problem" with too many > paths) ? Would be nice to have this feature working for makefiles and > ninja. Teaching the Ninja generator about response files for object file compilation would be the way to go (and support for RC as well would be good since the logic is likely the same). > PS. Can we do something about bloated cmake ninja generator ? in our > case cmake generates 1.8 Mb Makefile and 84 Mb build.ninja, though > ninja is still faster than make even in this case. There was work to reduce the size of the generated build.ninja file. More work could be done, but the projects I was looking at would only get marginal improvements from other techniques (though other projects with different flag quantities might show other things to improve). What version of CMake are you using? --Ben From manyoso at yahoo.com Mon Apr 4 16:08:10 2016 From: manyoso at yahoo.com (Adam Treat) Date: Mon, 4 Apr 2016 20:08:10 +0000 (UTC) Subject: [cmake-developers] for C# language support References: <489694366.2732639.1459800490966.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <489694366.2732639.1459800490966.JavaMail.yahoo@mail.yahoo.com> Hello, I have been working on improving the cmake language module for C# found here: https://github.com/awakecoding/CMakeSharp One thing that has me a bit flummoxed is how to implement the following: CMAKE_CSharp_CREATE_SHARED_LIBRARY CMAKE_CSharp_CREATE_SHARED_MODULE CMAKE_CSharp_CREATE_STATIC_LIBRARY in CMakeCSharpInformation.cmake. In C# libraries need to have all symbols resolved at creation time just like executables and this means I need access to the LINK_LIBRARIES property to correctly implement the above. However, it seems this property is empty for the above. Any suggestions? Adam From Melven.Roehrig-Zoellner at dlr.de Tue Apr 5 04:48:41 2016 From: Melven.Roehrig-Zoellner at dlr.de (Melven.Roehrig-Zoellner at dlr.de) Date: Tue, 5 Apr 2016 08:48:41 +0000 Subject: [cmake-developers] [PATCH] Fix CMAKE_Fortran_PLATFORM_ID on mingw-w64 Message-ID: <6CCDA91481A9E4418A996AE30C22781002180C2E@DLREXMBX01.intra.dlr.de> Requested changes from Ben Boeckel, also adjusted the similar if("${...}" MATCHES ...) statements in the section above. Regards Melven -------------------------- Deutsches Zentrum f?r Luft- und Raumfahrt e.V. (DLR) German Aerospace Center Simulation and Software Technology | Linder Hoehe | 51147 Cologne | Germany Melven R?hrig-Z?llner Telephone +492203 / 601 - 2574 www.DLR.de -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-CMAKE_Fortran_PLATFORM_ID-e.g.-mingw-w64.patch Type: application/octet-stream Size: 3202 bytes Desc: 0002-Fix-CMAKE_Fortran_PLATFORM_ID-e.g.-mingw-w64.patch URL: From Dmitry.Ivanov at king.com Tue Apr 5 08:03:59 2016 From: Dmitry.Ivanov at king.com (Dmitry Ivanov) Date: Tue, 5 Apr 2016 12:03:59 +0000 Subject: [cmake-developers] ninja/make compilation response file In-Reply-To: <57029CD2.2020105@gmail.com> References: <5702988F.2000408@gmail.com> <57029CD2.2020105@gmail.com> Message-ID: Just checked the size that we are getting, it's 20 Mb for all Makefile and *.make combined, and 84 mb build.ninja From: Nils Gladitz [mailto:nilsgladitz at gmail.com] Sent: Monday, April 4, 2016 18:57 To: Dmitry Ivanov ; cmake-developers at cmake.org Subject: Re: [cmake-developers] ninja/make compilation response file On 04.04.2016 18:38, Nils Gladitz wrote: On 04.04.2016 17:59, Dmitry Ivanov wrote: PS. Can we do something about bloated cmake ninja generator ? in our case cmake generates 1.8 Mb Makefile and 84 Mb build.ninja, though ninja is still faster than make even in this case. Curious. Did you count the accumulative size of all Makefile and Makefile2 files (also in sub-directories)? For a project of mine the ninja files are only half in size of what is generated for the Makefile generator (CMake 3.5.1). Oh and the Makefile generator also uses build.make files which actually seem to be where most of the size goes. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dmitry.Ivanov at king.com Tue Apr 5 08:07:12 2016 From: Dmitry.Ivanov at king.com (Dmitry Ivanov) Date: Tue, 5 Apr 2016 12:07:12 +0000 Subject: [cmake-developers] ninja/make compilation response file In-Reply-To: <20160404170102.GA878@megas.khq.kitware.com> References: <20160404170102.GA878@megas.khq.kitware.com> Message-ID: >Teaching the Ninja generator about response files for object file compilation would be the way to go (and support for RC as well would be good since the logic is likely the same). I will time box it and see if I can do it in few days, if not we need to figure out if it can be done like a sponsored feature or something. Actually same story with make file generators, doesn't look like they support response files for obj either. >There was work to reduce the size of the generated build.ninja file. >More work could be done, but the projects I was looking at would only get marginal improvements from other techniques (though other projects with different flag quantities might >show other things to improve). What version of CMake are you using? 3.5.1 atm, 84 mb takes around 3-4 seconds for ninja to parse on my machine, which makes ninja slightly useless an fast incremental builds tool, which is a shame. --Ben From brad.king at kitware.com Tue Apr 5 10:03:16 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 5 Apr 2016 10:03:16 -0400 Subject: [cmake-developers] CMake API for warnings In-Reply-To: <56FD5488.9010706@yahoo.com> References: <56F85BE4.2070503@yahoo.com> <56F93A40.8090904@kitware.com> <56FA7E9A.7020704@yahoo.com> <56FA9014.70106@kitware.com> <56FA9E26.2090704@yahoo.com> <56FD2835.60301@kitware.com> <56FD5488.9010706@yahoo.com> Message-ID: <5703C5A4.6090506@kitware.com> On 03/31/2016 12:47 PM, Ruslan Baratov wrote: > What about 3 properties containing list of 's (groups > unexpanded): > > * COMPILE_WARNINGS_DISABLE # e.g. "shift-sign-overflow;unused" > * COMPILE_WARNINGS_ENABLE # e.g. "ALL" > * COMPILE_WARNINGS_TREAT_AS_ERROR # e.g. group + specific: "inline;undef" We would need to define behavior when a warning appears in more than one list. Perhaps we need to define some kind of `=on/off/error/no-error` syntax for each list entry. The name "ALL" may not be representative. Even -Wall does not really enable all possible warnings on some compilers. I'd like to find another name that captures the idea of enabling most warnings. Or we could try to subsume it into an interface for the warning level, with -Wall considered "high". > I'm not sure about mixing more languages. I think it will be similar to > COMPILE_OPTIONS (?), see no language specification in > `add_compile_options` command. Right. We do have the COMPILE_LANGUAGE genex for some limited use cases. Its documentation even includes a COMPILE_OPTIONS example. However, it also documents that it is not possible to implement fully on VS IDE generators. For example, VS does not distinguish between C and C++ flags. The same set is always used for both. Another option is to have the warning names themselves have a language in them, similar to the COMPILE_FEATURES names. -Brad From brad.king at kitware.com Tue Apr 5 10:03:20 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 5 Apr 2016 10:03:20 -0400 Subject: [cmake-developers] for C# language support In-Reply-To: <489694366.2732639.1459800490966.JavaMail.yahoo@mail.yahoo.com> References: <489694366.2732639.1459800490966.JavaMail.yahoo.ref@mail.yahoo.com> <489694366.2732639.1459800490966.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5703C5A8.6030903@kitware.com> On 04/04/2016 04:08 PM, Adam Treat via cmake-developers wrote: > I have been working on improving the cmake language module for C# found here: Thanks for working on this. I'm adding Michael Stuermer to Cc who has been working on support in the VS IDE generators: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15753/focus=16064 > One thing that has me a bit flummoxed is how to implement the following: > > CMAKE_CSharp_CREATE_SHARED_LIBRARY > CMAKE_CSharp_CREATE_SHARED_MODULE > CMAKE_CSharp_CREATE_STATIC_LIBRARY > > in CMakeCSharpInformation.cmake. In C# libraries need to have all symbols resolved > at creation time just like executables and this means I need access to the LINK_LIBRARIES > property to correctly implement the above. However, it seems this property is empty > for the above. It is expected to be available for at least the shared/module link rules. See cmMakefileTargetGenerator::CreateLinkLibs's implementation and its call sites. Also see cmLocalGenerator::ExpandRuleVariable for where the placeholders like get expanded. -Brad From brad.king at kitware.com Tue Apr 5 10:03:27 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 5 Apr 2016 10:03:27 -0400 Subject: [cmake-developers] [PATCH] Fix CMAKE_Fortran_PLATFORM_ID on mingw-w64 In-Reply-To: <6CCDA91481A9E4418A996AE30C22781002180C2E@DLREXMBX01.intra.dlr.de> References: <6CCDA91481A9E4418A996AE30C22781002180C2E@DLREXMBX01.intra.dlr.de> Message-ID: <5703C5AF.2090806@kitware.com> On 04/05/2016 04:48 AM, Melven.Roehrig-Zoellner at dlr.de wrote: > Requested changes from Ben Boeckel, > also adjusted the similar if("${...}" MATCHES ...) statements in the section above. Thanks. Applied: CMakeDetermineFortranCompiler: Modernize conventions https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=66fa6143 Fortran: Fix platform id detection on mingw-w64 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c4f100a -Brad From brad.king at kitware.com Tue Apr 5 10:03:33 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 5 Apr 2016 10:03:33 -0400 Subject: [cmake-developers] [PATCH v2] language detection in FindBLAS and FindLAPACK (#0016039) In-Reply-To: <6CCDA91481A9E4418A996AE30C227810021809A0@DLREXMBX01.intra.dlr.de> References: <6CCDA91481A9E4418A996AE30C227810021809A0@DLREXMBX01.intra.dlr.de> Message-ID: <5703C5B5.3090309@kitware.com> On 04/03/2016 05:21 PM, Melven.Roehrig-Zoellner at dlr.de wrote: > Updated patch for a problem with find_package(BLAS/LAPACK) > on Windows for pure Fortran projects. > Now simply uses CMAKE__COMPILER_LOADED... Thanks! Applied: Find{BLAS,LAPACK}: Fix when used in pure Fortran projects (#16039) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1694112d -Brad From ruslan_baratov at yahoo.com Tue Apr 5 14:03:56 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 6 Apr 2016 01:03:56 +0700 Subject: [cmake-developers] CMake API for warnings In-Reply-To: <5703C5A4.6090506@kitware.com> References: <56F85BE4.2070503@yahoo.com> <56F93A40.8090904@kitware.com> <56FA7E9A.7020704@yahoo.com> <56FA9014.70106@kitware.com> <56FA9E26.2090704@yahoo.com> <56FD2835.60301@kitware.com> <56FD5488.9010706@yahoo.com> <5703C5A4.6090506@kitware.com> Message-ID: <5703FE0C.5060401@yahoo.com> On 05-Apr-16 21:03, Brad King wrote: > On 03/31/2016 12:47 PM, Ruslan Baratov wrote: >> What about 3 properties containing list of 's (groups >> unexpanded): >> >> * COMPILE_WARNINGS_DISABLE # e.g. "shift-sign-overflow;unused" >> * COMPILE_WARNINGS_ENABLE # e.g. "ALL" >> * COMPILE_WARNINGS_TREAT_AS_ERROR # e.g. group + specific: "inline;undef" > We would need to define behavior when a warning appears in more than > one list. Report an error in case of any type of conflicts. It may happens not only when same type appears in both DISABLE and ENABLE but for example when warning already defined by some group. E.g. "EVERYTHING;undef" is the same as "EVERYTHING". If user okay with having intersections (for any reason) new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may control this. > Perhaps we need to define some kind of `=on/off/error/no-error` > syntax for each list entry. You mean this: compatibility-c++98=off inline=off special-members=off catch-semantic-changed=off covered-switch-default=off inherits-via-dominance=off name-length-exceeded=off padded=off this-used-in-init=off EVERYTHING=on EVERYTHING=error versus this one: DISABLE compatibility-c++98 inline special-members catch-semantic-changed covered-switch-default inherits-via-dominance name-length-exceeded padded this-used-in-init ENABLE EVERYTHING TREAT_AS_ERROR EVERYTHING ? Second variant looks clearer for me. > > The name "ALL" may not be representative. Even -Wall does not really enable > all possible warnings on some compilers. I'd like to find another name that > captures the idea of enabling most warnings. Or we could try to subsume it > into an interface for the warning level, with -Wall considered "high". Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET? > >> I'm not sure about mixing more languages. I think it will be similar to >> COMPILE_OPTIONS (?), see no language specification in >> `add_compile_options` command. > Right. We do have the COMPILE_LANGUAGE genex for some limited use cases. > Its documentation even includes a COMPILE_OPTIONS example. However, it > also documents that it is not possible to implement fully on VS IDE > generators. For example, VS does not distinguish between C and C++ > flags. The same set is always used for both. Since /Wall can be set by 'target_compile_options' then abstracting it by `target_compile_warnings(... ENABLE ALL)` should not be a problem I think. > > Another option is to have the warning names themselves have a language > in them, similar to the COMPILE_FEATURES names. See no point of this one. So say we have switch-enum warning which is only for C++, why do we need cxx-switch-enum? There is no c-switch-enum or any other *-switch-enum. If we are talking about 'undef' why do we need c-undef and cxx-undef? It mean the same and I think will be set or unset simultaneously. Ruslo From mantis at public.kitware.com Tue Apr 5 14:49:23 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 5 Apr 2016 14:49:23 -0400 Subject: [cmake-developers] [CMake 0016049]: Resources generated with autorcc are always rebuilt using ninja Message-ID: <849254914e9b71effeb4257965f5204c@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=16049 ====================================================================== Reported By: Vidar Meland ?deg?rd Assigned To: ====================================================================== Project: CMake Issue ID: 16049 Category: CMake Reproducibility: always Severity: minor Priority: high Status: new ====================================================================== Date Submitted: 2016-04-05 14:49 EDT Last Modified: 2016-04-05 14:49 EDT ====================================================================== Summary: Resources generated with autorcc are always rebuilt using ninja Description: By using ninja and autorcc the resources are always rebuilt on CMake >= 3.5. CMake 3.4.3 does not have this issue. Steps to Reproduce: cmake -GNinja ninja -v ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-05 14:49 Vidar Meland ?deg?rdNew Issue 2016-04-05 14:49 Vidar Meland ?deg?rdFile Added: bug.tar.gz ====================================================================== From mantis at public.kitware.com Wed Apr 6 03:41:27 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 6 Apr 2016 03:41:27 -0400 Subject: [cmake-developers] [CMake 0016050]: Missing source files generate broken Makefiles (NMake) Message-ID: <0035449fc39b73abd573cbcecf00ae3f@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=16050 ====================================================================== Reported By: Llu?s Batlle Assigned To: ====================================================================== Project: CMake Issue ID: 16050 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-06 03:41 EDT Last Modified: 2016-04-06 03:41 EDT ====================================================================== Summary: Missing source files generate broken Makefiles (NMake) Description: Using the "NMake Makefiles" and "NMake Makefiles JOM" generate broken makefiles, in case that one source file of ADD_EXECUTABLE is missing. Steps to Reproduce: In my case, I have something like: ADD_EXECUTABLE(program WIN32 src1.cpp src1.hpp help.h) TARGET_LINK_LIBRARIES(program lib1 lib2) Running "cmake -G 'NMake Makefiles'" (or JOM) it reports properly: CMake Error at CMakeLists.txt:57 (ADD_EXECUTABLE): Cannot find source file: F:/projects/prog/build/help.h But then I can type "nmake program", and it goes on building lib1 and lib2, and then it tries to link program with the libs without any object files. It does not compile any "program" source files. Of course the linker reports missing _WinMainCRTStartup. Additional Information: If I use the ninja generator, it works fine. When trying to run "ninja program", it tries to run cmake again, and it fails because of the missing source file. NMake should also do the same: run cmake again, to see if the CMakeLists.txt has been fixed and all sources are found. I had missed the "CMake Error" line when using NMake, and I spent time trying to find out the sudden miss of the _WinMainCRTStartup symbol. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-06 03:41 Llu?s Batlle New Issue ====================================================================== From jeanmichael.celerier at gmail.com Wed Apr 6 04:48:41 2016 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Wed, 6 Apr 2016 10:48:41 +0200 Subject: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation In-Reply-To: References: <05a801d112d6$9b2e2910$d18a7b30$@codenest.com> Message-ID: Hi, could you give a try to the branch ? :) Jean-Micha?l Celerier On Sat, Dec 5, 2015 at 1:39 PM, David Cole via cmake-developers < cmake-developers at cmake.org> wrote: > Yes, that looks like it should work. I'll pull your branch and give it a > try sometime in the coming week. > > Thanks, > David > > On Friday, December 4, 2015, Daniel Pfeifer > wrote: > >> On Fri, Dec 4, 2015 at 11:32 PM, David Cole wrote: >> > Makes sense. >> > >> > Can I inject my own "#include " into >> > the generated stream, or otherwise inject something into it? >> >> You should be able to do: >> >> target_include_directories(your_target >> PUBLIC public >> PRIVATE private >> ) >> target_precompile_headers(your_target >> PUBLIC >> public_header1.h >> public_header2.h >> PRIVATE >> private_header1.h >> private_header2.h >> ) >> >> Does that answer your question? Do you think this could solve your >> use-case? >> >> > Specifically, for me, I want to include some, but not ALL VTK headers >> > for a VTK-based project. >> >> I don't see a problem for that. >> >> > Thanks for working on this. >> >> You are welcome. :-) >> >> > Let me know if you want me to be a Visual Studio tester for you. >> >> Yes, please. My main working environment is Linux. I appreciate any >> feedback from different platforms. >> > > -- > > 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 yves.frederix+cmake at gmail.com Wed Apr 6 04:51:11 2016 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Wed, 6 Apr 2016 10:51:11 +0200 Subject: [cmake-developers] [CMake] add_custom_command() OUTPUT does not accept generator expressions, why? In-Reply-To: <56FD2894.6070506@kitware.com> References: <56F93A2D.9090809@kitware.com> <56FD2894.6070506@kitware.com> Message-ID: Hi Brad, Thanks for the pointers. I played with this a bit over the last week, mainly to get familiar with the CMake internals, and it seems that there are some things that might need discussion before getting to a solution. Note that all my experiments were done using the VS generator. What we basically want to be able to do is something like: # Create any library. add_library(test_lib STATIC existing_file.cpp) # Generate a file in the same directory as the test_lib library was created. add_custom_target(test_target ALL SOURCES $/generated_file.cpp) add_custom_command( OUTPUT $/generated_file.cpp COMMAND cmake -E touch "$/generated_file.cpp" ) Without generator expressions, this works nicely. However, if CMake were to correctly interpret generator expressions in OUTPUT, then the corresponding source file would be $/generated_file.cpp in add_custom_target, which in turn, for a multiconfig generator would contain the configuration in its path. So, basically, a prerequisite for the above to work is that CMake behaves nicely for the following as well: add_library(test_lib STATIC existing_file_$.cpp) At this moment CMake supports generator expressions in the source list, so this "should" work. It does not in practice, however: CMake Error in CMakeLists.txt: Target "test_target" has source files which vary by configuration. This is not supported by the "Visual Studio 14 2015" generator. Intuitively I understand why this is not supported (different configurations share the same project file in VS, so which source file would the project point to?) Is this also a technical limitation though? Or do VS project files (and other multiconfig generator project files such as xcode) support this setup but was it merely not implemented yet? Yves On Thu, Mar 31, 2016 at 3:39 PM, Brad King wrote: > On 03/31/2016 07:26 AM, Yves Frederix wrote: >>> If anyone is interested in trying to implement generator expressions >>> for custom command outputs, I can provide more details to get started. >> >> I am interested in having a go at this. I recently ran into this issue >> at work as well and actually tried some things already. However, I >> realized it was not that straightforward (not even talking about doing >> it 'right' here ;)). Any pointers are welcome! > > Thanks! > > The main challenge is shown in the cmTargetTraceDependencies::FollowName > method where it calls cmMakefile::GetSourceFileWithOutput. This logic > is done without knowledge of the current configuration. Therefore we > cannot expand generator expressions of the available outputs because > they may contain $. Some table of pre-expanded per-config > outputs mapping back to their cmSourceFile instances may need to be > built. Achieving this may even require adding a generate-time > companion of cmSourceFile that knows its configuration. It will need > to be investigated further. > > cmTargetTraceDependencies::CheckCustomCommand currently has a loop > over all configurations to generate the union of dependencies. This > is used to allow generator expressions in the DEPENDS option. > The cmTargetTraceDependencies logic may need to be refactored to move > the loop over the configurations out to a higher level. We may need > to trace dependencies separately for each configuration (for multi- > config generators). > > Also see cmCustomCommandGenerator. The generators will need to > be adapted to use this to get the custom command outputs with > generator expressions expanded. They already do for the commands > and dependencies. > > -Brad From petr.kmoch at gmail.com Wed Apr 6 08:02:07 2016 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 6 Apr 2016 13:02:07 +0100 Subject: [cmake-developers] [CMake] add_custom_command() OUTPUT does not accept generator expressions, why? In-Reply-To: References: <56F93A2D.9090809@kitware.com> <56FD2894.6070506@kitware.com> Message-ID: On 6 April 2016 at 09:51, Yves Frederix wrote: > [...] > So, basically, a prerequisite for the above > to work is that CMake behaves nicely for the following as well: > > add_library(test_lib STATIC existing_file_$.cpp) > > At this moment CMake supports generator expressions in the source > list, so this "should" work. It does not in practice, however: > > CMake Error in CMakeLists.txt: > Target "test_target" has source files which vary by configuration. > This is > not supported by the "Visual Studio 14 2015" generator. > > Intuitively I understand why this is not supported (different > configurations share the same project file in VS, so which source file > would the project point to?) Is this also a technical limitation > though? Or do VS project files (and other multiconfig generator > project files such as xcode) support this setup but was it merely not > implemented yet? > I don't know anything about XCode, unfortunately. However, Visual Studio definitely supports a form of varying the source file list of the project between configurations. That's because a source file can be marked as _excluded_ from build for a particular configuration. So the solution CMake could use would be to add all source files from all configurations into the project, but mark them as excluded from [in]appropriate configurations. Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Apr 6 08:46:55 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 6 Apr 2016 08:46:55 -0400 Subject: [cmake-developers] [CMake] add_custom_command() OUTPUT does not accept generator expressions, why? In-Reply-To: References: <56F93A2D.9090809@kitware.com> <56FD2894.6070506@kitware.com> Message-ID: <5705053F.7070509@kitware.com> On 04/06/2016 08:02 AM, Petr Kmoch wrote: > On 6 April 2016 at 09:51, Yves Frederix wrote: >> add_custom_target(test_target ALL SOURCES $/generated_file.cpp) Watch out for circular logic here. For example: add_library(test_lib STATIC $/generated_file.cpp) add_custom_command(OUTPUT $/generated_file.cpp ...) When we compute the output information like target file directory and target file name we need to also determine the linker language. For that we need the full list of source files to infer the language. If that list of sources uses generator expressions that refer back to the location of the target itself then we have a circular dependency in the computation. This will have to be diagnosed and rejected. >> Target "test_target" has source files which vary by configuration. This is >> not supported by the "Visual Studio 14 2015" generator. >> >> Intuitively I understand why this is not supported (different >> configurations share the same project file in VS, so which source file >> would the project point to?) Is this also a technical limitation >> though? Or do VS project files (and other multiconfig generator >> project files such as xcode) support this setup but was it merely not >> implemented yet? > > I don't know anything about XCode, unfortunately. However, Visual Studio > definitely supports a form of varying the source file list of the project > between configurations. That's because a source file can be marked as > _excluded_ from build for a particular configuration. So the solution > CMake could use would be to add all source files from all configurations > into the project, but mark them as excluded from [in]appropriate configurations. The current limitation is mostly because no one has thoroughly investigated how to support it in VS IDE projects. If there is an approach that will work then we'd be happy to see it implemented. Similarly for Xcode. A fallback approach could be to generate a wrapper source file that uses the preprocessor to conditionally include the real per-config source file based on the configuration. -Brad From mantis at public.kitware.com Wed Apr 6 09:46:59 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 6 Apr 2016 09:46:59 -0400 Subject: [cmake-developers] [CMake 0016051]: Incorrect archive generated with CPACK_ARCHIVE_COMPONENT_INSTALL=ON with non-empty directory behind a symlink Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=16051 ====================================================================== Reported By: benoit.barbier Assigned To: ====================================================================== Project: CMake Issue ID: 16051 Category: CPack Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2016-04-06 09:46 EDT Last Modified: 2016-04-06 09:46 EDT ====================================================================== Summary: Incorrect archive generated with CPACK_ARCHIVE_COMPONENT_INSTALL=ON with non-empty directory behind a symlink Description: cmake_minimum_required(VERSION 3.0.0) # generate files & folders make_directory(${CMAKE_CURRENT_BINARY_DIR}/sample) FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/sample/dummy.txt "") execute_process( COMMAND mkdir folder COMMAND ln -s folder alias WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/sample) FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/sample/folder/file.txt "") # install 2 different components install(FILES ${CMAKE_CURRENT_BINARY_DIR}/sample/dummy.txt DESTINATION "." COMPONENT cmp1) install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/sample/alias DESTINATION "." COMPONENT cmp2) install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/sample/folder DESTINATION "." COMPONENT cmp2) set(CPACK_ARCHIVE_COMPONENT_INSTALL ON) include(cpack) ======================= Run cmake, then cpack -G TGZ or ZIP. Open the archive of the second component (cmp2), and you get an error: >> unzip Project-0.1.1-Darwin-cmp2.zip " Archive: Project-0.1.1-Darwin-cmp2.zip linking: alias -> folder checkdir error: alias exists but is not directory unable to process alias/dummy.txt. creating: folder/ inflating: folder/dummy.txt finishing deferred symbolic links: alias -> folder " ======================= This append only if you specify CPACK_ARCHIVE_COMPONENT_INSTALL= ON and there is a file created into the folder (folder/file.txt). If the folder is empty, no error are generated by the unzip. Seems to be appear when this feature have been introduced in CPack (cmake 3.4 release notes) : The CPack module learned to package empty directories. Often append if you package a bundle with frameworks... ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-06 09:46 benoit.barbier New Issue ====================================================================== From yves.frederix+cmake at gmail.com Wed Apr 6 09:59:24 2016 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Wed, 6 Apr 2016 15:59:24 +0200 Subject: [cmake-developers] [CMake] add_custom_command() OUTPUT does not accept generator expressions, why? In-Reply-To: <5705053F.7070509@kitware.com> References: <56F93A2D.9090809@kitware.com> <56FD2894.6070506@kitware.com> <5705053F.7070509@kitware.com> Message-ID: > add_library(test_lib STATIC $/generated_file.cpp) > add_custom_command(OUTPUT $/generated_file.cpp ...) > > When we compute the output information like target file directory and > target file name we need to also determine the linker language. For > that we need the full list of source files to infer the language. If > that list of sources uses generator expressions that refer back to the > location of the target itself then we have a circular dependency in the > computation. This will have to be diagnosed and rejected. Yes, agree. Or alternatively, document that source files that contain generator expressions are not taken into account during automatic linker language computation? In this case, you would need to set it manually if this particular source file would make a difference. >> I don't know anything about XCode, unfortunately. However, Visual Studio >> definitely supports a form of varying the source file list of the project >> between configurations. That's because a source file can be marked as >> _excluded_ from build for a particular configuration. So the solution >> CMake could use would be to add all source files from all configurations >> into the project, but mark them as excluded from [in]appropriate configurations. > > The current limitation is mostly because no one has thoroughly > investigated how to support it in VS IDE projects. If there is an > approach that will work then we'd be happy to see it implemented. > Similarly for Xcode. In order to implement this, CMake should be able to determine if the result of resolving a generator expression depends on the configuration or not. Does the generator expression logic currently allow such check? I did see cmGeneratorExpression::GetHadContextSensitiveCondition(), but I have the feeling it does not really do exactly that. > A fallback approach could be to generate a wrapper source file > that uses the preprocessor to conditionally include the real > per-config source file based on the configuration. That would be an option as well. I suspect best by using the CMAKE_INTDIR preprocessor define? Yves From brad.king at kitware.com Wed Apr 6 10:12:33 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 6 Apr 2016 10:12:33 -0400 Subject: [cmake-developers] [CMake] add_custom_command() OUTPUT does not accept generator expressions, why? In-Reply-To: References: <56F93A2D.9090809@kitware.com> <56FD2894.6070506@kitware.com> <5705053F.7070509@kitware.com> Message-ID: <57051951.4060006@kitware.com> On 04/06/2016 09:59 AM, Yves Frederix wrote: > In order to implement this, CMake should be able to determine if the > result of resolving a generator expression depends on the > configuration or not. Not necessarily. It can simply evaluate it with each configuration to be generated and the result for each compared. Build a list of sources with per-configuration activation marks. Use that to do the actual generation. This intermediate list/set/map may be needed internally to do post-genex/per-config source file lookup anyway. > Does the generator expression logic currently allow such check? I don't remember ;) >> A fallback approach could be to generate a wrapper source file >> that uses the preprocessor to conditionally include the real >> per-config source file based on the configuration. > > That would be an option as well. I suspect best by using the > CMAKE_INTDIR preprocessor define? No, that just defines a string literal that we can't switch off. I think it would be a source-specific generated macro name. -Brad From brad.king at kitware.com Wed Apr 6 16:52:25 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 6 Apr 2016 16:52:25 -0400 Subject: [cmake-developers] [PATCH v2] ExternalProject: Allow TLS_VERIFY for git clones In-Reply-To: <20160401171803.GA6250@megas.khq.kitware.com> References: <1459521566-11239-1-git-send-email-me@rmz.io> <20160401171803.GA6250@megas.khq.kitware.com> Message-ID: <57057709.4040202@kitware.com> On 04/01/2016 01:18 PM, Ben Boeckel wrote: > On Fri, Apr 01, 2016 at 15:39:26 +0100, Samir Benmendil wrote: >> Use the git config `http.sslVerify=false` to disable strict ssl for git >> commands. > > I've pushed this into next for testing. FYI, the patch is now in 'master'. However, I since realized that it changes default behavior to TLS_VERIFY=OFF. I've restored the default behavior: ExternalProject: Tell Git not to verify certs only if TLS_VERIFY is OFF https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23a71e4e Now an explicit "TLS_VERIFY OFF" or setting CMAKE_TLS_VERIFY to "OFF" will disable it but otherwise no special option will be passed to `git clone`. -Brad From tamas.kenez at gmail.com Thu Apr 7 10:03:12 2016 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Thu, 7 Apr 2016 16:03:12 +0200 Subject: [cmake-developers] -isystem suppresses warnings from user header Message-ID: Environment: CMake 3.5, linux, g++ CMake uses "-isystem" on the compiler command line for the INTERFACE_INCLUDE_DIRECTORIES of imported libraries. Unfortunately including a header via an isystem path suppresses warnings emitted from the header, such as warnings caused by expansions of macros defined in that header. Example: I have a printf-like LOG(...) macro which expands to a function marked as printf-like. The -Wformat warnings are suppressed if the containing log.h is found on isystem path. Question: is this the intended behaviour? Can I force the -I flag somehow for my library? (I'm aware of CMAKE_INCLUDE_SYSTEM_FLAG_CXX but I don't want to modify all the client projects that uses my library.) Or is it bug? Thanks, Tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Apr 7 10:13:58 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 7 Apr 2016 10:13:58 -0400 Subject: [cmake-developers] -isystem suppresses warnings from user header In-Reply-To: References: Message-ID: <57066B26.6090009@kitware.com> On 04/07/2016 10:03 AM, Tam?s Ken?z wrote: > CMake uses "-isystem" on the compiler command line for the > INTERFACE_INCLUDE_DIRECTORIES of imported libraries. > > Question: is this the intended behaviour? Yes. See discussion here: * http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7533 and implementation here: * Always consider includes from IMPORTED targets to be SYSTEM. https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a63fcbcb > Can I force the -I flag somehow for my library? Look at these: * https://cmake.org/cmake/help/v3.5/variable/CMAKE_NO_SYSTEM_FROM_IMPORTED.html * https://cmake.org/cmake/help/v3.5/prop_tgt/NO_SYSTEM_FROM_IMPORTED.html -Brad From mantis at public.kitware.com Thu Apr 7 10:36:26 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 7 Apr 2016 10:36:26 -0400 Subject: [cmake-developers] [CMake 0016052]: Extra space on NDEBUG in release builds causes flag to be ignored Message-ID: <05b23a454ea1d8f86d84b3f838b26bf6@kwwidgets.org> The following issue has been SUBMITTED. ====================================================================== http://kwwidgets.org/Bug/view.php?id=16052 ====================================================================== Reported By: Stephen Dunn Assigned To: ====================================================================== Project: CMake Issue ID: 16052 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-07 10:36 EDT Last Modified: 2016-04-07 10:36 EDT ====================================================================== Summary: Extra space on NDEBUG in release builds causes flag to be ignored Description: This bug was previously reported, but incorrectly marked as resolved here: http://kwwidgets.org/Bug/view.php?id=1749 All Release mode configs accidentally append a space after /D in Visual Studio 2015 (14) which causes the flag NDEBUG to be ignored. It should be: /DNDEBUG, not /D NDEBUG which is invalid syntax. Other /D flags are defined correctly. I check for the presence of this var, and its absence in Release mode causes undefined behavior. Steps to Reproduce: Generate any project with Release mode builds. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-07 10:36 Stephen Dunn New Issue 2016-04-07 10:36 Stephen Dunn File Added: cmake-bug.png ====================================================================== From mantis at public.kitware.com Thu Apr 7 11:26:22 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 7 Apr 2016 11:26:22 -0400 Subject: [cmake-developers] [CMake 0016053]: $ should return a short path on Windows when containing spaces Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16053 ====================================================================== Reported By: Guillaume Dumont Assigned To: ====================================================================== Project: CMake Issue ID: 16053 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-07 11:26 EDT Last Modified: 2016-04-07 11:26 EDT ====================================================================== Summary: $ should return a short path on Windows when containing spaces Description: I am trying to build OpenCV from sources using MSVC and the Ninja Generator and I have a failing build because of linker flags added to the target_link_libraries. OpenCV's CMakeLists.txt uses this line of CMake code: set(OPENCV_LINKER_LIBS ${OPENCV_LINKER_LIBS} -L${p}) OPENCV_LINKER_LIBS is passed to target_link_libraries afterwards. The problem with this line is that it does not work on Windows with the Ninja generator. I tried: set(OPENCV_LINKER_LIBS ${OPENCV_LINKER_LIBS} ${CMAKE_LIBRARY_PATH_FLAG}$) but that does not work either because the even though we end up using /LIBPATH: instead of /L and backslashes instead of forward slashes the path contains spaces and ninja throws a link error. Shouldn't SHELL_PATH return a short path, or a path between quotes when the path contains spaces on Windows? Steps to Reproduce: Try to build OpenCV 3.1.0 on Windows with Ninja. Additional Information: See OpenCV issue: https://github.com/Itseez/opencv/issues/6372 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-07 11:26 Guillaume DumontNew Issue ====================================================================== From mantis at public.kitware.com Thu Apr 7 16:53:42 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 7 Apr 2016 16:53:42 -0400 Subject: [cmake-developers] [CMake 0016054]: Cannot override CMAKE_{C, CXX}_FLAGS* to allow compiler check to succeed Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=16054 ====================================================================== Reported By: Daniel Richard G. Assigned To: ====================================================================== Project: CMake Issue ID: 16054 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-07 16:53 EDT Last Modified: 2016-04-07 16:53 EDT ====================================================================== Summary: Cannot override CMAKE_{C,CXX}_FLAGS* to allow compiler check to succeed Description: I am attempting to build a project on a Windows system. The development tools on this system are set up a little differently from the norm: Because my company always builds against the static C runtime library (i.e. using the /MT flag), the dynamic C runtime (/MD) stub library is not present at all. Any attempt to link an executable/DLL that was built with /MD will fail. Now, CMake ships with /MD or /MDd in the default flags. I set my desired flags (including /MT) in CFLAGS/CXXFLAGS in the environment, start up cmake-gui, and hit "Configure". "Error in configuration process, project files may be invalid" The log window shows CMake Error at C:/.../Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "C:/.../icl.exe" is not able to compile a simple test program. Lower down, after the compiler invocation, I see icl: command line warning https://public.kitware.com/Bug/view.php?id=10121: overriding '/MT' with '/MDd' CMake's flags are concatenated to my own, and /MDd wins out. Thus the linker fails to link the program, due to that missing stub library, and CMake reports the compiler as non-functional. Okay, so I edit the CMAKE_{C,CXX}_FLAGS* variables to remove all the /MD and /MDd flags. Then I configure again. Same error. It's _still_ passing /MDd to the compiler! At this point, I don't know where that flag is coming from. I grep through the nascent build tree to see if there are any instances of it still kicking around; the only hit is in CMakeError.log. I double-check that the project source isn't at fault: nope, the flag is nowhere to be found there either. Turns out, the place where that flag is coming from is CMake's own Modules/Platform/Windows-MSVC.cmake file. If I edit the _INIT variable in there (e.g. add /Dhi_mom), then I see the result reflected in the compiler test. The bug, then, is that I have no good way of overriding those flag variables in order to allow the compiler check to succeed. (Note that CMAKE_USER_MAKE_RULES_OVERRIDE is not applicable here, because I want to override those flags as a user, not modify the project to get the same effect.) Perhaps the edited variables are used later on, when building the project, but they are certainly not used when checking the compiler. I believe this bug has gone unnoticed for so long due to this specific scenario (missing dynamic CRT stub library) being uncommon. Note that this issue is reproducible with a trivial CMake project---I used one as described at cmake.org/examples---so the original project that exhibited this bug is not at issue. Additional Information: Because I need to use my company's exact compiler/linker flags, and will be given grief by my release-engineering group if I use anything else, it would be nice to be able to set some environment variable or the like that will tell CMake not to "help" with any default flags. While I can always edit the Windows-MSVC.cmake file, that then imposes the ongoing burden of maintaining that file, merging in upstream changes, etc. My goal is to just set CFLAGS/LDFLAGS/etc. in the environment and have the tools work with that, as is the case in Unix. (Setting a CMAKE_NO_DEFAULT_FLAGS variable or the like would be a reasonable solution.) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-07 16:53 Daniel Richard G.New Issue ====================================================================== From mantis at public.kitware.com Thu Apr 7 16:58:28 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 7 Apr 2016 16:58:28 -0400 Subject: [cmake-developers] [CMake 0016055]: "nmake" program is not found using MAKE environment variable Message-ID: <2520567c55a5aa65c99b38ea008cf3f4@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=16055 ====================================================================== Reported By: Daniel Richard G. Assigned To: ====================================================================== Project: CMake Issue ID: 16055 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-07 16:58 EDT Last Modified: 2016-04-07 16:58 EDT ====================================================================== Summary: "nmake" program is not found using MAKE environment variable Description: If you set MAKE=C:\path\to\nmake.exe in your environment, but nmake is not in your PATH, then the NMake generator will fail. Looking for nmake in the current PATH is reasonable, but if MAKE is defined, then that should be used instead. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-07 16:58 Daniel Richard G.New Issue ====================================================================== From tamas.kenez at gmail.com Thu Apr 7 17:12:37 2016 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Thu, 7 Apr 2016 23:12:37 +0200 Subject: [cmake-developers] -isystem suppresses warnings from user header In-Reply-To: <57066B26.6090009@kitware.com> References: <57066B26.6090009@kitware.com> Message-ID: Thanks! I missed that property. Tamas On Thu, Apr 7, 2016 at 4:13 PM, Brad King wrote: > On 04/07/2016 10:03 AM, Tam?s Ken?z wrote: > > CMake uses "-isystem" on the compiler command line for the > > INTERFACE_INCLUDE_DIRECTORIES of imported libraries. > > > > Question: is this the intended behaviour? > > Yes. See discussion here: > > * http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7533 > > and implementation here: > > * Always consider includes from IMPORTED targets to be SYSTEM. > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a63fcbcb > > > Can I force the -I flag somehow for my library? > > Look at these: > > * > https://cmake.org/cmake/help/v3.5/variable/CMAKE_NO_SYSTEM_FROM_IMPORTED.html > * https://cmake.org/cmake/help/v3.5/prop_tgt/NO_SYSTEM_FROM_IMPORTED.html > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Harry at codexdigital.com Fri Apr 8 10:24:08 2016 From: Harry at codexdigital.com (Harry Mallon) Date: Fri, 8 Apr 2016 14:24:08 +0000 Subject: [cmake-developers] Suggest if function has lte gte operators Message-ID: CMake's "if" functionality is missing greater than or equal to and less than or equal to. This change could be tweaked and added to provide this functionality to avoid things like "if(VERSION_STRING VERSION_GREATER "4.8.0" OR VERSION_STRING VERSION_EQUAL "4.8.0")". Commit on github: https://github.com/hm1992/CMake/commit/75b318f8809ae71685cad068cd2e8ce9f19fb28a Would this be of interest for merging? I don't really have the time to do extensive testing on it at the moment. Harry Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 Website | Facebook | Twitter [http://www.codexdigital.com/?action=asset&id=83095F5A-2233-47F5-9598-19228D7E37AE] -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Fri Apr 8 10:42:33 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 8 Apr 2016 10:42:33 -0400 Subject: [cmake-developers] Suggest if function has lte gte operators In-Reply-To: References: Message-ID: <20160408144233.GC16222@megas.khq.kitware.com> On Fri, Apr 08, 2016 at 14:24:08 +0000, Harry Mallon wrote: > CMake's "if" functionality is missing greater than or equal to and > less than or equal to. This change could be tweaked and added to > provide this functionality to avoid things like "if(VERSION_STRING > VERSION_GREATER "4.8.0" OR VERSION_STRING VERSION_EQUAL "4.8.0")". This can also be done as: if (NOT VERSION_STRING VERSION_LESS "4.8.0") I'm ambivalent on the idea of new operators. Documentation for this pattern would likely help. --Ben From eike at sf-mail.de Fri Apr 8 10:42:37 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 08 Apr 2016 16:42:37 +0200 Subject: [cmake-developers] Suggest if function has lte gte operators In-Reply-To: References: Message-ID: <23552762.8zXFCPDzbo@caliban.sf-tec.de> Am Freitag, 8. April 2016, 14:24:08 schrieb Harry Mallon: > CMake's "if" functionality is missing greater than or equal to and less than > or equal to. This change could be tweaked and added to provide this > functionality to avoid things like "if(VERSION_STRING VERSION_GREATER > "4.8.0" OR VERSION_STRING VERSION_EQUAL "4.8.0")". > > Commit on github: > https://github.com/hm1992/CMake/commit/75b318f8809ae71685cad068cd2e8ce9f19fb > 28a > > Would this be of interest for merging? I don't really have the time to do > extensive testing on it at the moment. The common way is to use the power of not: LTE -> NOT GE GTE -> NOT LE Greetings, Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From brad.king at kitware.com Fri Apr 8 10:49:12 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 8 Apr 2016 10:49:12 -0400 Subject: [cmake-developers] Suggest if function has lte gte operators In-Reply-To: References: Message-ID: <5707C4E8.1060008@kitware.com> On 04/08/2016 10:24 AM, Harry Mallon wrote: > "if(VERSION_STRING VERSION_GREATER "4.8.0" OR VERSION_STRING VERSION_EQUAL "4.8.0")". As others have said this can be done with if(NOT version VERSION_LESS 4.8.0) > Commit on github: > https://github.com/hm1992/CMake/commit/75b318f8809ae71685cad068cd2e8ce9f19fb28a I don't think we have a strong use case for the proposed operators, but I've taken a small cleanup from that commit: cmConditionEvaluator: Use pre-allocated keywords in more places https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aff4a5fa Thanks, -Brad From Harry at codexdigital.com Fri Apr 8 10:49:42 2016 From: Harry at codexdigital.com (Harry Mallon) Date: Fri, 8 Apr 2016 14:49:42 +0000 Subject: [cmake-developers] Suggest if function has lte gte operators In-Reply-To: <20160408144233.GC16222@megas.khq.kitware.com> References: <20160408144233.GC16222@megas.khq.kitware.com> Message-ID: <106DE6B8-DA09-479B-9C04-B8525DAC553E@codexdigital.com> That is completely fair. Perhaps a bit of Friday brain from me. It still could reduce complexity if you are trying to do something more complicated. In my opinion A is easier to read than B. A: if ( $1 STRGREATER_EQ $2 AND $3 STRLESS $4 AND $5 STRLESS_EQ $6 ) B: if ( NOT $1 STRLESS $2 AND $3 STRLESS $4 AND NOT $5 STRGREATER $6) H Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 > On 8 Apr 2016, at 15:42, Ben Boeckel wrote: > > On Fri, Apr 08, 2016 at 14:24:08 +0000, Harry Mallon wrote: >> CMake's "if" functionality is missing greater than or equal to and >> less than or equal to. This change could be tweaked and added to >> provide this functionality to avoid things like "if(VERSION_STRING >> VERSION_GREATER "4.8.0" OR VERSION_STRING VERSION_EQUAL "4.8.0")". > > This can also be done as: > > if (NOT VERSION_STRING VERSION_LESS "4.8.0") > > I'm ambivalent on the idea of new operators. Documentation for this > pattern would likely help. > > --Ben > From mantis at public.kitware.com Fri Apr 8 13:18:45 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 8 Apr 2016 19:18:45 +0200 Subject: [cmake-developers] [CMake 0016056]: file(GENERATE) not processing variables from INPUT file Message-ID: <26b276c5c9c89c5739268833379ff71c@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16056 ====================================================================== Reported By: johnnyzz Assigned To: ====================================================================== Project: CMake Issue ID: 16056 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-08 19:18 CEST Last Modified: 2016-04-08 19:18 CEST ====================================================================== Summary: file(GENERATE) not processing variables from INPUT file Description: There is a bug when generating a file with: file(GENERATE OUTPUT "${CMAKE_BINARY_DIR}/output1.txt" INPUT ${CMAKE_SOURCE_DIR}/input.txt ) file(GENERATE OUTPUT "${CMAKE_BINARY_DIR}/output2.txt" CONTENT "SOURCE DIR = '${CMAKE_SOURCE_DIR}'" ) - Using "INPUT filename", variables are not processed, but "CONTENT text" with the same content works properly Steps to Reproduce: 1) cmake . 2) cat output1.txt 3) cat output2.txt -> The variable in output1.txt is not replaced by its value ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-08 19:18 johnnyzz New Issue 2016-04-08 19:18 johnnyzz File Added: CMakeLists.txt ====================================================================== From daniel at pfeifer-mail.de Fri Apr 8 18:31:59 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Sat, 9 Apr 2016 00:31:59 +0200 Subject: [cmake-developers] Integration of clang-tidy Message-ID: Hi, I implemented the integration of `clang-tidy` along the lines of the `include-what-you-use` integration. There is a new `_CLANG_TIDY` target property that is initialized with the value of the `CMAKE__CLANG_TIDY` variable. It contains the command line for `clang-tidy` as a ;-list. Example use: $ cmake -DCMAKE_CXX_CLANG_TIDY:STRING="clang-tidy;-checks=-*,readability-*" .. $ cmake --build . It is also possible to let `clang-tidy` apply fixit hints directly: $ cmake -DCMAKE_CXX_CLANG_TIDY:STRING="clang-tidy;-checks=-*,readability-redundant-string-cstr;-fix" .. The output is recognized by CTest's diagnostic parser. I haven't checked how they look on CDash. cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Provide-integration-for-clang-tidy.patch Type: text/x-patch Size: 18901 bytes Desc: not available URL: From foss at grueninger.de Sat Apr 9 04:12:01 2016 From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=) Date: Sat, 9 Apr 2016 10:12:01 +0200 Subject: [cmake-developers] [Patch] Improve documentation of FindMPI Message-ID: <5708B951.2070200@grueninger.de> Dear CMake developers, please find attached patch to improve the formatting of the FindMPI documentation. Bye Christoph -- My new computer came with Windows 7. Windows 7 is much more user-friendly than Windows Vista. I don't like that. [Sheldon, S03E13] -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Help-improve-formating-of-FindMPI.patch Type: text/x-patch Size: 3253 bytes Desc: not available URL: From dave.gittins at gmail.com Sat Apr 9 05:58:07 2016 From: dave.gittins at gmail.com (Dave Gittins) Date: Sat, 9 Apr 2016 19:58:07 +1000 Subject: [cmake-developers] Emit link commands to file? Message-ID: Enabling CMAKE_EXPORT_COMPILE_COMMANDS causes CMake to emit compile_commands.json, to be picked up by llvm tools or other custom stuff. This is very useful. Can we also have a link_commands.json that records the link commands that produce each target? That would allow a whole new set of validation to be performed on the structure of the build and the linking arrangements. I am trying to perform some of those validations on some large CMake projects but it's hard at the moment - I either have to try to explore the situation within CMake, or parse the generated build files, or parse the verbose build output - none of which is working very well! I am willing to try implementing this feature myself, if it's considered potentially useful and doesn't overlap with ongoing work or something. Any thoughts? Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Sat Apr 9 09:58:42 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 9 Apr 2016 09:58:42 -0400 Subject: [cmake-developers] [CMake 0016057]: FindBoost: No imported target when components not specified Message-ID: <974331aa59d76a11c697899c08fb1ceb@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16057 ====================================================================== Reported By: Tatsuyuki Ishi Assigned To: ====================================================================== Project: CMake Issue ID: 16057 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-09 09:58 EDT Last Modified: 2016-04-09 09:58 EDT ====================================================================== Summary: FindBoost: No imported target when components not specified Description: Here's an example: ============= project(...) find_package(Boost REQUIRED) add_executable(...) target_link_libraries(... Boost::Boost) *BOOM* ============= But this works: ============= find_package(Boost COMPONENTS system REQUIRED) target_link_libraries(... Boost::Boost) ============= This is hard to use, and should be considered as bug and fixed. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-09 09:58 Tatsuyuki Ishi New Issue ====================================================================== From tamas.kenez at gmail.com Sat Apr 9 11:03:39 2016 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Sat, 9 Apr 2016 17:03:39 +0200 Subject: [cmake-developers] Emit link commands to file? In-Reply-To: References: Message-ID: For the "Unix Makefiles" generator, there's already a link.txt in /CMakeFiles/.dir Tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.gittins at gmail.com Sat Apr 9 11:13:08 2016 From: dave.gittins at gmail.com (Dave Gittins) Date: Sun, 10 Apr 2016 01:13:08 +1000 Subject: [cmake-developers] Emit link commands to file? In-Reply-To: References: Message-ID: So, it should be pretty easy to emit a json file containing those - and maybe listing the other targets on which each target depends? That'd be very useful. On Sun, Apr 10, 2016 at 1:03 AM, Tam?s Ken?z wrote: > For the "Unix Makefiles" generator, there's already a link.txt in > /CMakeFiles/.dir > > Tamas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Sun Apr 10 22:24:12 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Mon, 11 Apr 2016 09:24:12 +0700 Subject: [cmake-developers] CMake API for warnings In-Reply-To: <5703FE0C.5060401@yahoo.com> References: <56F85BE4.2070503@yahoo.com> <56F93A40.8090904@kitware.com> <56FA7E9A.7020704@yahoo.com> <56FA9014.70106@kitware.com> <56FA9E26.2090704@yahoo.com> <56FD2835.60301@kitware.com> <56FD5488.9010706@yahoo.com> <5703C5A4.6090506@kitware.com> <5703FE0C.5060401@yahoo.com> Message-ID: <570B0ACC.1050005@yahoo.com> Sounds good? On 06-Apr-16 01:03, Ruslan Baratov via cmake-developers wrote: > On 05-Apr-16 21:03, Brad King wrote: >> On 03/31/2016 12:47 PM, Ruslan Baratov wrote: >>> What about 3 properties containing list of 's (groups >>> unexpanded): >>> >>> * COMPILE_WARNINGS_DISABLE # e.g. "shift-sign-overflow;unused" >>> * COMPILE_WARNINGS_ENABLE # e.g. "ALL" >>> * COMPILE_WARNINGS_TREAT_AS_ERROR # e.g. group + specific: >>> "inline;undef" >> We would need to define behavior when a warning appears in more than >> one list. > > Report an error in case of any type of conflicts. It may happens not > only when same type appears in both DISABLE and ENABLE but for example > when warning already defined by some group. E.g. "EVERYTHING;undef" is > the same as "EVERYTHING". If user okay with having intersections (for > any reason) new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may > control this. > >> Perhaps we need to define some kind of `=on/off/error/no-error` >> syntax for each list entry. > > You mean this: > > compatibility-c++98=off > inline=off > special-members=off > catch-semantic-changed=off > covered-switch-default=off > inherits-via-dominance=off > name-length-exceeded=off > padded=off > this-used-in-init=off > EVERYTHING=on > EVERYTHING=error > > versus this one: > > DISABLE > compatibility-c++98 > inline > special-members > catch-semantic-changed > covered-switch-default > inherits-via-dominance > name-length-exceeded > padded > this-used-in-init > ENABLE > EVERYTHING > TREAT_AS_ERROR > EVERYTHING > > ? > > Second variant looks clearer for me. > >> >> The name "ALL" may not be representative. Even -Wall does not really >> enable >> all possible warnings on some compilers. I'd like to find another >> name that >> captures the idea of enabling most warnings. Or we could try to >> subsume it >> into an interface for the warning level, with -Wall considered "high". > > Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET? > >> >>> I'm not sure about mixing more languages. I think it will be similar to >>> COMPILE_OPTIONS (?), see no language specification in >>> `add_compile_options` command. >> Right. We do have the COMPILE_LANGUAGE genex for some limited use >> cases. >> Its documentation even includes a COMPILE_OPTIONS example. However, it >> also documents that it is not possible to implement fully on VS IDE >> generators. For example, VS does not distinguish between C and C++ >> flags. The same set is always used for both. > > Since /Wall can be set by 'target_compile_options' then abstracting it > by `target_compile_warnings(... ENABLE ALL)` should not be a problem I > think. > >> >> Another option is to have the warning names themselves have a language >> in them, similar to the COMPILE_FEATURES names. > > See no point of this one. So say we have switch-enum warning which is > only for C++, why do we need cxx-switch-enum? There is no > c-switch-enum or any other *-switch-enum. If we are talking about > 'undef' why do we need c-undef and cxx-undef? It mean the same and I > think will be set or unset simultaneously. > > Ruslo From brad.king at kitware.com Mon Apr 11 11:26:09 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 11 Apr 2016 11:26:09 -0400 Subject: [cmake-developers] Integration of clang-tidy In-Reply-To: References: Message-ID: <570BC211.4020006@kitware.com> On 04/08/2016 06:31 PM, Daniel Pfeifer wrote: > I implemented the integration of `clang-tidy` along the lines of the > `include-what-you-use` integration. > There is a new `_CLANG_TIDY` target property that is initialized > with the value of the `CMAKE__CLANG_TIDY` variable. > It contains the command line for `clang-tidy` as a ;-list. Nice. The patch is very complete. Applied: Add options to run clang-tidy with the compiler https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b2db0170 Thanks, -Brad From brad.king at kitware.com Mon Apr 11 11:26:17 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 11 Apr 2016 11:26:17 -0400 Subject: [cmake-developers] [Patch] Improve documentation of FindMPI In-Reply-To: <5708B951.2070200@grueninger.de> References: <5708B951.2070200@grueninger.de> Message-ID: <570BC219.2060105@kitware.com> On 04/09/2016 04:12 AM, Christoph Gr?ninger wrote: > Dear CMake developers, > please find attached patch to improve the formatting of the FindMPI > documentation. Thanks! Applied with minor tweak to the underline character choice: FindMPI: Improve documentation formatting https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=87549054 -Brad From mantis at public.kitware.com Mon Apr 11 15:24:15 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 11 Apr 2016 15:24:15 -0400 Subject: [cmake-developers] [CMake 0016058]: ImageMagick found from Command line but not from CMake GUI Message-ID: <804c5c1328428cf0f89c8727e72ef4a5@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16058 ====================================================================== Reported By: Alex Ferrier Assigned To: ====================================================================== Project: CMake Issue ID: 16058 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-11 15:24 EDT Last Modified: 2016-04-11 15:24 EDT ====================================================================== Summary: ImageMagick found from Command line but not from CMake GUI Description: I am trying to configure the project Theia-SfM to compile with XCode on a Mac. https://github.com/sweeneychris/TheiaSfM Using CMake 3.5.1 installed via Macports via XCode the package configures and builds fine once the appropriate dependencies are installed, e.g. mkdir Build cmake -G XCode .. -- Generating done -- Build files have been written to: /Users/alex/src/TheiaSfM/build If using CMake GUI 3.5.1 downloaded from KitWare, and installed via applications, the same build fails to find ImageMagick. Output ends: -- Found SuiteSparse 4.2.1 -- Check for ImageMagick ImageMagick_EXECUTABLE_DIRImageMagick_EXECUTABLE_DIR-NOTFOUND CMake Error at /Applications/CMake.app/Contents/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message): Could NOT find ImageMagick (missing: ImageMagick_convert_EXECUTABLE ImageMagick_mogrify_EXECUTABLE ImageMagick_convert_EXECUTABLE ImageMagick_mogrify_EXECUTABLE) ImageMagick is demonstrably installed (via macports) in /opt/local/bin. Alexs-MacBook-Pro:TheiaSfM alex$ type -a mogrify mogrify is /opt/local/bin/mogrify Is there any obvious reason why identical versions of CMake would fail to find the same package? I'm assuming /opt/local is in my CMake GUI paths search paths, because further up it finds other dependencies there. -- Found Google Flags: /opt/local/include in namespace: google -- Check for Google Log -- Found Google Logging: /opt/local/include -- Check for Ceres Steps to Reproduce: See description, download package and configure with command line (successful) and GUI (unsuccessful.) Presumably reproducible with other builds using imagemagick? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-11 15:24 Alex Ferrier New Issue ====================================================================== From seblist at xwmw.org Tue Apr 12 05:57:41 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Tue, 12 Apr 2016 11:57:41 +0200 Subject: [cmake-developers] Automoc same source name fix (proposal) Message-ID: <570CC695.1050202@xwmw.org> Hi, I've stumbled over bug https://cmake.org/Bug/view.php?id=12873 a few times now since I like to use same named data/view classes. I've prepared a fix that generates all moc_xxx.cpp files in the foo_automoc.dir subdirectory. For the attached test case you end up with foo_automoc.cpp -- As before but includes sources below foo_automoc.dir/data/moc_item.cpp foo_automoc.dir/view/moc_item.cpp foo_automoc.dir/item.cpp This solves the same output moc problem. What remains though is that including "moc_foo.cpp" does not work because of missing INCLUDE_DIRECTORIES. Kind regards, Sebastian Holtermann -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_automoc_directory_fix-2016-04-12-1.patch Type: text/x-patch Size: 8651 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_automoc_test-2016-04-12-1.tar.gz Type: application/gzip Size: 919 bytes Desc: not available URL: From seblist at xwmw.org Tue Apr 12 06:21:05 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Tue, 12 Apr 2016 12:21:05 +0200 Subject: [cmake-developers] Automoc same source name fix (proposal) In-Reply-To: <570CC695.1050202@xwmw.org> References: <570CC695.1050202@xwmw.org> Message-ID: <570CCC11.4070406@xwmw.org> Am 12.04.2016 um 11:57 schrieb Sebastian Holtermann: Oops, moc_item.cpp it is. > For the attached test case you end up with foo_automoc.cpp -- As before but includes sources below foo_automoc.dir/data/moc_item.cpp foo_automoc.dir/view/moc_item.cpp foo_automoc.dir/moc_item.cpp From seblist at xwmw.org Tue Apr 12 07:43:29 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Tue, 12 Apr 2016 13:43:29 +0200 Subject: [cmake-developers] Automoc same source name fix (proposal) In-Reply-To: <570CC695.1050202@xwmw.org> References: <570CC695.1050202@xwmw.org> Message-ID: <570CDF61.8020508@xwmw.org> Sorry for the noise. > I've stumbled over bug > https://cmake.org/Bug/view.php?id=12873 > a few times now since I like to use same named data/view classes. > > I've prepared a fix that generates all moc_xxx.cpp files > in the foo_automoc.dir subdirectory. Here is an improved patch that calculates header relative paths in the following parent directory lookup order - CMAKE_CURRENT_SOURCE_DIR - CMAKE_CURRENT_BINARY_DIR - CMAKE_SOURCE_DIR - CMAKE_BINARY_DIR Also std::cout debugging was removed ;) Kind regards, Sebastian Holtermann -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_automoc_directory_fix-2016-04-12-2.patch Type: text/x-patch Size: 9050 bytes Desc: not available URL: From seblist at xwmw.org Tue Apr 12 11:40:44 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Tue, 12 Apr 2016 17:40:44 +0200 Subject: [cmake-developers] Automoc same source - More thoughts In-Reply-To: <570CDF61.8020508@xwmw.org> References: <570CC695.1050202@xwmw.org> <570CDF61.8020508@xwmw.org> Message-ID: <570D16FC.1080702@xwmw.org> Am 12.04.2016 um 13:43 schrieb Sebastian Holtermann: > Sorry for the noise. > >> I've stumbled over bug >> https://cmake.org/Bug/view.php?id=12873 >> a few times now since I like to use same named data/view classes. >> >> I've prepared a fix that generates all moc_xxx.cpp files >> in the foo_automoc.dir subdirectory. > I had some more thoughts about this. CMAKE_CURRENT_BINARY_DIR / foo_automoc.cpp foo_automoc.dir/data/moc_item.cpp foo_automoc.dir/view/moc_item.cpp foo_automoc.dir/moc_item.cpp With directory based moc file generation it is complicated to allow "#include " (I've never included mocs btw.). Putting every moc directory into the target INCLUDE_DIRECTORIES won't help because then there would be multiple moc_item.cpp files that match "include ". If per source INCLUDE_DIRECTORIES were possible it might work though. My proposal is this: - Moc files that are "#include<>"d get generated in CMAKE_CURRENT_BINARY_DIR/moc_xxx.cpp as before but with name collision test. - Moc files not included but detected from headers get generated in CMAKE_CURRENT_BINARY_DIR/foo_automoc.dir/ with subdirectory support. Since they're not included it doesn't matter where they are as long as they don't overwrite each other. I'll prepare another patch for this... Kind regards, Sebastian From mantis at public.kitware.com Tue Apr 12 12:00:44 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 12 Apr 2016 12:00:44 -0400 Subject: [cmake-developers] [CMake 0016059]: It is not possible to specify a linker different from the compiler to link a shared library Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16059 ====================================================================== Reported By: Antonio Assigned To: ====================================================================== Project: CMake Issue ID: 16059 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-12 12:00 EDT Last Modified: 2016-04-12 12:00 EDT ====================================================================== Summary: It is not possible to specify a linker different from the compiler to link a shared library Description: In some situations, it might be convenient to specify a different linker than the compiler. For example, for llvm combined with mingw, compiling with clang and linking with gcc would work. The workaround proposed here https://cmake.org/pipermail/cmake/2014-August/058268.html does not seem to work. Steps to Reproduce: Requires 2 compilers to be there. In the attached project, Configuring with D:\dummyProj\build> cmake ..\src -G "Eclipse CDT4 - Ninja" -DCMAKE_TOOLCHAIN_FILE=..\src\Toolchain-LLVM.cmake -DCMAKE_LINKER=C:/Programs/mingw32_493_posix_dwarf/bin/g++.exe -DCMAKE_CXX_LINK_EXECUTABLE=" -o " -DCMAKE_CXX_CREATE_SHARED_LIBRARY=" -o " Building will anyway lead to the following commands to be generated: [1/2] C:\Programs\LLVM\bin\clang++.exe -Ddummy_EXPORTS -MMD -MT CMakeFiles/dummy.dir/dummy.cpp.obj -MF CMakeFiles/dummy.dir/dummy.cpp.obj.d -o CMakeFiles/dummy.dir/dummy.cpp.obj -c D:/dummyProj/src/dummy.cpp [2/2] cmd.exe /C "cd . && C:\Programs\LLVM\bin\clang++.exe -shared -o libdummy.dll -Wl,--out-implib,libdummy.dll.a -Wl,--major-image-version,0,--minor-image-version,0 CMakeFiles/dummy.dir/dummy.cpp.obj -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ." FAILED: cmd.exe /C "cd . && C:\Programs\LLVM\bin\clang++.exe -shared -o libdummy.dll -Wl,--out-implib,libdummy.dll.a -Wl,--major-image-version,0,--minor-image-version,0 CMakeFiles/dummy.dir/dummy.cpp.obj -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ." C:\Programs\mingw32_493_posix_dwarf\i686-w64-mingw32\lib/libmingw32.a(lib32_libmingw32_a-pseudo-reloc.o):pseudo-reloc.c:(.text+0x1d6): undefined reference to `__chkstk_ms' clang++.exe: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed. The first command is correct, the second doesn't use g++ to link as desired. Linking succeeds if g++ is replaced in the command line. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-12 12:00 Antonio New Issue 2016-04-12 12:00 Antonio File Added: dummyProj.zip ====================================================================== From brad.king at kitware.com Tue Apr 12 14:00:21 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 12 Apr 2016 14:00:21 -0400 Subject: [cmake-developers] CMake API for warnings In-Reply-To: <5703FE0C.5060401@yahoo.com> References: <56F85BE4.2070503@yahoo.com> <56F93A40.8090904@kitware.com> <56FA7E9A.7020704@yahoo.com> <56FA9014.70106@kitware.com> <56FA9E26.2090704@yahoo.com> <56FD2835.60301@kitware.com> <56FD5488.9010706@yahoo.com> <5703C5A4.6090506@kitware.com> <5703FE0C.5060401@yahoo.com> Message-ID: <570D37B5.6010502@kitware.com> Hi Ruslo, Sorry for taking so long to respond here. I've been hoping to find time to think through the design deeply but I don't know when that may happen. Here is some more feedback. I invite others to jump in here. Without more interest I'm hesitant to proceed. On 04/05/2016 02:03 PM, Ruslan Baratov wrote: > Report an error in case of any type of conflicts. Yes. > new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may control this. I'd prefer to avoid extra knobs if possible. > You mean this: > > compatibility-c++98=off > inline=off > special-members=off > catch-semantic-changed=off > covered-switch-default=off > inherits-via-dominance=off > name-length-exceeded=off > padded=off > this-used-in-init=off > EVERYTHING=on > EVERYTHING=error > > versus this one: > > DISABLE > compatibility-c++98 > inline > special-members > catch-semantic-changed > covered-switch-default > inherits-via-dominance > name-length-exceeded > padded > this-used-in-init > ENABLE > EVERYTHING > TREAT_AS_ERROR > EVERYTHING Consider examples where we don't have the full list ahead of time and are instead appending. Or, what if we want to check the current property value to see if some setting is already present? Compilers use flags like -Wxyz -Wno-abc -Whjk=error and not -WDISABLE $w1 $w2 -WENABLE $w3 $w4 so IMO the individual values are easier to reason about. Also one could imagine having the value come from a generator expression, e.g. foo=$ >> I'd like to find another name that captures the idea of enabling most warnings. > > Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET? I don't think "everything" or "all" has a meaningful implementation available on all compilers. I was actually saying the opposite. We should not try to provide such an abstraction and instead have one called "most" or "high" or something like that. -Brad From rcdailey.lists at gmail.com Tue Apr 12 14:54:01 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 12 Apr 2016 13:54:01 -0500 Subject: [cmake-developers] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS Message-ID: I have the following CMake code: get_property( predefined_folder GLOBAL PROPERTY PREDEFINED_TARGETS_FOLDER ) set_target_properties( ALL_BUILD PROPERTIES FOLDER ${predefined_folder} ) if( BUILD_TESTING ) set_target_properties( RUN_TESTS PROPERTIES FOLDER "Testing" ) endif() However this fails stating those targets do not exist. Is there a way I can make this work? I'd like to organize these CMake targets in my own way in the Visual Studio solution. There have been topics regarding this on the mailing list in the past, but they have gone unanswered. Specifically, why are these targets treated as if they do not exist? Does CMake only allow you to set properties on targets created directly by the scripts themselves (i.e. no built-in targets can be affected)? I'm happy to contribute a patch to this if needed. Thanks in advance. From brad.king at kitware.com Tue Apr 12 15:05:11 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 12 Apr 2016 15:05:11 -0400 Subject: [cmake-developers] Changing FOLDER property of ALL_BUILD and RUN_TESTS targets in VS In-Reply-To: References: Message-ID: <570D46E7.1050400@kitware.com> On 04/12/2016 02:54 PM, Robert Dailey wrote: > set_target_properties( ALL_BUILD PROPERTIES FOLDER ${predefined_folder} ) > > if( BUILD_TESTING ) > set_target_properties( RUN_TESTS PROPERTIES FOLDER "Testing" ) > endif() > > However this fails stating those targets do not exist. They don't exist because they are not created until generate-time. FYI recent changes in 'master' move ALL_BUILD into the predefined targets folder. > Does CMake only allow you to set properties on targets created > directly by the scripts themselves (i.e. no built-in targets can be > affected)? Correct. See above. This is not trivial to change because the ALL_BUILD, INSTALL, etc. targets are not normal targets. Internally they have type GLOBAL_TARGET. There can be *multiple* such targets of the same name created by the generators. Each directory whose CMakeLists.txt file calls project(SomeName) gets a SomeName.sln in VS, for example. Each such .sln has a different ALL_BUILD target with its own dependencies. The generators can get away with this because nothing ever looks up these targets by name. Therefore trying to present such targets to CMake project code is not well-defined. -Brad From seblist at xwmw.org Tue Apr 12 15:12:42 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Tue, 12 Apr 2016 21:12:42 +0200 Subject: [cmake-developers] Automoc same source - More thoughts In-Reply-To: <570D16FC.1080702@xwmw.org> References: <570CC695.1050202@xwmw.org> <570CDF61.8020508@xwmw.org> <570D16FC.1080702@xwmw.org> Message-ID: <570D48AA.8040007@xwmw.org> Am 12.04.2016 um 17:40 schrieb Sebastian Holtermann: > Am 12.04.2016 um 13:43 schrieb Sebastian Holtermann: >> Sorry for the noise. >> >>> I've stumbled over bug >>> https://cmake.org/Bug/view.php?id=12873 >>> a few times now since I like to use same named data/view classes. >>> >>> I've prepared a fix that generates all moc_xxx.cpp files >>> in the foo_automoc.dir subdirectory. >> > > I had some more thoughts about this. > > CMAKE_CURRENT_BINARY_DIR / > foo_automoc.cpp > foo_automoc.dir/data/moc_item.cpp > foo_automoc.dir/view/moc_item.cpp > foo_automoc.dir/moc_item.cpp > > With directory based moc file generation it is complicated to allow > "#include " (I've never included mocs btw.). > Putting every moc directory into the target INCLUDE_DIRECTORIES > won't help because then there would be multiple moc_item.cpp > files that match "include ". > If per source INCLUDE_DIRECTORIES were possible it might work though. > > My proposal is this: > > - Moc files that are "#include<>"d get generated in > CMAKE_CURRENT_BINARY_DIR/moc_xxx.cpp as before but with > name collision test. > > - Moc files not included but detected from > headers get generated in > CMAKE_CURRENT_BINARY_DIR/foo_automoc.dir/ > with subdirectory support. > Since they're not included it doesn't matter where they are as long as > they don't overwrite each other. > > > I'll prepare another patch for this... Here it is. Please review/commit. To test it insert #include "moc_item.cpp" in any or many of the item.cpp files of the attached test project. Kind regards, Sebastian Holtermann -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_automoc_directory_fix-2016-04-12-3.patch Type: text/x-patch Size: 6948 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_automoc_directory_test-2016-04-12-2.tar.gz Type: application/gzip Size: 1057 bytes Desc: not available URL: From brad.king at kitware.com Tue Apr 12 15:26:43 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 12 Apr 2016 15:26:43 -0400 Subject: [cmake-developers] Automoc same source - More thoughts In-Reply-To: <570D48AA.8040007@xwmw.org> References: <570CC695.1050202@xwmw.org> <570CDF61.8020508@xwmw.org> <570D16FC.1080702@xwmw.org> <570D48AA.8040007@xwmw.org> Message-ID: <570D4BF3.8010702@kitware.com> On 04/12/2016 03:12 PM, Sebastian Holtermann wrote: > Here it is. Please review/commit. > > To test it insert #include "moc_item.cpp" in any or many > of the item.cpp files of the attached test project. Thanks for working on this! As requested in the issue tracker entry you linked, in this comment: https://cmake.org/Bug/view.php?id=12873#c40513 please extend the CMake test suite with a case covering this. We need to test both the conflicting source name use case and the #include "moc_..." use case. Please revise the patch to include such tests. Thanks, -Brad From mantis at public.kitware.com Tue Apr 12 17:52:26 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 12 Apr 2016 17:52:26 -0400 Subject: [cmake-developers] [CMake 0016060]: Chrome warns cmake installer is harmful program Message-ID: <021f4be9d1b9de70980ae4d32f3a9264@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=16060 ====================================================================== Reported By: raysatiro Assigned To: ====================================================================== Project: CMake Issue ID: 16060 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-12 17:52 EDT Last Modified: 2016-04-12 17:52 EDT ====================================================================== Summary: Chrome warns cmake installer is harmful program Description: Using Chrome Version 49.0.2623.112 m I'm trying to download the cmake installer: "The site ahead contains harmful programs Attackers on cmake.org might attempt to trick you into installing programs that harm your browsing experience (for example, by changing your homepage or showing extra ads on sites you visit)." Steps to Reproduce: https://cmake.org/download/ and click on cmake-3.5.1-win32-x86.msi Additional Information: https://www.google.com/transparencyreport/safebrowsing/diagnostic/index.html?hl=en-US#url=https://cmake.org/files/v3.5/cmake-3.5.1-win32-x86.msi ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-12 17:52 raysatiro New Issue 2016-04-12 17:52 raysatiro File Added: cmake chrome says harmful programs.PNG ====================================================================== From ruslan_baratov at yahoo.com Wed Apr 13 01:20:05 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 13 Apr 2016 12:20:05 +0700 Subject: [cmake-developers] CMake API for warnings In-Reply-To: <570D37B5.6010502@kitware.com> References: <56F85BE4.2070503@yahoo.com> <56F93A40.8090904@kitware.com> <56FA7E9A.7020704@yahoo.com> <56FA9014.70106@kitware.com> <56FA9E26.2090704@yahoo.com> <56FD2835.60301@kitware.com> <56FD5488.9010706@yahoo.com> <5703C5A4.6090506@kitware.com> <5703FE0C.5060401@yahoo.com> <570D37B5.6010502@kitware.com> Message-ID: <570DD705.5020306@yahoo.com> On 13-Apr-16 01:00, Brad King wrote: > Hi Ruslo, > > Sorry for taking so long to respond here. I've been hoping to find time > to think through the design deeply but I don't know when that may happen. > Here is some more feedback. I invite others to jump in here. Without > more interest I'm hesitant to proceed. > > On 04/05/2016 02:03 PM, Ruslan Baratov wrote: >> Report an error in case of any type of conflicts. > Yes. > >> new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may control this. > I'd prefer to avoid extra knobs if possible. Okay, what about CMake warning for developer? (cmake -Wdev/cmake -Wno-dev) > >> You mean this: >> >> compatibility-c++98=off >> inline=off >> special-members=off >> catch-semantic-changed=off >> covered-switch-default=off >> inherits-via-dominance=off >> name-length-exceeded=off >> padded=off >> this-used-in-init=off >> EVERYTHING=on >> EVERYTHING=error >> >> versus this one: >> >> DISABLE >> compatibility-c++98 >> inline >> special-members >> catch-semantic-changed >> covered-switch-default >> inherits-via-dominance >> name-length-exceeded >> padded >> this-used-in-init >> ENABLE >> EVERYTHING >> TREAT_AS_ERROR >> EVERYTHING > Consider examples where we don't have the full list ahead of time and > are instead appending. - > Or, what if we want to check the current property > value to see if some setting is already present? What do you mean? > Compilers use flags like > > -Wxyz -Wno-abc -Whjk=error > > and not > > -WDISABLE $w1 $w2 -WENABLE $w3 $w4 I don't think the reason of approach used in compilers is about been convenient for user to analyze command line flags. CMake can do much better job here. All I'm trying to say about ENABLE/DISABLE lists is that if user will have N warnings to enable and M warnings to disable he will not write N times *=on and M times *=off and probably will just create helper functions: function(enable_warnings_list ...) foreach(warning ...) list(APPEND result ${warning}=on) endforeach() endif() So instead of writing extra different modules by a lot of developers why not support this from the box? > > so IMO the individual values are easier to reason about. Also one could > imagine having the value come from a generator expression, e.g. > > foo=$ As far as I understand we should allow on/off/error, so effectively it will be: foo=$<$:off>$<$>:error> so how about this: compile_warnings(DISABLE foo CONFIGURATION Debug) compile_warnings(ERROR foo CONFIGURATION NOT Debug) ? > >>> I'd like to find another name that captures the idea of enabling most warnings. >> Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET? > I don't think "everything" or "all" has a meaningful implementation > available on all compilers. I was actually saying the opposite. > We should not try to provide such an abstraction and instead have > one called "most" or "high" or something like that. I'm pretty sure all compilers have flag to enable all kind of available warnings (it may not call "All", e.g. -Weverything for Clang). Even if there is such compiler we can use maximum level + adding extra warnings explicitly. There must be abstracted group that allow to enable everything. Also I think that LEVEL/MOST/ALL groups doesn't make a lot of practical sense since every compiler have different kind of warnings enabled by such groups, so it's not cross-platformic friendly. Ruslo From seblist at xwmw.org Wed Apr 13 10:08:13 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Wed, 13 Apr 2016 16:08:13 +0200 Subject: [cmake-developers] Automoc same source - More thoughts In-Reply-To: <570D4BF3.8010702@kitware.com> References: <570CC695.1050202@xwmw.org> <570CDF61.8020508@xwmw.org> <570D16FC.1080702@xwmw.org> <570D48AA.8040007@xwmw.org> <570D4BF3.8010702@kitware.com> Message-ID: <570E52CD.7040602@xwmw.org> Am 12.04.2016 um 21:26 schrieb Brad King: > On 04/12/2016 03:12 PM, Sebastian Holtermann wrote: >> Here it is. Please review/commit. >> >> To test it insert #include "moc_item.cpp" in any or many >> of the item.cpp files of the attached test project. > > Thanks for working on this! > > As requested in the issue tracker entry you linked, > in this comment: > > https://cmake.org/Bug/view.php?id=12873#c40513 > > please extend the CMake test suite with a case covering > this. We need to test both the conflicting source name > use case and the #include "moc_..." use case. Please > revise the patch to include such tests. > Thanks for the feedback. Well, looking into the sources and there is already Tests/QtAutogen. It covers various #include "moc_..." cases. What is missing is a same-name case. I will post an updated patch later. Regards, Sebastian From brad.king at kitware.com Wed Apr 13 10:40:17 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 13 Apr 2016 10:40:17 -0400 Subject: [cmake-developers] Automoc same source - More thoughts In-Reply-To: <570E52CD.7040602@xwmw.org> References: <570CC695.1050202@xwmw.org> <570CDF61.8020508@xwmw.org> <570D16FC.1080702@xwmw.org> <570D48AA.8040007@xwmw.org> <570D4BF3.8010702@kitware.com> <570E52CD.7040602@xwmw.org> Message-ID: <570E5A51.8030500@kitware.com> On 04/13/2016 10:08 AM, Sebastian Holtermann wrote: > Well, looking into the sources and there is already Tests/QtAutogen. > It covers various #include "moc_..." cases. Perhaps, but as pointed out in the issue tracker entry I linked those test cases were not sufficient to fail after the the incorrect fix made and reverted there. Please identify why and extend them. > What is missing is a same-name case. > I will post an updated patch later. Thanks! -Brad From mantis at public.kitware.com Wed Apr 13 11:02:54 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 13 Apr 2016 11:02:54 -0400 Subject: [cmake-developers] [CMake 0016061]: define SOLARIS and CMAKE_HOST_SOLARIS as a cmake built-in Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=16061 ====================================================================== Reported By: Stefan Teleman Assigned To: ====================================================================== Project: CMake Issue ID: 16061 Category: CMake Reproducibility: always Severity: trivial Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-13 11:02 EDT Last Modified: 2016-04-13 11:02 EDT ====================================================================== Summary: define SOLARIS and CMAKE_HOST_SOLARIS as a cmake built-in Description: in ${top_srcdir}/Source/cmState.cxx: void cmState::Snapshot::SetDefaultDefinitions() several builtins are defined: WIN32/CMAKE_HOST_WIN32, APPLE/CMAKE_HOST_APPLE, etc. We would like to submit this patch to add corresponding definitions for Solaris: SOLARIS/CMAKE_HOST_SOLARIS Proposed patch - cmState.cxx-solaris.patch - attached. The patch is based on cmake 3.5.0. Steps to Reproduce: Always - the SOLARIS/CMAKE_HOST_SOLARIS definition is not present in cmake. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-13 11:02 Stefan Teleman New Issue 2016-04-13 11:02 Stefan Teleman File Added: cmState.cxx-solaris.patch ====================================================================== From seblist at xwmw.org Wed Apr 13 11:44:12 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Wed, 13 Apr 2016 17:44:12 +0200 Subject: [cmake-developers] Automoc same source - More thoughts In-Reply-To: <570E5A51.8030500@kitware.com> References: <570CC695.1050202@xwmw.org> <570CDF61.8020508@xwmw.org> <570D16FC.1080702@xwmw.org> <570D48AA.8040007@xwmw.org> <570D4BF3.8010702@kitware.com> <570E52CD.7040602@xwmw.org> <570E5A51.8030500@kitware.com> Message-ID: <570E694C.4050609@xwmw.org> Am 13.04.2016 um 16:40 schrieb Brad King: > On 04/13/2016 10:08 AM, Sebastian Holtermann wrote: >> Well, looking into the sources and there is already Tests/QtAutogen. >> It covers various #include "moc_..." cases. > > Perhaps, but as pointed out in the issue tracker entry I linked those > test cases were not sufficient to fail after the the incorrect fix > made and reverted there. Please identify why and extend them. Ok, I think I've identifier the problem of the current test (includer abc.cpp is not in a subdirectory of CMAKE_CURRENT_BINARY_DIR). I will prepare another test that fails on the incorrect fix, too. -Sebastian From seblist at xwmw.org Wed Apr 13 14:30:36 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Wed, 13 Apr 2016 20:30:36 +0200 Subject: [cmake-developers] Automoc same source - More thoughts In-Reply-To: <570E5A51.8030500@kitware.com> References: <570CC695.1050202@xwmw.org> <570CDF61.8020508@xwmw.org> <570D16FC.1080702@xwmw.org> <570D48AA.8040007@xwmw.org> <570D4BF3.8010702@kitware.com> <570E52CD.7040602@xwmw.org> <570E5A51.8030500@kitware.com> Message-ID: <570E904C.1040308@xwmw.org> Am 13.04.2016 um 16:40 schrieb Brad King: > On 04/13/2016 10:08 AM, Sebastian Holtermann wrote: >> Well, looking into the sources and there is already Tests/QtAutogen. >> It covers various #include "moc_..." cases. > > Perhaps, but as pointed out in the issue tracker entry I linked those > test cases were not sufficient to fail after the the incorrect fix > made and reverted there. Please identify why and extend them. > Here is a patch that introduces the same-source-name test in Tests/QtAutogen. With the current git cmake the test fails. The latest moc-directory-patch from earlier in this thread (cmake_automoc_directory_fix-2016-04-12-3.patch) fixes the issue. -Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_automoc_directory_test-2016-04-13-1.patch Type: text/x-patch Size: 8231 bytes Desc: not available URL: From mantis at public.kitware.com Wed Apr 13 15:38:03 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 13 Apr 2016 15:38:03 -0400 Subject: [cmake-developers] [CMake 0016062]: Policy CMP0037 should only warn about "test" and "package" being reserved if CTest and CPack are being used Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16062 ====================================================================== Reported By: Ben Boeckel Assigned To: ====================================================================== Project: CMake Issue ID: 16062 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-13 15:37 EDT Last Modified: 2016-04-13 15:37 EDT ====================================================================== Summary: Policy CMP0037 should only warn about "test" and "package" being reserved if CTest and CPack are being used Description: Common complaint among those not using CTest for testing, but want "make test" to use their test running infrastructure. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-13 15:37 Ben Boeckel New Issue ====================================================================== From seblist at xwmw.org Thu Apr 14 04:22:47 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Thu, 14 Apr 2016 10:22:47 +0200 Subject: [cmake-developers] Automoc same source - More thoughts In-Reply-To: <570E5A51.8030500@kitware.com> References: <570CC695.1050202@xwmw.org> <570CDF61.8020508@xwmw.org> <570D16FC.1080702@xwmw.org> <570D48AA.8040007@xwmw.org> <570D4BF3.8010702@kitware.com> <570E52CD.7040602@xwmw.org> <570E5A51.8030500@kitware.com> Message-ID: <570F5357.1050404@xwmw.org> Am 13.04.2016 um 16:40 schrieb Brad King: > On 04/13/2016 10:08 AM, Sebastian Holtermann wrote: >> Well, looking into the sources and there is already Tests/QtAutogen. >> It covers various #include "moc_..." cases. > > Perhaps, but as pointed out in the issue tracker entry I linked those > test cases were not sufficient to fail after the the incorrect fix > made and reverted there. Please identify why and extend them. Now after testing it I think the incorrect fix was not incorrect at all. The feared moc renaming was only applied to mocs that were not #included. For not #included mocs the (not so) incorrect pach creates long moc names in this format: moc_DIRNAME_BASENAME.cpp. My patch creates the not #included mocs in subdirectories. This is more robust IMO. -Sebastian From mantis at public.kitware.com Thu Apr 14 04:40:42 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 14 Apr 2016 04:40:42 -0400 Subject: [cmake-developers] [CMake 0016063]: Wrong protobuf search logic Message-ID: <939c6db668be998ae81777cc065a52c2@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=16063 ====================================================================== Reported By: xseven Assigned To: ====================================================================== Project: CMake Issue ID: 16063 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-14 04:40 EDT Last Modified: 2016-04-14 04:40 EDT ====================================================================== Summary: Wrong protobuf search logic Description: I faced a problem with using find_package(Protobuf). I'm using protobuf-3.0.0-beta-2 I built it and installed via MSVC 2015 but module looks for ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug)and Release which seem missing in contemporary MSVC build anymore Could be more reasonable to use PROTOBUF_SRC_ROOT_FOLDER as a path to installed protobuf files after build? Steps to Reproduce: Build protobuf-3.0.0-beta-2 Set PROTOBUF_SRC_ROOT_FOLDER run CMake 3.5.1 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-14 04:40 xseven New Issue ====================================================================== From brad.king at kitware.com Thu Apr 14 08:36:25 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 14 Apr 2016 08:36:25 -0400 Subject: [cmake-developers] Automoc same source - More thoughts In-Reply-To: <570D48AA.8040007@xwmw.org> References: <570CC695.1050202@xwmw.org> <570CDF61.8020508@xwmw.org> <570D16FC.1080702@xwmw.org> <570D48AA.8040007@xwmw.org> Message-ID: <570F8EC9.7060205@kitware.com> On 04/12/2016 03:12 PM, Sebastian Holtermann wrote: > Here it is. Please review/commit. Thanks. > - subDir = absPath > - + cmsys::SystemTools::GetFilenamePath(currentMoc) + '/'; > + std::string fileNamePath = cmsys::SystemTools::GetFilenamePath(currentMoc); > + if ( fileNamePath.find ( ".." ) == std::string::npos ) > + { > + subDir = absPath + fileNamePath + '/'; > + } > + else > + { > + // We can't handle parent directories > + std::cerr << "AUTOGEN: error: moc include \"" << currentMoc > + << "\" contains parent directory reference \"..\"" > + << std::endl; > + ::exit(EXIT_FAILURE); > + } [snip] > + // Check: Look for name collisions > + { > + typedef std::map::const_iterator Iter; > + for ( Iter ita = includedMocs.begin(); ita != includedMocs.end(); ++ita ) > + { > + Iter itb = ita; > + ++itb; > + for ( ; itb != includedMocs.end(); ++itb ) > + { > + if ( ita->second == itb->second ) > + { > + std::cerr << "AUTOGEN: error: moc name collision" << std::endl > + << ita->first << " -> " << ita->second << std::endl > + << itb->first << " -> " << itb->second << std::endl; > + ::exit(EXIT_FAILURE); > + } > + } > + } > + } > + These two hunks look like error checks added to the existing logic. Please split these out into preceding commits with their own messages explaining the new errors. Please also include a Help/release/dev/automoc-diagnostics.rst file with a release note explaining the new diagnostics. Thanks, -Brad From mantis at public.kitware.com Thu Apr 14 12:45:17 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 14 Apr 2016 12:45:17 -0400 Subject: [cmake-developers] [CMake 0016064]: Missing /usr/local/bin causes --install script to fail. Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16064 ====================================================================== Reported By: Ho Cheung Assigned To: ====================================================================== Project: CMake Issue ID: 16064 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-14 12:45 EDT Last Modified: 2016-04-14 12:45 EDT ====================================================================== Summary: Missing /usr/local/bin causes --install script to fail. Description: On a clean install of OSX 10.11.4, I discovered the install script fails to create the symlinks: Work-iMac:~ hocheung20$ sudo "/Applications/CMake.app/Contents/bin/cmake-gui" --install Failed: '/usr/local/bin/cmake' -> '/Applications/CMake.app/Contents/bin/cmake': No such file or directory This is because in a clean install of OSX, only /usr/local exists. When I mkdir /usr/local/bin, the script succeeds. Steps to Reproduce: Clean install OSX. Copy CMake app to /Applications sudo "/Applications/CMake.app/Contents/bin/cmake-gui" --install ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-14 12:45 Ho Cheung New Issue ====================================================================== From seblist at xwmw.org Thu Apr 14 17:06:30 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Thu, 14 Apr 2016 23:06:30 +0200 Subject: [cmake-developers] Automoc same source - More thoughts In-Reply-To: <570F8EC9.7060205@kitware.com> References: <570CC695.1050202@xwmw.org> <570CDF61.8020508@xwmw.org> <570D16FC.1080702@xwmw.org> <570D48AA.8040007@xwmw.org> <570F8EC9.7060205@kitware.com> Message-ID: <57100656.1000207@xwmw.org> > These two hunks look like error checks added to the existing logic. > Please split these out into preceding commits with their own messages > explaining the new errors. Please also include a > > Help/release/dev/automoc-diagnostics.rst > > file with a release note explaining the new diagnostics. > Wow, this turned into a git learning session for me. Git is as awesome as it is hard. I've split the patch into three as suggested. -Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_automoc_name_collision_check-2016-04-14-1.patch Type: text/x-patch Size: 3946 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_automoc_include_parent_check-2016-04-14-1.patch Type: text/x-patch Size: 2251 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_automoc_moc_directories-2016-04-14-1.patch Type: text/x-patch Size: 5261 bytes Desc: not available URL: From dmeiser at txcorp.com Thu Apr 14 16:23:47 2016 From: dmeiser at txcorp.com (Dominic Meiser) Date: Thu, 14 Apr 2016 16:23:47 -0400 Subject: [cmake-developers] FindMPI with intel MPI wrappers Message-ID: <20160414202347.GD3177@ivyamd.txcorp.com> Hi, I've been having trouble with the detection of the MPI libraries when using intel's MPI compiler wrappers. The issue is that - The wrappers use /LIBPATH: instead of -L to specify the library search path - The wrappers link against static versions of the mpi libraries without using -l. I'm attaching a couple of patches to deal with this. Are patches to the mailing list still the recommended way to submit changes? Or are pull requests on github preferred? Cheers, Dominic -- Dominic Meiser Tech-X Corporation - 5621 Arapahoe Avenue - Boulder, CO 80303 -------------- next part -------------- >From 879532ce66d87d9733e0edca9d54d95823880dff Mon Sep 17 00:00:00 2001 From: Dominic Meiser Date: Thu, 14 Apr 2016 11:01:43 -0600 Subject: [PATCH 1/2] Accept /LIBPATH for specification of linker paths. The intel MPI wrappers use this form of -L to specify library locations. --- Modules/FindMPI.cmake | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Modules/FindMPI.cmake b/Modules/FindMPI.cmake index 0e406e0..0bf5549 100644 --- a/Modules/FindMPI.cmake +++ b/Modules/FindMPI.cmake @@ -357,10 +357,11 @@ function (interrogate_mpi_compiler lang try_libs) endif() # Extract linker paths from the link command line - string(REGEX MATCHALL "(^| |-Wl,)-L([^\" ]+|\"[^\"]+\")" MPI_ALL_LINK_PATHS "${MPI_LINK_CMDLINE}") + string(REGEX MATCHALL "(^| |-Wl,)(-L|/LIBPATH:)([^\" ]+|\"[^\"]+\")" MPI_ALL_LINK_PATHS "${MPI_LINK_CMDLINE}") set(MPI_LINK_PATH) foreach(LPATH ${MPI_ALL_LINK_PATHS}) string(REGEX REPLACE "^(| |-Wl,)-L" "" LPATH ${LPATH}) + string(REGEX REPLACE "/LIBPATH:" "" LPATH ${LPATH}) string(REPLACE "//" "/" LPATH ${LPATH}) list(APPEND MPI_LINK_PATH ${LPATH}) endforeach() -- 2.6.2.450.g259b5e6 -------------- next part -------------- >From 62a9bf47f07b5853a7c857545f243844ab3b5ca6 Mon Sep 17 00:00:00 2001 From: Dominic Meiser Date: Thu, 14 Apr 2016 11:03:21 -0600 Subject: [PATCH 2/2] Fix for static MPI libraries. The intel MPI compiler wrappers link against static MPI libraries simply by listing the libraries (no `-l`). --- Modules/FindMPI.cmake | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/Modules/FindMPI.cmake b/Modules/FindMPI.cmake index 0bf5549..fd9cc19 100644 --- a/Modules/FindMPI.cmake +++ b/Modules/FindMPI.cmake @@ -386,6 +386,13 @@ function (interrogate_mpi_compiler lang try_libs) # Extract the set of libraries to link against from the link command # line string(REGEX MATCHALL "(^| )-l([^\" ]+|\"[^\"]+\")" MPI_LIBNAMES "${MPI_LINK_CMDLINE}") + if(WIN32) + # The intel wrappers on windows link against static versions of the MPI libraries. + # The static libraries are simply listed on the command line without -l. + # For instance: " icl ... impi.lib " + string(REGEX MATCHALL "(^| )([^\" ]+)\\.lib" tmp "${MPI_LINK_CMDLINE}") + list(APPEND MPI_LIBNAMES ${tmp}) + endif() # add the compiler implicit directories because some compilers # such as the intel compiler have libraries that show up @@ -400,6 +407,10 @@ function (interrogate_mpi_compiler lang try_libs) # to link against in an MPI program foreach(LIB ${MPI_LIBNAMES}) string(REGEX REPLACE "^ ?-l" "" LIB ${LIB}) + if(WIN32) + string(REGEX REPLACE "\\.lib$" "" LIB ${LIB}) + endif() + string(STRIP ${LIB} LIB) # MPI_LIB is cached by find_library, but we don't want that. Clear it first. set(MPI_LIB "MPI_LIB-NOTFOUND" CACHE FILEPATH "Cleared" FORCE) find_library(MPI_LIB NAMES ${LIB} HINTS ${MPI_LINK_PATH}) -- 2.6.2.450.g259b5e6 From mantis at public.kitware.com Thu Apr 14 19:57:07 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 14 Apr 2016 19:57:07 -0400 Subject: [cmake-developers] [CMake 0016065]: Building CUDA files fails when compile definitions contains parenthesis Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16065 ====================================================================== Reported By: Guillaume Dumont Assigned To: ====================================================================== Project: CMake Issue ID: 16065 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-14 19:57 EDT Last Modified: 2016-04-14 19:57 EDT ====================================================================== Summary: Building CUDA files fails when compile definitions contains parenthesis Description: When calling cuda_wrap_srcs with the OPTIONS argument or when adding compile definitions via add_definitions the build fails when the definitions contain parentheses. For example, add_definitions("-DFOO_BAR_EXPORT=declspec\(dllimport\)") generates: set(nvcc_flags -DFOO_BAR_EXPORT=declspec(dllimport)) which makes the build fail. When the parentheses are escaped like so: add_definitions("-DFOO_BAR_EXPORT=declspec\\\(dllimport\\\)") we get: set(nvcc_flags -DFOO_BAR_EXPORT=declspec\(dllimport\)) and everything is fine. This is similar to issue: https://cmake.org/Bug/view.php?id=15919 Maybe a similar fix can be applied? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-14 19:57 Guillaume DumontNew Issue ====================================================================== From mantis at public.kitware.com Fri Apr 15 09:45:52 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 15 Apr 2016 09:45:52 -0400 Subject: [cmake-developers] [CMake 0016066]: Compilation error on ./bootstrap Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=16066 ====================================================================== Reported By: alexfc Assigned To: ====================================================================== Project: CMake Issue ID: 16066 Category: CMakeSetup Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-15 09:45 EDT Last Modified: 2016-04-15 09:45 EDT ====================================================================== Summary: Compilation error on ./bootstrap Description: While compiling file cmake-3.5.1/Source/cmPolicies.cxx when launching ./bootstrap.error is : isdigit not declared in this scope Steps to Reproduce: Download and extract cmake-3.5.1 cd cmake-3.5.1 ./boostrap Additional Information: Compilation successful when adding #include in the file cmake-3.5.1/Source/cmPolicies.cxx ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-15 09:45 alexfc New Issue ====================================================================== From mantis at public.kitware.com Fri Apr 15 10:20:09 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 15 Apr 2016 10:20:09 -0400 Subject: [cmake-developers] [CMake 0016067]: $ generator expression evaluates to NEW instead of 1 Message-ID: <6f057de4a7dfbd5d3ab857b37a96b137@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16067 ====================================================================== Reported By: Johannes S. Mueller-Roemer Assigned To: ====================================================================== Project: CMake Issue ID: 16067 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-15 10:20 EDT Last Modified: 2016-04-15 10:20 EDT ====================================================================== Summary: $ generator expression evaluates to NEW instead of 1 Description: When the $ generator expression is used, it should evaluate to 1 if the given policy is new and 0 if it is old, as documented here: https://cmake.org/cmake/help/v3.5/manual/cmake-generator-expressions.7.html However, with the current version of CMake it evaluates to NEW in the true case. I did not test the false case, which probably evaluates to OLD. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-15 10:20 Johannes S. Mueller-RoemerNew Issue ====================================================================== From mantis at public.kitware.com Fri Apr 15 10:56:41 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 15 Apr 2016 10:56:41 -0400 Subject: [cmake-developers] [CMake 0016068]: qt5 autorcc uses wrong output folder Message-ID: <9c13f3692f7cf9904ea7fc07fdf25dd7@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=16068 ====================================================================== Reported By: Martin Haa? Assigned To: ====================================================================== Project: CMake Issue ID: 16068 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-15 10:56 EDT Last Modified: 2016-04-15 10:56 EDT ====================================================================== Summary: qt5 autorcc uses wrong output folder Description: The file qrc_Editor.cpp generated by the qt5 rcc compile step from Editor.qrc is put into CMAKE_BINARY_DIR/CMakeFiles/${target}.dir where it cannot be found/referenced. Files generated by automoc and autoui are put in CMAKE_BINARY_DIR, where they can be found. Inside CMAKE_BINARY_DIR/CMakeFiles/${target}.dir there is another folder ${target}.dir/CMakeFiles/${target}.dir which contains qrc_Editor.cpp.o. To me it looks like cmake start the rcc step with the wrong folder ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-15 10:56 Martin Haa? New Issue ====================================================================== From brad.king at kitware.com Fri Apr 15 11:11:57 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 15 Apr 2016 11:11:57 -0400 Subject: [cmake-developers] Segmentation fault during run cmake 3.5.1 In-Reply-To: References: Message-ID: <571104BD.8010003@kitware.com> On 04/15/2016 11:09 AM, Bartosz Kosiorek wrote: > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x00000000005bb427 in cmTarget::GetProperty(std::string const&, cmMakefile*) const () Is this https://cmake.org/Bug/view.php?id=16044 ? -Brad From brad.king at kitware.com Fri Apr 15 11:55:13 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 15 Apr 2016 11:55:13 -0400 Subject: [cmake-developers] Segmentation fault during run cmake 3.5.1 In-Reply-To: References: <571104BD.8010003@kitware.com> Message-ID: <57110EE1.7030900@kitware.com> On 04/15/2016 11:44 AM, Bartosz Kosiorek wrote: > How I could get souce code for CMAKE 3.5.2 for testing purposes ? $ git clone -b release https://cmake.org/cmake.git -Brad From brad.king at kitware.com Fri Apr 15 13:44:29 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 15 Apr 2016 13:44:29 -0400 Subject: [cmake-developers] FindMPI with intel MPI wrappers In-Reply-To: <20160414202347.GD3177@ivyamd.txcorp.com> References: <20160414202347.GD3177@ivyamd.txcorp.com> Message-ID: <5711287D.3070601@kitware.com> On 04/14/2016 04:23 PM, Dominic Meiser wrote: > I'm attaching a couple of patches to deal with this. Are patches > to the mailing list still the recommended way to submit changes? > Or are pull requests on github preferred? Thanks! Posting here is perfect. See CONTRIBUTING.rst. Applied: FindMPI: Recognize /LIBPATH for specification of linker paths. https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c4417b09 FindMPI: Recognize `.lib` file names for specification of link libraries https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2a99fae1 Please check the /LIBPATH fix because I tweaked it a bit from your original. -Brad From robert.maynard at kitware.com Fri Apr 15 13:48:50 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 15 Apr 2016 13:48:50 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.5.2 available for download Message-ID: We are pleased to announce that CMake 3.5.2 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.5.2 since 3.5.1: Brad King (6): Fix lookup of an ALIAS target outside aliased target's directory (#16044) Rename local target lookup methods to clarify purpose cmFortranParser: Skip #line directives that do not name files Ninja: Fix detection of custom command symbolic outputs Ninja: Restat custom command byproducts even with a SYMBOLIC output (#16049) CMake 3.5.2 Gregor Jasny (2): Xcode: Fixup XCTest bundle location for Xcode 7.3 ASM: Add missing placeholder for "compile" rules Pierrick Koch (1): FindGSL: Fix typo in documentation From dmeiser at txcorp.com Fri Apr 15 14:05:28 2016 From: dmeiser at txcorp.com (Dominic Meiser) Date: Fri, 15 Apr 2016 14:05:28 -0400 Subject: [cmake-developers] FindMPI with intel MPI wrappers In-Reply-To: <5711287D.3070601@kitware.com> References: <20160414202347.GD3177@ivyamd.txcorp.com> <5711287D.3070601@kitware.com> Message-ID: <20160415180528.GB13646@ivyamd.txcorp.com> On Fri, Apr 15, 2016 at 01:44:29PM -0400, Brad King wrote: > On 04/14/2016 04:23 PM, Dominic Meiser wrote: > > I'm attaching a couple of patches to deal with this. Are patches > > to the mailing list still the recommended way to submit changes? > > Or are pull requests on github preferred? > > Thanks! Posting here is perfect. See CONTRIBUTING.rst. > > Applied: > > FindMPI: Recognize /LIBPATH for specification of linker paths. > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c4417b09 > > FindMPI: Recognize `.lib` file names for specification of link libraries > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2a99fae1 > > Please check the /LIBPATH fix because I tweaked it a bit from > your original. Looks much cleaner, thanks. I tested FindMPI.cmake from current `next` branch and it all appears to work. Cheers, Dominic > > -Brad -- Dominic Meiser Tech-X Corporation - 5621 Arapahoe Avenue - Boulder, CO 80303 From mantis at public.kitware.com Sat Apr 16 03:49:05 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 16 Apr 2016 17:49:05 +1000 Subject: [cmake-developers] [CMake 0016069]: Behaviour does not match documentation for policy CMP0048 Message-ID: <5b0ae688894abe8795e460db4355e61a@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=16069 ====================================================================== Reported By: Craig Scott Assigned To: ====================================================================== Project: CMake Issue ID: 16069 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-16 17:49 AEST Last Modified: 2016-04-16 17:49 AEST ====================================================================== Summary: Behaviour does not match documentation for policy CMP0048 Description: The policy documentation for CMP0048 says this: "This policy was introduced in CMake version 3.0. CMake version 3.5.2 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly." In my testing, however, no such warning is issued and the default appears to be NEW, not OLD. Steps to Reproduce: The following minimal CMakeLists.txt demonstrates the problem: cmake_minimum_required(VERSION 3.5.2) cmake_policy(GET CMP0048 isOn) message("isOn = ${isOn}") project(proj VERSION 1.2.3) Changing the minimum required version doesn't seem to make any difference. Additional Information: If you explicitly set the policy for CMP0048 to OLD, then the expected error does occur when the project() command includes a VERSION specification. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-16 17:49 Craig Scott New Issue ====================================================================== From seblist at xwmw.org Sat Apr 16 07:41:47 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Sat, 16 Apr 2016 13:41:47 +0200 Subject: [cmake-developers] Automoc same source - More thoughts In-Reply-To: <57100656.1000207@xwmw.org> References: <570CC695.1050202@xwmw.org> <570CDF61.8020508@xwmw.org> <570D16FC.1080702@xwmw.org> <570D48AA.8040007@xwmw.org> <570F8EC9.7060205@kitware.com> <57100656.1000207@xwmw.org> Message-ID: <571224FB.1050107@xwmw.org> Am 14.04.2016 um 23:06 schrieb Sebastian Holtermann: > >> These two hunks look like error checks added to the existing logic. >> Please split these out into preceding commits with their own messages >> explaining the new errors. Please also include a >> >> Help/release/dev/automoc-diagnostics.rst >> >> file with a release note explaining the new diagnostics. >> > > Wow, this turned into a git learning session for me. > Git is as awesome as it is hard. > > I've split the patch into three as suggested. > Please do not commit. After checking a greater picture and https://cmake.org/Bug/view.php?id=16068 I found that an adapted more generic test would help with qrc and ui file generation, too. I'm going to start a new thread next week. -Sebastian From Geoffrey.Viola at asirobots.com Sun Apr 17 16:22:06 2016 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Sun, 17 Apr 2016 20:22:06 +0000 Subject: [cmake-developers] 0016046: GHS Multi Generator: duplicate object file names Message-ID: Attached is a patch to fix the bug tracked at https://cmake.org/Bug/view.php?id=16046. It adds a special source property to set the obj filename for the GHS MULTI generator. It is necessary, because GHS MULTI has a bug where it can't compile two source files with the same filenames. Geoff 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: 0001-GHS-MULTI-add-object_file-source-property.patch Type: application/octet-stream Size: 2534 bytes Desc: 0001-GHS-MULTI-add-object_file-source-property.patch URL: From mantis at public.kitware.com Sun Apr 17 17:52:12 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 17 Apr 2016 17:52:12 -0400 Subject: [cmake-developers] [CMake 0016070]: Malformed newline sequences from externally executed processes Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=16070 ====================================================================== Reported By: Nils Gladitz Assigned To: ====================================================================== Project: CMake Issue ID: 16070 Category: (No Category) Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-17 17:52 EDT Last Modified: 2016-04-17 17:52 EDT ====================================================================== Summary: Malformed newline sequences from externally executed processes Description: When running ctest in script mode verbosely e.g. the executed build command produces "\r\n" newlines. When ctest forwards that output to stdout/stderr these "\r\n" newlines turn into "\r\r\n". The same happens when using execute_process() without the OUTPUT_/ERROR_ options. When using the OUTPUT_/ERROR_ VARIABLE/FILE options "\r" newlines are explicitly stripped resulting in correct/expected output. While the windows console and e.g. notepad interpret these "\r\r\n" newline sequences as a single newline other tools (e.g. buildbot) interpret such a sequence as two newlines. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-17 17:52 Nils Gladitz New Issue ====================================================================== From roman.wueger at gmx.at Mon Apr 18 10:20:52 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Mon, 18 Apr 2016 16:20:52 +0200 Subject: [cmake-developers] Patch for BundleUtilities to ignore specified files Message-ID: Hello, attached is a patch with which files can be specified which should not be resolved. Best regards Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-BundleUtilities-Add-optional-parameter-to-ignore-spe.patch Type: application/octet-stream Size: 8715 bytes Desc: not available URL: -------------- next part -------------- From brad.king at kitware.com Mon Apr 18 11:28:06 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 18 Apr 2016 11:28:06 -0400 Subject: [cmake-developers] 0016046: GHS Multi Generator: duplicate object file names In-Reply-To: References: Message-ID: <5714FD06.9050507@kitware.com> On 04/17/2016 04:22 PM, Geoffrey Viola wrote: > Attached is a patch to fix the bug tracked at https://cmake.org/Bug/view.php?id=16046. > It adds a special source property to set the obj filename for the GHS MULTI generator. > It is necessary, because GHS MULTI has a bug where it can?t compile two source files > with the same filenames. Thanks. However, I do not think it should be the project's responsibility to set the OBJECT_FILE property for this. CMake's VS IDE generator has the same problem so we generate specific object file names automatically when the defaults will not be unique. See logic here: cmLocalVisualStudioGenerator::ComputeObjectFilenames https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalVisualStudioGenerator.cxx;hb=v3.5.2#l41 and use of AddExplicitObjectName in particular. -Brad From brad.king at kitware.com Mon Apr 18 11:28:11 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 18 Apr 2016 11:28:11 -0400 Subject: [cmake-developers] Patch for BundleUtilities to ignore specified files In-Reply-To: References: Message-ID: <5714FD0B.6040502@kitware.com> On 04/18/2016 10:20 AM, Roman W?ger wrote: > attached is a patch with which files can be specified which should not be resolved. Thanks. Please include a documentation update too. -Brad From brad.king at kitware.com Mon Apr 18 11:37:23 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 18 Apr 2016 11:37:23 -0400 Subject: [cmake-developers] CMake API for warnings In-Reply-To: <570DD705.5020306@yahoo.com> References: <56F85BE4.2070503@yahoo.com> <56F93A40.8090904@kitware.com> <56FA7E9A.7020704@yahoo.com> <56FA9014.70106@kitware.com> <56FA9E26.2090704@yahoo.com> <56FD2835.60301@kitware.com> <56FD5488.9010706@yahoo.com> <5703C5A4.6090506@kitware.com> <5703FE0C.5060401@yahoo.com> <570D37B5.6010502@kitware.com> <570DD705.5020306@yahoo.com> Message-ID: <5714FF33.4020700@kitware.com> On 04/13/2016 01:20 AM, Ruslan Baratov wrote: >>> new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may control this. >> I'd prefer to avoid extra knobs if possible. > Okay, what about CMake warning for developer? (cmake -Wdev/cmake -Wno-dev) Sure. >>> You mean this: >>> >>> compatibility-c++98=off >>> inline=off >>> special-members=off >>> catch-semantic-changed=off >>> covered-switch-default=off >>> inherits-via-dominance=off >>> name-length-exceeded=off >>> padded=off >>> this-used-in-init=off >>> EVERYTHING=on >>> EVERYTHING=error >>> >>> versus this one: >>> >>> DISABLE >>> compatibility-c++98 >>> inline >>> special-members >>> catch-semantic-changed >>> covered-switch-default >>> inherits-via-dominance >>> name-length-exceeded >>> padded >>> this-used-in-init >>> ENABLE >>> EVERYTHING >>> TREAT_AS_ERROR >>> EVERYTHING [snip] > All I'm trying to say about ENABLE/DISABLE lists is that if user will > have N warnings to enable and M warnings to disable he will not write N > times *=on and M times *=off and probably will just create helper functions: I realized there is a difference between the low-level plumbing representation of this in the property values and the porcelain provided by a new command like target_compile_warnings. I've been thinking of the plumbing and you've been thinking of the porcelain. They do not have to be the same. The plumbing could even use 0/1 instead of off/on to work better with a genex. We need to work out designs for both such that they can work together and the command can easily map to the internal property representation. Perhaps having separate properties for _ENABLE, _DISABLE, and _ERROR is the way to go, perhaps not. Either way we can diagnose inconsistent value combinations. > so how about this: > > compile_warnings(DISABLE foo CONFIGURATION Debug) > compile_warnings(ERROR foo CONFIGURATION NOT Debug) I'd prefer to use generator expressions for the per-config values instead of an explicit CONFIGURATION porcelain, at least at first. > I'm pretty sure all compilers have flag to enable all kind of available > warnings (it may not call "All", e.g. -Weverything for Clang). Even if > there is such compiler we can use maximum level + adding extra warnings > explicitly. There must be abstracted group that allow to enable > everything. Okay. We can document the "everything" mode as meaning CMake will do a best-effort to add all warnings the compiler can provide, at least without resorting to adding lots of individual flags. Thanks, -Brad From roman.wueger at gmx.at Tue Apr 19 02:03:29 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Tue, 19 Apr 2016 08:03:29 +0200 Subject: [cmake-developers] Patch for BundleUtilities to ignore specified files In-Reply-To: <5714FD0B.6040502@kitware.com> References: <5714FD0B.6040502@kitware.com> Message-ID: <433E2230-A355-4F0B-BBF0-91074D09F5EB@gmx.at> Hello Brad, attached is an updated patch. Regards Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-BundleUtilities-Add-optional-parameter-to-ignore-spe.patch Type: application/octet-stream Size: 10093 bytes Desc: not available URL: -------------- next part -------------- > Am 18.04.2016 um 17:28 schrieb Brad King : > >> On 04/18/2016 10:20 AM, Roman W?ger wrote: >> attached is a patch with which files can be specified which should not be resolved. > > Thanks. Please include a documentation update too. > > -Brad > From seblist at xwmw.org Tue Apr 19 11:09:54 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Tue, 19 Apr 2016 17:09:54 +0200 Subject: [cmake-developers] Autogen subdirectories patches Message-ID: <57164A42.6030407@xwmw.org> Hello again, I've prepared a set of patches that address https://cmake.org/Bug/view.php?id=12873 https://cmake.org/Bug/view.php?id=16068 They introduce - same name collision checks during moc/qrc/ui generation - moc/qrc generation in subdirectories to support sources with the name in different subdirectories - A test for equally named sources in different subdirectories Please review. -Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: autogen_patches_2016-04-19-1.tar.gz Type: application/gzip Size: 13699 bytes Desc: not available URL: From mantis at public.kitware.com Tue Apr 19 13:02:04 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 19 Apr 2016 13:02:04 -0400 Subject: [cmake-developers] [CMake 0016071]: CMake should map /Fd to COMPILE_PDB_NAME for static libraries Message-ID: <46adec2d6a00db4c6dec0163d8741cac@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16071 ====================================================================== Reported By: Itai Seggev Assigned To: ====================================================================== Project: CMake Issue ID: 16071 Category: CMake Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-19 13:02 EDT Last Modified: 2016-04-19 13:02 EDT ====================================================================== Summary: CMake should map /Fd to COMPILE_PDB_NAME for static libraries Description: This is a follow up to https://cmake.org/Bug/view.php?id=14763 and its predecessors https://cmake.org/Bug/view.php?id=14060 / https://cmake.org/Bug/view.php?id=14062 /Fd was separated from PDB_NAME, because normally what we want is the linker pdb. However, if our final product is the static library, then we do want to the compiler PDB file, so COMPILE_PDB_NAME was added. Yet, a mapping was not added between COMPILE_PDB_NAME and /Fd. The result is /Fd is added to compile flags but COMPILE_PDB_NAME remains at its default value, and an inconsistency is created between Visual Studio and NMake generators. For the former, the flag is honored, but for the latter it is overridden by the NMake file's own specification of /Fd. Thus, for dlls and exes, you can simply add /PDB to the link flags, but for static libraries you must manually manipulate the COMPILE_PDB_NAME property for the target. I think that /Fd, certainly for static libraries which have no link step, should be mapped to COMPILE_PDB_NAME. Steps to Reproduce: Create a minimal CMakeLists.txt like the following: project(foo) add_library(myLib STATIC myLib.c) target_compile_options(myLib PUBLIC $<$:/Zi /FdmyLib.pdb>) Generate a NMake Makefiles build system and build. You will see cl : Command line warning D9025 : overriding '/FdmyLib.pdb' with '/FdCMakeFiles\myLib.dir/' and the PDB file is indeed CMakeFiles\myLib.dir\vc120.pdb. If you generate a Visual Studio project and build, there is no warning and the pdb file is .\myLib.pdb. And indeed the pdb file will be ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-19 13:02 Itai Seggev New Issue ====================================================================== From brad.king at kitware.com Tue Apr 19 13:27:26 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 19 Apr 2016 13:27:26 -0400 Subject: [cmake-developers] Patch for BundleUtilities to ignore specified files In-Reply-To: <433E2230-A355-4F0B-BBF0-91074D09F5EB@gmx.at> References: <5714FD0B.6040502@kitware.com> <433E2230-A355-4F0B-BBF0-91074D09F5EB@gmx.at> Message-ID: <57166A7E.7070202@kitware.com> On 04/19/2016 02:03 AM, Roman W?ger wrote: > attached is an updated patch. Thanks. Applied: BundleUtilities: Add optional parameter to ignore specified files https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=26c92d50 -Brad From brad.king at kitware.com Tue Apr 19 13:28:35 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 19 Apr 2016 13:28:35 -0400 Subject: [cmake-developers] Autogen subdirectories patches In-Reply-To: <57164A42.6030407@xwmw.org> References: <57164A42.6030407@xwmw.org> Message-ID: <57166AC3.7000302@kitware.com> On 04/19/2016 11:09 AM, Sebastian Holtermann wrote: > https://cmake.org/Bug/view.php?id=12873 > https://cmake.org/Bug/view.php?id=16068 > > They introduce > - same name collision checks during moc/qrc/ui generation > - moc/qrc generation in subdirectories to support > sources with the name in different subdirectories > - A test for equally named sources in different subdirectories > > Please review. Thanks! I've applied them locally and merged the cleanup/refactoring commits to 'next' for testing first. Once those test cleanly I'll move on to the rest. -Brad From seblist at xwmw.org Tue Apr 19 16:02:08 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Tue, 19 Apr 2016 22:02:08 +0200 Subject: [cmake-developers] Autogen subdirectories patches In-Reply-To: <57166AC3.7000302@kitware.com> References: <57164A42.6030407@xwmw.org> <57166AC3.7000302@kitware.com> Message-ID: <57168EC0.8000600@xwmw.org> Am 19.04.2016 um 19:28 schrieb Brad King: > On 04/19/2016 11:09 AM, Sebastian Holtermann wrote: >> https://cmake.org/Bug/view.php?id=12873 >> https://cmake.org/Bug/view.php?id=16068 >> >> They introduce >> - same name collision checks during moc/qrc/ui generation >> - moc/qrc generation in subdirectories to support >> sources with the name in different subdirectories >> - A test for equally named sources in different subdirectories >> >> Please review. > > Thanks! I've applied them locally and merged the cleanup/refactoring > commits to 'next' for testing first. Once those test cleanly I'll move > on to the rest. > Ok, thanks. -Sebastian From rleigh at codelibre.net Tue Apr 19 18:02:33 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Tue, 19 Apr 2016 23:02:33 +0100 Subject: [cmake-developers] [PATCH] Always define Boost::boost imported target Message-ID: <5716AAF9.3060404@codelibre.net> For https://cmake.org/Bug/view.php?id=16057 I have merged the boost-import-default branch into next for testing. This includes a unit test to verify that the basic boost headers work in the absence of COMPONENTS being specified with find_package. Regards, Roger -- Dr Roger Leigh -- Open Microscopy Environment Wellcome Trust Centre for Gene Regulation and Expression, School of Life Sciences, University of Dundee, Dow Street, Dundee DD1 5EH Scotland UK Tel: (01382) 386364 From ruslan_baratov at yahoo.com Wed Apr 20 09:50:54 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 20 Apr 2016 20:50:54 +0700 Subject: [cmake-developers] CMake API for warnings In-Reply-To: <5714FF33.4020700@kitware.com> References: <56F85BE4.2070503@yahoo.com> <56F93A40.8090904@kitware.com> <56FA7E9A.7020704@yahoo.com> <56FA9014.70106@kitware.com> <56FA9E26.2090704@yahoo.com> <56FD2835.60301@kitware.com> <56FD5488.9010706@yahoo.com> <5703C5A4.6090506@kitware.com> <5703FE0C.5060401@yahoo.com> <570D37B5.6010502@kitware.com> <570DD705.5020306@yahoo.com> <5714FF33.4020700@kitware.com> Message-ID: <5717893E.1040304@yahoo.com> So here is a summary of this feature so far: Introducing new 3 functions for controlling compiler warnings: 1) add_compile_warnings * similar to add_definitions, add_compile_options * modify COMPILE_WARNINGS directory property (append) 2) target_compile_warnings * similar to target_compile_options, target_compile_definitions * modify COMPILE_WARNINGS target property (append) 3) source_files_compile_warnings * similar to set_source_files_properties * modify COMPILE_WARNINGS sources property (append) Same API for all: *_compile_warnings( DISABLE # add =off to COMPILE_WARNINGS property ENABLE # add =on to COMPILE_WARNINGS property TREAT_AS_ERROR # add =error to COMPILE_WARNINGS property ) General warning-id's: * all (compiler specific "all", e.g. /Wall or -Wall) * default * level * none * everything (all possible warnings for compiler, if there is no such option use maximum level plus some warnings explicitly) Group warnings-id's: * inline # MSVC: 4711 (automatic-inline), 4714 (force-not-inlined), 4710 (not-inlined), 4514 (unreferenced-inline) * compatibility-c++98 # Clang: `-Wc++98-compat`, `-Wc++98-compat-pedantic` Simple warning-id examples: * undef # Clang/GCC: `-Wunder`; MSVC: 4668 * shift-sign-overflow # Clang: `-Wshift-sign-overflow`, GCC: nothing, MSVC: nothing * inherits-via-dominance # Clang/GCC: nothing, MSVC: 4250 Since I'm expecting cross-platform behaviour here I think that such general warnings-id like 'all', 'default', 'level' might be confusing since different compilers with the same levels will define different groups of warnings (no tests/examples, I'm just pretty sure about that). So I'm afraid we will end with code like this: if(MSVC) add_compile_warnings(ENABLE level3) else() add_compile_warnings(ENABLE level4) endif() I think that goal of this feature is to avoid such compiler specific switches. Note that there is no such problem with 'none', 'everything', group/simple warning-id. Properties will be set in form =on|off|error, e.g.: add_compile_warnings(DISABLE undef unused ENABLE inline TREAT_AS_ERROR everything) will set COMPILE_WARNINGS directory property to: undef=off unused=off inline=on everything=error Generator expressions can be used for config-specific warnings: set(debug_off $<$:off>) set(non_debug_error $<$>:error>) set_directory_properties(... COMPILE_WARNINGS undef=${debug_off}${non_debug_error} ${old_warnings}) In case of any conflicts return CMake warning for developer message (cmake -Wdev/cmake -Wno-dev). Implementation details: Abstracted unmodified will be kept until the very last point when we need real flags generated. E.g. do not expand 'everything' on any step since this will mask possible configuration errors: add_compile_warnings(DISABLE all ENABLE undef) # OK: turn off everything except 'undef' add_compile_warnings(DISABLE warning-A warning-B ... undef ... warning-Y warning-Z ENABLE undef) # ERROR: user want undef=on and undef=off Directory properties affect targets and sources, target properties affect sources of this target. E.g.: add_compile_warnings(DISABLE undef) target_compile_warnings(foo DISABLE unused) effectively equivalent to: target_compile_warnings(foo DISABLE undef unused) Question: do we need to control this? probably by 'target_compile_warnings(foo DISABLE unused IGNORE DIRECTORY)' ? may expand to nothing in case warning make no sense for current language or warning not implemented by compiler: add_compile_warnings(ENABLE switch-enum) add_executable(foo foo.c) # C target, no warning will be added add_executable(boo boo.cpp) # C++ target, -Wswitch-enum will be added add_compile_warning(ENABLE inherits-via-dominance) add_executable(foo foo.cpp) # Clang/GCC: nothing, MSVC: 4250 After this feature implemented we need to introduce new policy to avoid adding warnings flags to CMAKE_CXX_FLAGS by default (e.g. "/W3" added by default for Visual Studio). Warnings should not be propagated via INTERFACE because unlike definitions or other compiler flags they doesn't affect final binary or compatibility. Questions that is not touched so far: On 29-Mar-16 22:42, Ruslan Baratov wrote: > One more note. Properties is a good abstraction and works great for the native CMake project. But there is a tricky scenario about them - when we need to create ExternalProject_Add for the non-CMake project. > E.g. when I have CMAKE_POSITION_INDEPENDENT_CODE variable set to `YES` I need to add `-fPIC` to the flags manually, or check `CXX_STANDARD 11` and add `-std=c++11`. I guess I can handle such simple cases but I can predict that for warnings it will be a huge pain. > How CMake can help me avoid violating DRY? Would be nice to have this one. Like 'expand_compiler_flags(cxxflags LANGUAGE CXX CONFIGURATION Debug)' => add 'CXXFLAGS=${cxxflags}' to ExternalProject_Add step of autotools based project. On 31-Mar-16 04:31, Simon Richter wrote: > > With my Linux distro hat on: please don't force warning levels from > inside projects. > > Packages are often automatically compiled on different platforms, and we > do want to know about third party modules generating warnings on the > more obscure ones where sizeof(long) < sizeof(void *), because no human > will ever have more than a casual look at the build logs unless there > are warnings there that do not appear on other platforms. Is it possible in general to control warnings globally? Imagine I have target that should ignore all warnings for any reason. If you able to control warnings globally this target will generate tons of useless messages. How to enable warnings for all targets except this one? Ruslo From mantis at public.kitware.com Wed Apr 20 12:43:57 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 20 Apr 2016 12:43:57 -0400 Subject: [cmake-developers] [CMake 0016072]: flex macro can't handle parenthesis in path Message-ID: <04758ae67de5afebf4e02098f5c56d30@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=16072 ====================================================================== Reported By: Raymond Langer Assigned To: ====================================================================== Project: CMake Issue ID: 16072 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-20 12:43 EDT Last Modified: 2016-04-20 12:43 EDT ====================================================================== Summary: flex macro can't handle parenthesis in path Description: The FLEX_TARGET macro doesn't escape parenthesis in the output argument for flex. Steps to Reproduce: In a project that uses flex I used the build directory 'Build 123()'. Additional Information: Maybe it's possible to use double quotes. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-20 12:43 Raymond Langer New Issue ====================================================================== From seblist at xwmw.org Thu Apr 21 03:14:01 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Thu, 21 Apr 2016 09:14:01 +0200 Subject: [cmake-developers] Autogen subdirectories patches In-Reply-To: <57166AC3.7000302@kitware.com> References: <57164A42.6030407@xwmw.org> <57166AC3.7000302@kitware.com> Message-ID: <57187DB9.7060904@xwmw.org> Am 19.04.2016 um 19:28 schrieb Brad King: > On 04/19/2016 11:09 AM, Sebastian Holtermann wrote: >> https://cmake.org/Bug/view.php?id=12873 >> https://cmake.org/Bug/view.php?id=16068 >> >> They introduce >> - same name collision checks during moc/qrc/ui generation >> - moc/qrc generation in subdirectories to support >> sources with the name in different subdirectories >> - A test for equally named sources in different subdirectories >> >> Please review. > > Thanks! I've applied them locally and merged the cleanup/refactoring > commits to 'next' for testing first. Once those test cleanly I'll move > on to the rest. It is good too see the patches made it into the next branch. Thanks and sorry for the wrong indentation btw.. Now there is another issue I have a partially fix for. As of now all included mocs and uis get generated in CMAKE_CURRENT_BINARY_DIR/ because they must be within INCLUDE_DIRECTORIES. I think a more robust approach would be to generate them in CMAKE_CURRENT_BINARY_DIR/TARGET_automoc.dir/ and to add the _automoc.dir to INCLUDE_DIRECTORIES. I've attached a patch that does does so - it is relative to current "next" branch. It is incomplete though because I didn't manage to get CMAKE_CURRENT_BINARY_DIR/TARGET_automoc.dir/ into INCLUDE_DIRECTORIES in Source/cmQtAutoGeneratorInitializer.cxx. (GetAutogenTargetBuildDir() in Source/cmQtAutoGeneratorInitializer.cxx) If someone could do that or give me pointers on how to do it then this could be another improvement. -Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Autogen-Generate-included-moc-and-ui-files-in-TARGET.patch Type: text/x-patch Size: 2203 bytes Desc: not available URL: From mantis at public.kitware.com Thu Apr 21 03:38:50 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 21 Apr 2016 03:38:50 -0400 Subject: [cmake-developers] [CMake 0016073]: InstallRequiredSystemLibraries needs updating for MSVS2015 Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16073 ====================================================================== Reported By: Lewoco Assigned To: ====================================================================== Project: CMake Issue ID: 16073 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-21 03:38 EDT Last Modified: 2016-04-21 03:38 EDT ====================================================================== Summary: InstallRequiredSystemLibraries needs updating for MSVS2015 Description: Many system DLL's required by MSVS2015 are not identified by InstallRequiredSystemLibraries. Steps to Reproduce: - add_executable a simple hello world - Use InstallRequiredSystemLibraries to install the required libraries - Build an installer using WiX (or whatever) - Install it on Windows 7 (no updates) BUG: executable cannot be run because of missing DLL's. Note: - Updates might have helped but I didn't try it. - Probably also affects Windows 8/8.1. - Might not affect Windows 10? (see link) https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/ Additional Information: Right now I'm using the following code to select the additional required libraries. Please integrate something similar into InstallRequiredSystemLibraries: # InstallRequiredSystemLibraries does not properly support MSVS 14 yet, so do it manually. unset(CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_DEBUG) unset(CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_RELEASE) if(DEFINED MSVC_VERSION AND NOT MSVC_VERSION LESS 1900) # Internal: Architecture-appropriate library directory names. if("${CMAKE_VS_PLATFORM_NAME}" STREQUAL "ARM") set(_winsdk_arch8 arm) # what the WDK for Win8+ calls this architecture else() if(CMAKE_SIZEOF_VOID_P MATCHES "8") set(_winsdk_arch8 x64) # what the WDK for Win8+ calls this architecture else() set(_winsdk_arch8 x86) # what the WDK for Win8+ calls this architecture endif() endif() # The CRT is distributed with MSVS. get_filename_component(MSVS_DIR "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\14.0;ShellFolder]" ABSOLUTE) # As of MSVC 19 the CRT depends on the 'univeral' CRT (which is part of Windows development kit 10 and above). # http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx get_filename_component(WINDOWS_KIT_DIR "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows Kits\\Installed Roots;KitsRoot10]" ABSOLUTE) file(GLOB CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_DEBUG "${MSVS_DIR}/VC/redist/debug_nonredist/${_winsdk_arch8}/Microsoft.VC140.DebugCRT/*.dll" "${WINDOWS_KIT_DIR}/Redist/ucrt/DLLs/${_winsdk_arch8}/api-ms-win-*.dll" "${WINDOWS_KIT_DIR}/bin/${_winsdk_arch8}/ucrt/*.dll" ) file(GLOB CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_RELEASE "${MSVS_DIR}/VC/redist/${_winsdk_arch8}/Microsoft.VC140.CRT/*.dll" "${WINDOWS_KIT_DIR}/Redist/ucrt/DLLs/${_winsdk_arch8}/*.dll" ) endif() ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-21 03:38 Lewoco New Issue ====================================================================== From mantis at public.kitware.com Thu Apr 21 09:58:10 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 21 Apr 2016 09:58:10 -0400 Subject: [cmake-developers] [CMake 0016074]: Setting link_directories in toolchain file is only used for compiler tests, and inhibits effect of repeating the command Message-ID: <380135a11717dbfad4a8fadb8c1a0bb8@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16074 ====================================================================== Reported By: Antonio Assigned To: ====================================================================== Project: CMake Issue ID: 16074 Category: (No Category) Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-21 09:58 EDT Last Modified: 2016-04-21 09:58 EDT ====================================================================== Summary: Setting link_directories in toolchain file is only used for compiler tests, and inhibits effect of repeating the command Description: In the attached example, TOOLCHAIN FILE: link_directories("D:/abcd") CMAKELISTS.TXT: project(dummyProject) cmake_minimum_required(VERSION 3.4) link_directories("D:/abcd") link_directories("D:/efgh") add_library(dummyTarget SHARED dummy.cpp) At linking stage, only the "-LD:/efgh" will be there: cmd.exe /C "cd . && -shared -o libdummyTarget.dll -Wl,--out-implib,libdummyTarget.dll.a -Wl,--major-image-version,0,--minor-image-version,0 CMakeFiles/dummyTarget.dir/dummy.cpp.obj -LD:/efgh -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ." Note: In the CMakeOutput.log file is possible to see that -LD:/abcd is used in the preliminary compiler tests. Use case: I am dealing with a toolchain where the std library is in a specific location, and to pass the preliminary cmake compiler tests I must set the std library location with a link_directories command. Since it is toolchain specific, it makes sense to set in the toolchain file. I can pass the compiler tests if I call `link_directories` in the toolchain file. The only workaround I could find so far was to directly set the flag (still in the toolchain file): # SET(CMAKE_EXE_LINKER_FLAGS "-LD:/abcd") # SET(CMAKE_SHARED_LINKER_FLAGS "-LD:/abcd") # SET(CMAKE_MODULE_LINKER_FLAGS "-LD:/abcd") Steps to Reproduce: 1) Take the project in attachment 2) Configure with the attached toolchain, for example using ninja generator 3a) With ninja, run ninja -v to see the command line 3b) With make, run make.exe VERBOSE=1 to see the command line ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-21 09:58 Antonio New Issue 2016-04-21 09:58 Antonio File Added: CMakeBugProject.zip ====================================================================== From mantis at public.kitware.com Fri Apr 22 03:53:29 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 22 Apr 2016 03:53:29 -0400 Subject: [cmake-developers] [CMake 0016075]: Play jeopardy theme during compilation Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16075 ====================================================================== Reported By: Richard Wiedenh?ft Assigned To: ====================================================================== Project: CMake Issue ID: 16075 Category: CMake Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-22 03:53 EDT Last Modified: 2016-04-22 03:53 EDT ====================================================================== Summary: Play jeopardy theme during compilation Description: I'd like to request the addition of a command line flag that enables playback of the Jeopardy theme while a compilation is running. This should be trivially possible using mplayer (on Linux at least). Reasons: - It would be awesome ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-22 03:53 Richard Wiedenh?ftNew Issue ====================================================================== From brad.king at kitware.com Fri Apr 22 09:36:54 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 22 Apr 2016 09:36:54 -0400 Subject: [cmake-developers] CMake API for warnings In-Reply-To: <5717893E.1040304@yahoo.com> References: <56F85BE4.2070503@yahoo.com> <56F93A40.8090904@kitware.com> <56FA7E9A.7020704@yahoo.com> <56FA9014.70106@kitware.com> <56FA9E26.2090704@yahoo.com> <56FD2835.60301@kitware.com> <56FD5488.9010706@yahoo.com> <5703C5A4.6090506@kitware.com> <5703FE0C.5060401@yahoo.com> <570D37B5.6010502@kitware.com> <570DD705.5020306@yahoo.com> <5714FF33.4020700@kitware.com> <5717893E.1040304@yahoo.com> Message-ID: <571A28F6.8070409@kitware.com> On 04/20/2016 09:50 AM, Ruslan Baratov wrote: > 1) add_compile_warnings > * similar to add_definitions, add_compile_options > * modify COMPILE_WARNINGS directory property (append) > 2) target_compile_warnings > * similar to target_compile_options, target_compile_definitions > * modify COMPILE_WARNINGS target property (append) > 3) source_files_compile_warnings > * similar to set_source_files_properties > * modify COMPILE_WARNINGS sources property (append) Sounds good. Note that cmTarget has dedicated storage with backtrace information for other build system properties. Please use the same pattern for these. I also suggest getting the directory/target level working first and work on source files later. The infrastructure for the latter is not as mature so it may need more work. > *_compile_warnings( > > DISABLE # add =off to COMPILE_WARNINGS > property > ENABLE # add =on to COMPILE_WARNINGS > property > TREAT_AS_ERROR # add =error to > COMPILE_WARNINGS property > ) Sounds good. > * all (compiler specific "all", e.g. /Wall or -Wall) > * default > * level > * none > * everything (all possible warnings for compiler, if there is no such > option use maximum level plus some warnings explicitly) Okay. Let's drop level for now for the reason you outlined. We can always add it later. > Properties will be set in form =on|off|error, e.g.: > > add_compile_warnings(DISABLE undef unused ENABLE inline TREAT_AS_ERROR everything) > > will set COMPILE_WARNINGS directory property to: > > undef=off unused=off inline=on everything=error Good. > In case of any conflicts return CMake warning for developer message > (cmake -Wdev/cmake -Wno-dev). Good. > Directory properties affect targets and sources, target properties > affect sources of this target. E.g.: > > add_compile_warnings(DISABLE undef) > target_compile_warnings(foo DISABLE unused) > > effectively equivalent to: > > target_compile_warnings(foo DISABLE undef unused) > > Question: do we need to control this? probably by > 'target_compile_warnings(foo DISABLE unused IGNORE DIRECTORY)' ? It should be possible to merge the directory/target/source settings with proper precedence. I don't understand your example well enough to see what "IGNORE DIRECTORY" would mean. Either way, such information needs to be encoded somehow in the property values. > may expand to nothing in case warning make no sense for > current language or warning not implemented by compiler: Okay. > After this feature implemented we need to introduce new policy to avoid > adding warnings flags to CMAKE_CXX_FLAGS by default (e.g. "/W3" added by > default for Visual Studio). Yes. > Warnings should not be propagated via INTERFACE because unlike > definitions or other compiler flags they doesn't affect final binary or > compatibility. Okay. > On 29-Mar-16 22:42, Ruslan Baratov wrote: >> One more note. Properties is a good abstraction and works great for >> the native CMake project. But there is a tricky scenario about them - >> when we need to create ExternalProject_Add for the non-CMake project. > > Would be nice to have this one. This is beyond the scope of this change and affects all flags, so let's defer this for a later time. > Is it possible in general to control warnings globally? Imagine I have > target that should ignore all warnings for any reason. If you able to > control warnings globally this target will generate tons of useless > messages. How to enable warnings for all targets except this one? This thread has not yet designed any means for a user to control warnings globally (e.g. via a cache entry). Project code should be able to offer such options manually, but it would also be nice to have a CMake-defined setting. The semantics of such a setting will need to be defined carefully to allow the project to override (or not override) settings for specific targets. -Brad From brad.king at kitware.com Fri Apr 22 09:37:02 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 22 Apr 2016 09:37:02 -0400 Subject: [cmake-developers] Autogen subdirectories patches In-Reply-To: <57187DB9.7060904@xwmw.org> References: <57164A42.6030407@xwmw.org> <57166AC3.7000302@kitware.com> <57187DB9.7060904@xwmw.org> Message-ID: <571A28FE.6080401@kitware.com> On 04/21/2016 03:14 AM, Sebastian Holtermann wrote: >> Thanks! I've applied them locally and merged the cleanup/refactoring >> commits to 'next' for testing first. Once those test cleanly I'll move >> on to the rest. > > It is good too see the patches made it into the next branch. The rest of the changes are now in 'master'. Thanks for working on this! > Now there is another issue I have a partially fix for. > > As of now all included mocs and uis get generated in > CMAKE_CURRENT_BINARY_DIR/ > because they must be within INCLUDE_DIRECTORIES. > I think a more robust approach would be to generate them in > CMAKE_CURRENT_BINARY_DIR/TARGET_automoc.dir/ > and to add the _automoc.dir to INCLUDE_DIRECTORIES. > > I've attached a patch that does does so > - it is relative to current "next" branch. You should be able to rebase on 'master' now. > It is incomplete though because I didn't manage to get > CMAKE_CURRENT_BINARY_DIR/TARGET_automoc.dir/ > into INCLUDE_DIRECTORIES in Source/cmQtAutoGeneratorInitializer.cxx. > (GetAutogenTargetBuildDir() in Source/cmQtAutoGeneratorInitializer.cxx) > > If someone could do that or give me pointers on how to do it > then this could be another improvement. I'm afraid I'm not familiar enough with this infrastructure to know for sure. The entire Qt autogen infrastructure was built by others. Take a look at cmGlobalGenerator::Compute to see a carefully ordered set of operations. Among them is the QtAutoGenerator step. I'm not sure of its order relative to INCLUDE_DIRECTORIES evaluation. Thanks, -Brad From mantis at public.kitware.com Fri Apr 22 10:39:46 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 22 Apr 2016 10:39:46 -0400 Subject: [cmake-developers] [CMake 0016076]: bin install directory configuration Message-ID: <3af89bc84700abf80b1ec8a0d973aac6@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=16076 ====================================================================== Reported By: blackstar Assigned To: ====================================================================== Project: CMake Issue ID: 16076 Category: CMakeSetup Reproducibility: always Severity: block Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-22 10:39 EDT Last Modified: 2016-04-22 10:39 EDT ====================================================================== Summary: bin install directory configuration Description: It is impossible to set the CMake bin install directory with bootstrap options. The bin install directory is always /bin. If cmake binary is moved to other location, The CMAKE_ROOT could not be find, because the unique search directory of /Modules/CMake.cmake file is at the same level of bin directory. CMake Error: Could not find CMAKE_ROOT !!! CMake has most likely not been installed correctly. Modules directory not found in So it is impossible to have in the same install directory, several CMake binary of different OS. For example : cmake-3.5.2/bin/centos6.2/cmake cmake-3.5.2/bin/ubuntu14.04/cmake Is it possible to add an option in bootstrap, like --docdir, to set the binary install directory relative to ? Steps to Reproduce: do a cmake installation move the cmake binary run cmake ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-22 10:39 blackstar New Issue ====================================================================== From mantis at public.kitware.com Fri Apr 22 17:09:01 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 22 Apr 2016 17:09:01 -0400 Subject: [cmake-developers] [CMake 0016077]: FindProtobuf.cmake doesn't have required flexibility to configure protoc usage for all use cases Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16077 ====================================================================== Reported By: skebanga Assigned To: ====================================================================== Project: CMake Issue ID: 16077 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-22 17:09 EDT Last Modified: 2016-04-22 17:09 EDT ====================================================================== Summary: FindProtobuf.cmake doesn't have required flexibility to configure protoc usage for all use cases Description: I have here a very simple test project which has 2 protobuf files, one of which is included in the other. Using cmake, I will create a static library for each generated protobuf message. ##Protobuf files: **`src/foo/message.proto`:** package test.foo; message FooMsg { required string s = 1; } **`src/bar/message.proto`:** package test.bar; import "foo/message.proto"; message BarMsg { optional foo.FooMsg f = 1; } ##CMake files: I build `lib_foo` from generated `foo/message.proto` files. **`src/foo/CMakeLists.txt`:** protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS message.proto) add_library(lib_foo STATIC ${PROTO_SRCS}) I build `lib_bar` from the generated `bar/message.proto` files, and link in `lib_foo`: **`src/bar/CMakeLists.txt`:** protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS message.proto ) add_library(lib_bar STATIC ${PROTO_SRCS}) target_link_libraries(lib_bar lib_foo) **`src/CMakeLists.txt`:** cmake_minimum_required (VERSION 3.5) project (cmake_proto_test CXX) find_package(Protobuf REQUIRED) # proto files import from the source root directory, so add the required -I flag set(PROTOBUF_IMPORT_DIRS ${CMAKE_SOURCE_DIR}) # genererated proto files go into the CMake binary output dir include_directories("${CMAKE_BINARY_DIR}") add_subdirectory(foo) add_subdirectory(bar) ##Build error: When I try to build this, I get the following error: $ make .. VERBOSE=1 cd src/cmake_proto/build/bar && /usr/bin/c++ -I src/cmake_proto/build -o CMakeFiles/lib_bar.dir/message.pb.cc.o -c src/cmake_proto/build/bar/message.pb.cc In file included from src/cmake_proto/build/bar/message.pb.cc:5:0: src/cmake_proto/build/bar/message.pb.h:99:24: error: ?foo? in namespace ?test? does not name a type inline const ::test::foo::FooMsg& f() const; ^ ##Reason: The error is due to the header guard created by `protoc` being the same for the 2 generated files: #ifndef PROTOBUF_message_2eproto__INCLUDED #define PROTOBUF_message_2eproto__INCLUDED ... #endif The reason is that the header guard is derived from a combination of the output directory and the generated file's path. The current command issued by `FindProtobuf.cmake` results in the header guard only using the filename: cd src/cmake_proto/build/foo && /usr/local/bin/protoc --cpp_out src/cmake_proto/build/foo -I src/cmake_proto/foo -I src/cmake_proto src/cmake_proto/foo/message.proto cd src/cmake_proto/build/bar && /usr/local/bin/protoc --cpp_out src/cmake_proto/build/bar -I src/cmake_proto/bar -I src/cmake_proto src/cmake_proto/bar/message.proto This command, however, will result in the files being generated in the same location, but with a different header guard: cd src/cmake_proto/build && /usr/local/bin/protoc --cpp_out src/cmake_proto/build -I src/cmake_proto src/cmake_proto/foo/message.proto cd src/cmake_proto/build && /usr/local/bin/protoc --cpp_out src/cmake_proto/build -I src/cmake_proto src/cmake_proto/bar/message.proto Header guards: PROTOBUF_foo_2fmessage_2eproto__INCLUDED PROTOBUF_bar_2fmessage_2eproto__INCLUDED There are three key differences here: - The `WORKING_DIRECTORY` from which `protoc` is run from is `${CMAKE_BINARY_DIR}` - The `--cpp_out` directory passed to `protoc` is `${CMAKE_BINARY_DIR}` - The `-I` include path passed to `protoc` does **not** include the folder where the proto file is found Being able to control these 3 items would give the flexibility required to use this tool in the above setup. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-22 17:09 skebanga New Issue ====================================================================== From ruslan_baratov at yahoo.com Sat Apr 23 00:11:21 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Sat, 23 Apr 2016 11:11:21 +0700 Subject: [cmake-developers] CMake API for warnings In-Reply-To: <571A28F6.8070409@kitware.com> References: <56F85BE4.2070503@yahoo.com> <56F93A40.8090904@kitware.com> <56FA7E9A.7020704@yahoo.com> <56FA9014.70106@kitware.com> <56FA9E26.2090704@yahoo.com> <56FD2835.60301@kitware.com> <56FD5488.9010706@yahoo.com> <5703C5A4.6090506@kitware.com> <5703FE0C.5060401@yahoo.com> <570D37B5.6010502@kitware.com> <570DD705.5020306@yahoo.com> <5714FF33.4020700@kitware.com> <5717893E.1040304@yahoo.com> <571A28F6.8070409@kitware.com> Message-ID: <2dec52c6-3365-c438-05b7-94cb95149bb1@yahoo.com> On 22-Apr-16 20:36, Brad King wrote: > On 04/20/2016 09:50 AM, Ruslan Baratov wrote: >> 1) add_compile_warnings >> * similar to add_definitions, add_compile_options >> * modify COMPILE_WARNINGS directory property (append) >> 2) target_compile_warnings >> * similar to target_compile_options, target_compile_definitions >> * modify COMPILE_WARNINGS target property (append) >> 3) source_files_compile_warnings >> * similar to set_source_files_properties >> * modify COMPILE_WARNINGS sources property (append) > Sounds good. Note that cmTarget has dedicated storage with backtrace > information for other build system properties. Please use the same > pattern for these. I also suggest getting the directory/target level > working first and work on source files later. The infrastructure for > the latter is not as mature so it may need more work. > >> *_compile_warnings( >> >> DISABLE # add =off to COMPILE_WARNINGS >> property >> ENABLE # add =on to COMPILE_WARNINGS >> property >> TREAT_AS_ERROR # add =error to >> COMPILE_WARNINGS property >> ) > Sounds good. > >> * all (compiler specific "all", e.g. /Wall or -Wall) >> * default >> * level >> * none >> * everything (all possible warnings for compiler, if there is no such >> option use maximum level plus some warnings explicitly) > Okay. Let's drop level for now for the reason you outlined. > We can always add it later. > >> Properties will be set in form =on|off|error, e.g.: >> >> add_compile_warnings(DISABLE undef unused ENABLE inline TREAT_AS_ERROR everything) >> >> will set COMPILE_WARNINGS directory property to: >> >> undef=off unused=off inline=on everything=error > Good. > >> In case of any conflicts return CMake warning for developer message >> (cmake -Wdev/cmake -Wno-dev). > Good. > >> Directory properties affect targets and sources, target properties >> affect sources of this target. E.g.: >> >> add_compile_warnings(DISABLE undef) >> target_compile_warnings(foo DISABLE unused) >> >> effectively equivalent to: >> >> target_compile_warnings(foo DISABLE undef unused) >> >> Question: do we need to control this? probably by >> 'target_compile_warnings(foo DISABLE unused IGNORE DIRECTORY)' ? > It should be possible to merge the directory/target/source settings > with proper precedence. I don't understand your example well enough > to see what "IGNORE DIRECTORY" would mean. Either way, such information > needs to be encoded somehow in the property values. It means ignoring directory properties. So by default we will inherit settings. Target will inherit directory properties: add_compile_warnings(DISABLE warn-A) target_compile_warnings(foo DISABLE warn-B) COMPILE_WARNINGS of target 'foo' property value: warn-A=off warn-B=off Sources: add_compile_warnings(ENABLE warn-A) target_compile_warnings(foo ENABLE warn-B) source_files_compile_warnings(foo.cpp ENABLE warn-C) COMPILE_WARNINGS of 'foo.cpp' property value: warn-A=on warn-B=on warn-C=on To disable inheriting we need to add extra argument (?) to *_compile_warnings: add_compile_warnings(DISABLE warn-A) target_compile_warnings(foo DISABLE warn-B IGNORE DIRECTORY) COMPILE_WARNINGS of target 'foo' property value (warn-A from directory properties ignored): warn-B=off Same with IGNORE TARGET: add_compile_warnings(ENABLE warn-A) target_compile_warnings(foo ENABLE warn-B) source_files_compile_warnings(foo.cpp ENABLE warn-C IGNORE TARGET) COMPILE_WARNINGS of 'foo.cpp' property value (warn-B from target ignored, directory not): warn-C=on warn-A=on Ignoring both: add_compile_warnings(ENABLE warn-A) target_compile_warnings(foo ENABLE warn-B) source_files_compile_warnings(foo.cpp ENABLE warn-C IGNORE TARGET DIRECTORY) Result: warn-C=on > >> may expand to nothing in case warning make no sense for >> current language or warning not implemented by compiler: > Okay. > >> After this feature implemented we need to introduce new policy to avoid >> adding warnings flags to CMAKE_CXX_FLAGS by default (e.g. "/W3" added by >> default for Visual Studio). > Yes. > >> Warnings should not be propagated via INTERFACE because unlike >> definitions or other compiler flags they doesn't affect final binary or >> compatibility. > Okay. > >> On 29-Mar-16 22:42, Ruslan Baratov wrote: >>> One more note. Properties is a good abstraction and works great for >>> the native CMake project. But there is a tricky scenario about them - >>> when we need to create ExternalProject_Add for the non-CMake project. >> Would be nice to have this one. > This is beyond the scope of this change and affects all flags, so > let's defer this for a later time. > >> Is it possible in general to control warnings globally? Imagine I have >> target that should ignore all warnings for any reason. If you able to >> control warnings globally this target will generate tons of useless >> messages. How to enable warnings for all targets except this one? > This thread has not yet designed any means for a user to control > warnings globally (e.g. via a cache entry). Project code should > be able to offer such options manually, but it would also be nice > to have a CMake-defined setting. The semantics of such a setting > will need to be defined carefully to allow the project to override > (or not override) settings for specific targets. From seblist at xwmw.org Sat Apr 23 07:21:49 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Sat, 23 Apr 2016 13:21:49 +0200 Subject: [cmake-developers] Autogen subdirectories patches In-Reply-To: <571A28FE.6080401@kitware.com> References: <57164A42.6030407@xwmw.org> <57166AC3.7000302@kitware.com> <57187DB9.7060904@xwmw.org> <571A28FE.6080401@kitware.com> Message-ID: <571B5ACD.6010002@xwmw.org> Am 22.04.2016 um 15:37 schrieb Brad King: > On 04/21/2016 03:14 AM, Sebastian Holtermann wrote: >>> Thanks! I've applied them locally and merged the cleanup/refactoring >>> commits to 'next' for testing first. Once those test cleanly I'll move >>> on to the rest. >> >> It is good too see the patches made it into the next branch. > > The rest of the changes are now in 'master'. Thanks for working on this! > >> Now there is another issue I have a partially fix for. >> >> As of now all included mocs and uis get generated in >> CMAKE_CURRENT_BINARY_DIR/ >> because they must be within INCLUDE_DIRECTORIES. >> I think a more robust approach would be to generate them in >> CMAKE_CURRENT_BINARY_DIR/TARGET_automoc.dir/ >> and to add the _automoc.dir to INCLUDE_DIRECTORIES. >> >> I've attached a patch that does does so >> - it is relative to current "next" branch. > > You should be able to rebase on 'master' now. > >> It is incomplete though because I didn't manage to get >> CMAKE_CURRENT_BINARY_DIR/TARGET_automoc.dir/ >> into INCLUDE_DIRECTORIES in Source/cmQtAutoGeneratorInitializer.cxx. >> (GetAutogenTargetBuildDir() in Source/cmQtAutoGeneratorInitializer.cxx) >> >> If someone could do that or give me pointers on how to do it >> then this could be another improvement. > > I'm afraid I'm not familiar enough with this infrastructure to know > for sure. The entire Qt autogen infrastructure was built by others. > Take a look at cmGlobalGenerator::Compute to see a carefully > ordered set of operations. Among them is the QtAutoGenerator step. > I'm not sure of its order relative to INCLUDE_DIRECTORIES evaluation. I see. Thanks for the pointer. Unfortunately I can't spend much more time on this right now but maybe later. Thanks again for the kind support. -Sebastian From mantis at public.kitware.com Sun Apr 24 04:28:49 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 24 Apr 2016 04:28:49 -0400 Subject: [cmake-developers] [CMake 0016078]: CMake on Cygwin with clang not creating expected dll.a Message-ID: <32bbe4fb7c258d70f7e48c9ed56f04e1@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16078 ====================================================================== Reported By: Thomas Nilsson Assigned To: ====================================================================== Project: CMake Issue ID: 16078 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-24 04:28 EDT Last Modified: 2016-04-24 04:28 EDT ====================================================================== Summary: CMake on Cygwin with clang not creating expected dll.a Description: I'm building a shared library and an application using that lib on Cygwin. With GCC CMake creates a .dll.a to use when linking. Switching to clang I get [ 34%] Built target xyz_shared make[2]: *** No rule to make target 'src/libxyz_shared.dll.a', needed by 'xyz.exe'. Stop. Steps to Reproduce: On Cygwin, use the attached CMakeLists.txt and see it produce 'cygxyz_shared.dll' and 'libxyz_shared.dll.a'. Clear the build directory and do $ CC=clang cmake ..; make and it will not create 'libxyz_shared.dll.a'. Additional Information: As described in this Stackoverflow question (http://stackoverflow.com/questions/36294199) the culprit seems to be the lack of the flags '-Wl,--enable-auto-import' when using clang. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-24 04:28 Thomas Nilsson New Issue 2016-04-24 04:28 Thomas Nilsson File Added: CMakeLists.txt ====================================================================== From mantis at public.kitware.com Sun Apr 24 06:39:58 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 24 Apr 2016 06:39:58 -0400 Subject: [cmake-developers] [CMake 0016079]: Unknown extension ".c" for file Message-ID: <5a31afd1cff4eb6aad0cd94dd3877b6f@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16079 ====================================================================== Reported By: rtsisyk Assigned To: ====================================================================== Project: CMake Issue ID: 16079 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-24 06:39 EDT Last Modified: 2016-04-24 06:39 EDT ====================================================================== Summary: Unknown extension ".c" for file Description: Ubuntu 14.04 inside Windows 10 LXSS. ``` -- The C compiler identification is unknown CMake Error at Modules/CMakeDetermineCCompiler.cmake:181 (configure_file): configure_file Problem configuring file Call Stack (most recent call first): CMakeLists.txt:19 (project) -- The CXX compiler identification is unknown CMake Error at Modules/CMakeDetermineCXXCompiler.cmake:179 (configure_file): configure_file Problem configuring file Call Stack (most recent call first): CMakeLists.txt:19 (project) -- Check for working C compiler: /usr/bin/gcc CMake Error at Modules/CMakeTestCCompiler.cmake:47 (try_compile): Unknown extension ".c" for file /home/roman/cmake-3.5.2/CMakeFiles/CMakeTmp/testCCompiler.c try_compile() works only for enabled languages. Currently these are: C CXX See project() command to enable other languages. Call Stack (most recent call first): CMakeLists.txt:19 (project) -- Check for working C compiler: /usr/bin/gcc -- broken CMake Error at Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "/usr/bin/gcc" 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:19 (project) -- Configuring incomplete, errors occurred! See also "/home/roman/cmake-3.5.2/CMakeFiles/CMakeOutput.log". See also "/home/roman/cmake-3.5.2/CMakeFiles/CMakeError.log". --------------------------------------------- Error when bootstrapping CMake: Problem while running initial CMake --------------------------------------------- ``` Steps to Reproduce: 1. Install Windows Subsystem for Linux on Windows 10 http://www.howtogeek.com/249966/how-to-install-and-use-the-linux-bash-shell-on-windows-10/ 2. Install cmake (any version) apt-get install build-essential cmake 3. Try to build a simple C or CXX project cmake . ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-24 06:39 rtsisyk New Issue 2016-04-24 06:39 rtsisyk File Added: 7.png ====================================================================== From seblist at xwmw.org Sun Apr 24 09:55:49 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Sun, 24 Apr 2016 15:55:49 +0200 Subject: [cmake-developers] Autogen message cleanups Message-ID: <571CD065.5040204@xwmw.org> Two more autogen patches with message cleanups/tweaks. -Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Autogen-Message-cleanups-Compose-messages-in-std-str.patch Type: text/x-patch Size: 23296 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Autogen-Message-tweaks-Compiler-type-moc-qrc-ui-adde.patch Type: text/x-patch Size: 2232 bytes Desc: not available URL: From Geoffrey.Viola at asirobots.com Sun Apr 24 15:57:40 2016 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Sun, 24 Apr 2016 19:57:40 +0000 Subject: [cmake-developers] 0016046: GHS Multi Generator: duplicate object file names In-Reply-To: <5714FD06.9050507@kitware.com> References: <5714FD06.9050507@kitware.com> Message-ID: I didn't understand why the visual studio target used the target's AddExplicitObjectName so that the visual studio global class could use it. It seems roundabout. The Green Hills MULTI IDE has a few different quirks from visual studio. 1. It counts the extension as a difference in the filename 2. It ignores the '/' Attached is a patch that handles duplicate filenames by prepending collided filepaths with the absolute paths. The full path uses '_' instead of ":/" and '/', since MULTI ignores that. There's also a test that should work with the other generators. Geoff -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Monday, April 18, 2016 9:28 AM To: Geoffrey Viola Cc: cmake-developers at cmake.org Subject: Re: [cmake-developers] 0016046: GHS Multi Generator: duplicate object file names On 04/17/2016 04:22 PM, Geoffrey Viola wrote: > Attached is a patch to fix the bug tracked at https://cmake.org/Bug/view.php?id=16046. > It adds a special source property to set the obj filename for the GHS MULTI generator. > It is necessary, because GHS MULTI has a bug where it can't compile > two source files with the same filenames. Thanks. However, I do not think it should be the project's responsibility to set the OBJECT_FILE property for this. CMake's VS IDE generator has the same problem so we generate specific object file names automatically when the defaults will not be unique. See logic here: cmLocalVisualStudioGenerator::ComputeObjectFilenames https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalVisualStudioGenerator.cxx;hb=v3.5.2#l41 and use of AddExplicitObjectName in particular. -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. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Green-Hills-MULTI-handles-duplicate-source-filenames.patch Type: application/octet-stream Size: 6425 bytes Desc: 0001-Green-Hills-MULTI-handles-duplicate-source-filenames.patch URL: From brad.king at kitware.com Mon Apr 25 14:24:38 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 25 Apr 2016 14:24:38 -0400 Subject: [cmake-developers] 0016046: GHS Multi Generator: duplicate object file names In-Reply-To: References: <5714FD06.9050507@kitware.com> Message-ID: <571E60E6.6030007@kitware.com> On 04/24/2016 03:57 PM, Geoffrey Viola wrote: > Attached is a patch that handles duplicate filenames by prepending > collided filepaths with the absolute paths. Applied, thanks. > There's also a test that should work with the other generators. I renamed it to be GhsMulti-specific since it is only added for that generator right now. I'm pretty sure the case is covered elsewhere in the test suite for other generators. Thanks, -Brad From brad.king at kitware.com Mon Apr 25 14:24:48 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 25 Apr 2016 14:24:48 -0400 Subject: [cmake-developers] Autogen message cleanups In-Reply-To: <571CD065.5040204@xwmw.org> References: <571CD065.5040204@xwmw.org> Message-ID: <571E60F0.2090400@kitware.com> On 04/24/2016 09:55 AM, Sebastian Holtermann wrote: > Two more autogen patches with message cleanups/tweaks. Thanks! Applied: Autogen: Message cleanups: Compose messages in std::stringstream https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9b58190c Autogen: Message tweaks: Compiler type (moc/qrc/ui) added to progress messages https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9647af3f I ran `s/msg/err/g` on the hunks of the first patch in order to avoid shadowing other `msg` locals in a few places. -Brad From brad.king at kitware.com Mon Apr 25 14:58:46 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 25 Apr 2016 14:58:46 -0400 Subject: [cmake-developers] CMake API for warnings In-Reply-To: <2dec52c6-3365-c438-05b7-94cb95149bb1@yahoo.com> References: <56F85BE4.2070503@yahoo.com> <56F93A40.8090904@kitware.com> <56FA7E9A.7020704@yahoo.com> <56FA9014.70106@kitware.com> <56FA9E26.2090704@yahoo.com> <56FD2835.60301@kitware.com> <56FD5488.9010706@yahoo.com> <5703C5A4.6090506@kitware.com> <5703FE0C.5060401@yahoo.com> <570D37B5.6010502@kitware.com> <570DD705.5020306@yahoo.com> <5714FF33.4020700@kitware.com> <5717893E.1040304@yahoo.com> <571A28F6.8070409@kitware.com> <2dec52c6-3365-c438-05b7-94cb95149bb1@yahoo.com> Message-ID: <571E68E6.6080704@kitware.com> On 04/23/2016 12:11 AM, Ruslan Baratov wrote: > It means ignoring directory properties. So by default we will inherit settings. [snip] > To disable inheriting we need to add extra argument (?) to *_compile_warnings: > > add_compile_warnings(DISABLE warn-A) > target_compile_warnings(foo DISABLE warn-B IGNORE DIRECTORY) We don't have such a feature for any of the other build settings so there is no precedent for how to represent this or its exact semantics. We may not need the capability at all. For other properties like COMPILE_OPTIONS and INCLUDE_DIRECTORIES the target-level property is initialized from the directory-level property when the target is created. After that the directory-level property has no meaning to the target. One may then set the target-level property to erase any content previously taken from the directory-level property. This allows specific targets to ignore the directory-level property in special cases. -Brad From mantis at public.kitware.com Tue Apr 26 09:04:05 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 26 Apr 2016 09:04:05 -0400 Subject: [cmake-developers] [CMake 0016082]: Support alternative download URL in ExternalProject_Add Message-ID: The following issue has been SUBMITTED. ====================================================================== https://public.kitware.com/Bug/view.php?id=16082 ====================================================================== Reported By: A. Klitzing Assigned To: ====================================================================== Project: CMake Issue ID: 16082 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-26 09:04 EDT Last Modified: 2016-04-26 09:04 EDT ====================================================================== Summary: Support alternative download URL in ExternalProject_Add Description: We use a script with a lot of ExternalProject_Add to generate our dependencies. But some project moves their files to different destination after some time. For example: openssl It would be very helpful if ExternalProject_Add could support alternative download URLs as a list. So cmake could try the next URL if a connection error occurs. ExternalProject_Add(dummy URL "${FIRST_URL}" "${SECOND_URL}" "${THIRD_URL}" ) Additional Information: OpenSSL: Current version: ftp://ftp.openssl.org/source/ If a new version arrives the old one will be moved to: ftp://ftp.openssl.org/source/old/ ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-26 09:04 A. Klitzing New Issue ====================================================================== From mantis at public.kitware.com Tue Apr 26 17:13:58 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 26 Apr 2016 17:13:58 -0400 Subject: [cmake-developers] [CMake 0016083]: ExternalProject with empty GIT_SUBMODULES does not initialize submodules of submodules Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16083 ====================================================================== Reported By: Ilya Assigned To: ====================================================================== Project: CMake Issue ID: 16083 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-26 17:13 EDT Last Modified: 2016-04-26 17:13 EDT ====================================================================== Summary: ExternalProject with empty GIT_SUBMODULES does not initialize submodules of submodules Description: Current implementation uses the following command to get submodules: 1. `git submodule init` 2. `submodule update --recursive` This is enough to initialize direct submodules of the repo, however it leaves submodules of submodules uninitialized. To address this, [2] (and possibly [1]) must be changed to `submodule update --recursive --init` Steps to Reproduce: 1. Add an external project that has submodule which has its own submodule 2. Try to pull sources of this project 3. Check that submodule of submodule was not initialized ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-26 17:13 Ilya New Issue ====================================================================== From daniel at pfeifer-mail.de Tue Apr 26 17:32:11 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Tue, 26 Apr 2016 23:32:11 +0200 Subject: [cmake-developers] Integration of clang-tidy In-Reply-To: <570BC211.4020006@kitware.com> References: <570BC211.4020006@kitware.com> Message-ID: On Mon, Apr 11, 2016 at 5:26 PM, Brad King wrote: > On 04/08/2016 06:31 PM, Daniel Pfeifer wrote: >> I implemented the integration of `clang-tidy` along the lines of the >> `include-what-you-use` integration. >> There is a new `_CLANG_TIDY` target property that is initialized >> with the value of the `CMAKE__CLANG_TIDY` variable. >> It contains the command line for `clang-tidy` as a ;-list. > > Nice. The patch is very complete. Applied: > > Add options to run clang-tidy with the compiler > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b2db0170 This is a follow up patch: Clang-Tidy writes the number of warnings, the number of suppressed warnings, and instructions on how to suppress warnings to stderr. Since each source file is checked individually, this repetitive information is disturbing and should be suppressed. The actual warning messages are written to stdout. Some IDEs (eg. QtCreator) analyze only stderr for issues. Redirecting Clang-Tidy's stdout to stderr makes sure the warnings are correctly displayed. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Clang-Tidy-copy-stdout-to-sterr-ignore-original-stde.patch Type: text/x-patch Size: 2029 bytes Desc: not available URL: From ruslan_baratov at yahoo.com Wed Apr 27 02:19:10 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 27 Apr 2016 13:19:10 +0700 Subject: [cmake-developers] CMake API for warnings In-Reply-To: <571E68E6.6080704@kitware.com> References: <56F85BE4.2070503@yahoo.com> <56F93A40.8090904@kitware.com> <56FA7E9A.7020704@yahoo.com> <56FA9014.70106@kitware.com> <56FA9E26.2090704@yahoo.com> <56FD2835.60301@kitware.com> <56FD5488.9010706@yahoo.com> <5703C5A4.6090506@kitware.com> <5703FE0C.5060401@yahoo.com> <570D37B5.6010502@kitware.com> <570DD705.5020306@yahoo.com> <5714FF33.4020700@kitware.com> <5717893E.1040304@yahoo.com> <571A28F6.8070409@kitware.com> <2dec52c6-3365-c438-05b7-94cb95149bb1@yahoo.com> <571E68E6.6080704@kitware.com> Message-ID: On 26-Apr-16 01:58, Brad King wrote: > On 04/23/2016 12:11 AM, Ruslan Baratov wrote: >> It means ignoring directory properties. So by default we will inherit settings. > [snip] >> To disable inheriting we need to add extra argument (?) to *_compile_warnings: >> >> add_compile_warnings(DISABLE warn-A) >> target_compile_warnings(foo DISABLE warn-B IGNORE DIRECTORY) > We don't have such a feature for any of the other build settings so > there is no precedent for how to represent this or its exact semantics. Okay, fair enough, let's skip it. Ruslo From mantis at public.kitware.com Wed Apr 27 06:41:34 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 27 Apr 2016 06:41:34 -0400 Subject: [cmake-developers] [CMake 0016084]: try_compile incorrect behavior for iOS universal build (device + simulator) with CMAKE_IOS_INSTALL_COMBINED Message-ID: <5c31129011b0ab6560eab9b5db1484bb@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16084 ====================================================================== Reported By: ranjak Assigned To: ====================================================================== Project: CMake Issue ID: 16084 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-27 06:41 EDT Last Modified: 2016-04-27 06:41 EDT ====================================================================== Summary: try_compile incorrect behavior for iOS universal build (device + simulator) with CMAKE_IOS_INSTALL_COMBINED Description: When configuring an iOS Xcode project using CMAKE_IOS_INSTALL_COMBINED (introduced in CMake 3.5) to produce universal binaries that contain code for both iPhone (ARM) and simulator (x86) code, I would like try_compile to compile for both the device and the simulator. However, currently, try_compile only compiles for the device. This causes projects that rely on try_compile to be possibly misconfigured for the simulator build (which can obviously lead to build failures and/or incorrect/non-existent values for architecture-dependent parameters set at configuration time). This problem also arises without CMAKE_IOS_INSTALL_COMBINED, if you want to use Xcode to build for both device(s) and simulator(s) without re-running CMake every time you switch between the two. Try_compile should instead call xcodebuild twice, one time with -sdk iphoneos and the other with -sdk iphonesimulator. Steps to Reproduce: Configure a project with IOS_INSTALL_COMBINED set to TRUE, and use try_compile in this project. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-27 06:41 ranjak New Issue ====================================================================== From mantis at public.kitware.com Wed Apr 27 08:02:23 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 27 Apr 2016 08:02:23 -0400 Subject: [cmake-developers] [CMake 0016085]: No Android Studio Generator Message-ID: The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16085 ====================================================================== Reported By: nguillot Assigned To: ====================================================================== Project: CMake Issue ID: 16085 Category: Modules Reproducibility: always Severity: feature Priority: high Status: new ====================================================================== Date Submitted: 2016-04-27 08:02 EDT Last Modified: 2016-04-27 08:02 EDT ====================================================================== Summary: No Android Studio Generator Description: With the Android Experimental Gradle plugin (http://tools.android.com/tech-docs/new-build-system/gradle-experimental) you enable the Android Studio C/C++ debug support. You can use either the "com.android.model.application" (Android application with Java and C/C++ sources code) , either "com.android.model.library" (Android Library with java and C/C++ sources) or "com.android.model.native" (only C/C++ sources) plugin to do that. As explain in the "Other Build Options" section the Gradle "ndk" section describe the compilation and linking options. The "NDK Dependencies" section of this page explain how to manage the dependency between the libraries. Additional Information: You can start with project that I published on Github to make your own experiment: https://github.com/nguillot/HelloCPP. Or use the official samples: https://github.com/googlesamples/android-ndk. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-27 08:02 nguillot New Issue ====================================================================== From brad.king at kitware.com Wed Apr 27 09:10:27 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 27 Apr 2016 09:10:27 -0400 Subject: [cmake-developers] Integration of clang-tidy In-Reply-To: References: <570BC211.4020006@kitware.com> Message-ID: <5720BA43.5000402@kitware.com> On 04/26/2016 05:32 PM, Daniel Pfeifer wrote: > This is a follow up patch: Thanks. > - tidy_cmd.insert(tidy_cmd.end(), orig_cmd.begin()+1, orig_cmd.end()); > + tidy_cmd.insert(tidy_cmd.end(), orig_cmd.begin(), orig_cmd.end()); What is the purpose of this hunk? Does clang-tidy expect to be given the full compiler command line including "cc"? This does not look related to the change described in the commit message. I've applied the change without that hunk: Clang-Tidy: copy stdout to sterr; ignore original stderr https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=04d74a7f Thanks, -Brad From gjasny at googlemail.com Wed Apr 27 16:47:00 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 27 Apr 2016 22:47:00 +0200 Subject: [cmake-developers] Integration of clang-tidy In-Reply-To: References: Message-ID: <57212544.4030902@googlemail.com> Hallo Daniel, On 09/04/16 00:31, Daniel Pfeifer wrote: > I implemented the integration of `clang-tidy` along the lines of the > `include-what-you-use` integration. > There is a new `_CLANG_TIDY` target property that is initialized > with the value of the `CMAKE__CLANG_TIDY` variable. > It contains the command line for `clang-tidy` as a ;-list. I'm wondering what's the advantage of having this built-in support for clang tidy over using the generated compile command database instead? Thanks, Gregor From chris.bieneman at me.com Wed Apr 27 16:39:44 2016 From: chris.bieneman at me.com (Chris Bieneman) Date: Wed, 27 Apr 2016 13:39:44 -0700 Subject: [cmake-developers] RFC: LLVM community CMake documentation Message-ID: Hello cmake-developers, Earlier this year the LLVM community finished migrating to CMake as our one and only build system. One of the lingering things on my to-do list to help this transition is to write some basic documentation for the CMake language to help LLVM developers get a feel for the language. I?ve attached the working draft of my documentation, and would greatly appreciate any feedback from members of the CMake community. While it is not my goal to be a definitive source, I would like to be as accurate as I can be. Thank you, -Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: CMakePrimer.rst Type: application/octet-stream Size: 12922 bytes Desc: not available URL: From daniel at pfeifer-mail.de Wed Apr 27 18:41:51 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Thu, 28 Apr 2016 00:41:51 +0200 Subject: [cmake-developers] Integration of clang-tidy In-Reply-To: <57212544.4030902@googlemail.com> References: <57212544.4030902@googlemail.com> Message-ID: On Wed, Apr 27, 2016 at 10:47 PM, Gregor Jasny wrote: > Hallo Daniel, > > On 09/04/16 00:31, Daniel Pfeifer wrote: >> I implemented the integration of `clang-tidy` along the lines of the >> `include-what-you-use` integration. >> There is a new `_CLANG_TIDY` target property that is initialized >> with the value of the `CMAKE__CLANG_TIDY` variable. >> It contains the command line for `clang-tidy` as a ;-list. > > I'm wondering what's the advantage of having this built-in support for > clang tidy over using the generated compile command database instead? The compile command database is just this: a database of compile commands. It does not execute clang-tidy at all. To execute clang-tidy for all source files that are listed in the database, you need a separate tool. There is this one, which requires Python: https://llvm.org/svn/llvm-project/clang-tools-extra/trunk/clang-tidy/tool/run-clang-tidy.py Having this functionality built into CMake means: * No additional dependencies. * Warning messages inside your IDE. * Warning messages on CDash. Since clang-tidy is executed directly before the compiler for each individual source file, you may set CMAKE_CXX_CLANG_TIDY to "clang-tidy;-fix-errors" and successfully compile invalid code. :-) From daniel at pfeifer-mail.de Wed Apr 27 18:48:15 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Thu, 28 Apr 2016 00:48:15 +0200 Subject: [cmake-developers] Integration of clang-tidy In-Reply-To: <5720BA43.5000402@kitware.com> References: <570BC211.4020006@kitware.com> <5720BA43.5000402@kitware.com> Message-ID: On Wed, Apr 27, 2016 at 3:10 PM, Brad King wrote: > On 04/26/2016 05:32 PM, Daniel Pfeifer wrote: >> This is a follow up patch: > > Thanks. > >> - tidy_cmd.insert(tidy_cmd.end(), orig_cmd.begin()+1, orig_cmd.end()); >> + tidy_cmd.insert(tidy_cmd.end(), orig_cmd.begin(), orig_cmd.end()); > > What is the purpose of this hunk? Does clang-tidy expect to be > given the full compiler command line including "cc"? This does > not look related to the change described in the commit message. It is unrelated. Clang-Tidy picks the interesting pieces from the compiler command line and ignores the rest. Whether cc is given or not makes no difference. But maybe we should leave the decision what to pick to Clang-Tidy? It may be clearer to forward the original command line unmodified. From daniel at pfeifer-mail.de Wed Apr 27 19:12:35 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Thu, 28 Apr 2016 01:12:35 +0200 Subject: [cmake-developers] Code style auto-formatting In-Reply-To: <564DDC29.8020409@kitware.com> References: <4797EDAAB4843944A70CA99A7DE7D8BD06B547C1@DE012432.schaeffler.com> <1447765056.13902.329.camel@mad-scientist.net> <564B9D98.5030303@kitware.com> <564DDC29.8020409@kitware.com> Message-ID: On Thu, Nov 19, 2015 at 3:26 PM, Brad King wrote: > On 11/19/2015 09:22 AM, Robert Dailey wrote: >> Tonight I will do some testing and submit a patch + example files >> converted to the style Brad suggested. We can fine-tune it as needed. > > Rather than a patch please work on a script to perform the conversion. > Then at any time we can choose to run the script as the one-shot conversion > and commit as a robot user. Any sweeping patch would be too big to > post to the list anyway. Ideally the script should be simple enough > to cut-n-paste into a shell so we can just record it in the commit > message. > > See this commit for an example of this approach: > > https://cmake.org/gitweb?p=cmake.git;a=commit;h=7bbaa428 It took a while, but i figured out .clang-format definitions (there are two required) and a script that, after applying, does not break compilation and unit tests. The .clang-format for the root directory looks like this: --- BasedOnStyle: Mozilla AlignAfterOpenBracket: false AlignOperands: false AllowShortFunctionsOnASingleLine: None AlwaysBreakAfterDefinitionReturnType: None AlwaysBreakAfterReturnType: None ColumnLimit: 79 ContinuationIndentWidth: 4 IncludeCategories: - Regex: 'cmStandardIncludes' Priority: -1 Standard: Cpp03 ... This is the script to perform the reformatting of most C/C++ source code: git ls-files -z -- '*.c' '*.cc' '*.cpp' '*.cxx' '*.h' '*.hh' '*.hpp' '*.hxx' \ | egrep -z -v '(Lexer|Parser|ParserHelper)\.' \ | egrep -z -v '^(Utilities/(KW|cm).*/|Source/(kwsys|CursesDialog/form)/)' \ | egrep -z -v '^Tests/Module/GenerateExportHeader' \ | egrep -z -v '^Tests/RunCMake/CommandLine/cmake_depends/test_UTF-16LE.h' \ | xargs -0 clang-format -i I have attached a patch that adds the .clang-format and two other patches that need to be applied before reformatting. I have pushed all those changes (including reformatting) to github: https://github.com/purpleKarrot/CMake/commits/clang-format Notes: * Trying to reformat Tests/RunCMake/CommandLine/cmake_depends/test_UTF-16LE.h makes clang-format crash. * Clang-Format dedents preprocessor directives. See also: https://llvm.org/bugs/show_bug.cgi?id=17362 * I did not include '*.in' files in the list, because Clang-Format does strange things to @VARIALES at . Please feel free to add/remove options from the .clang-format files. IncludeCategories and Standard should stay as they are. cheers, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CursesDialog-add-missing-cmState-include.patch Type: text/x-patch Size: 703 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-StringFileTest-add-blank-line-between-includes.patch Type: text/x-patch Size: 858 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-add-.clang-format-configuration-files.patch Type: text/x-patch Size: 1724 bytes Desc: not available URL: From mantis at public.kitware.com Thu Apr 28 05:37:15 2016 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 28 Apr 2016 05:37:15 -0400 Subject: [cmake-developers] [CMake 0016086]: Ninja generator doesn't handle multiple Mac apps using the same plist file with MACOSX_BUNDLE_INFO_PLIST Message-ID: <65f2e82e6ae029f7247fcefb7008997b@cmake.org> The following issue has been SUBMITTED. ====================================================================== https://cmake.org/Bug/view.php?id=16086 ====================================================================== Reported By: Florent Castelli Assigned To: ====================================================================== Project: CMake Issue ID: 16086 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2016-04-28 05:37 EDT Last Modified: 2016-04-28 05:37 EDT ====================================================================== Summary: Ninja generator doesn't handle multiple Mac apps using the same plist file with MACOSX_BUNDLE_INFO_PLIST Description: If an app is using the same plist file using the target property MACOSX_BUNDLE_INFO_PLIST, CMake will add a dependency on that plist file as it is a template with variables that needs processing at generation time. But if multiple apps are using the same plist template, CMake will add multiple dependencies to the same file on the Re-Run target and Ninja will then warn: ninja: warning: multiple rules generate ../Info.plist.in. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn] A fix would probably be to deduplicate the dependencies for rerunning CMake. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2016-04-28 05:37 Florent CastelliNew Issue ====================================================================== From brad.king at kitware.com Thu Apr 28 09:19:37 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 28 Apr 2016 09:19:37 -0400 Subject: [cmake-developers] RFC: LLVM community CMake documentation In-Reply-To: References: Message-ID: <57220DE9.3040600@kitware.com> On 04/27/2016 04:39 PM, Chris Bieneman wrote: > attached the working draft of my documentation Good work! Most of it looks great. Here are minor some comments. Please add a link to the cmake-language(7) manual: https://cmake.org/cmake/help/v3.5/manual/cmake-language.7.html somewhere. It has a lot of useful information, though is more of a reference than an introduction. It also has a formal grammar. > .. code-block:: console > > cmake_minimum_required(VERSION 3.2) I think you can specify "cmake" as the code block language here. CMake uses rst/sphinx for our docs and we do this frequently. > One of the few examples is PATH variables, which CMake does have some special > handling for. This special handling is for both PATH and FILEPATH and is explained at the end of this section: https://cmake.org/cmake/help/v3.5/command/set.html#set-cache-entry > CMake provides a module `CMakeParseArguments` which provides an implementation > of advanced argument parsing. FYI, in CMake 3.5 and above cmake_parse_arguments is a native command: https://cmake.org/cmake/help/v3.5/command/cmake_parse_arguments.html and the CMakeParseArguments module is an empty placeholder for compatibility. -Brad From brad.king at kitware.com Thu Apr 28 09:44:35 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 28 Apr 2016 09:44:35 -0400 Subject: [cmake-developers] Integration of clang-tidy In-Reply-To: References: <570BC211.4020006@kitware.com> <5720BA43.5000402@kitware.com> Message-ID: <572213C3.5050201@kitware.com> On 04/27/2016 06:48 PM, Daniel Pfeifer wrote: > It is unrelated. Clang-Tidy picks the interesting pieces from the > compiler command line and ignores the rest. Whether cc is given or not > makes no difference. > But maybe we should leave the decision what to pick to Clang-Tidy? It > may be clearer to forward the original command line unmodified. Applied, thanks! Clang-Tidy: Give entire compiler command line to clant-tidy tool https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=304ab71d -Brad From brad.king at kitware.com Thu Apr 28 10:26:54 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 28 Apr 2016 10:26:54 -0400 Subject: [cmake-developers] Code style auto-formatting In-Reply-To: References: <4797EDAAB4843944A70CA99A7DE7D8BD06B547C1@DE012432.schaeffler.com> <1447765056.13902.329.camel@mad-scientist.net> <564B9D98.5030303@kitware.com> <564DDC29.8020409@kitware.com> Message-ID: <57221DAE.4000405@kitware.com> On 04/27/2016 07:12 PM, Daniel Pfeifer wrote: > It took a while, but i figured out .clang-format definitions (there > are two required) and a script that, after applying, does not break > compilation and unit tests. Thanks! I'll try that out myself when I get a chance. > I have attached a patch that adds the .clang-format and two other > patches that need to be applied before reformatting. Meanwhile I've applied these cleanups: CursesDialog: add missing cmState include https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb8fdcf6 Tests: add blank line between includes in StringFileTest https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=29abee03 -Brad From chuck.atkins at kitware.com Thu Apr 28 11:33:45 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Thu, 28 Apr 2016 11:33:45 -0400 Subject: [cmake-developers] RFC: LLVM community CMake documentation In-Reply-To: References: Message-ID: Hi Chris, This is great! I do have a suggestion that perhaps Brad could weigh in on (may disagree). Since your already looking at a reasonably recent minimum requirement in your examples (3.2) and discussing bumping the minimum up to 3.4.3 even, I think it would be worthwhile to let even some of the simple examples show some of the newer language features and syntax. For example, in your lists of lists example, you currently have: foreach(list_name ${list_of_lists}) foreach(value ${${list_name}}) message(${value}) endforeach() endforeach() which has been valid CMake syntax since the days of yore, but you could show the newer syntax instead that uses the list variables directly instead of de-referencing them: foreach(list_name IN LISTS list_of_lists) foreach(value IN LISTS ${list_name}) message(${value}) endforeach() endforeach() It's of course a preference for how you want to document and use CMake in llvm but it might be good to get users started right off the bat with "new" cmake. - Chuck On Wed, Apr 27, 2016 at 4:39 PM, Chris Bieneman wrote: > Hello cmake-developers, > > Earlier this year the LLVM community finished migrating to CMake as our > one and only build system. One of the lingering things on my to-do list to > help this transition is to write some basic documentation for the CMake > language to help LLVM developers get a feel for the language. > > I?ve attached the working draft of my documentation, and would greatly > appreciate any feedback from members of the CMake community. While it is > not my goal to be a definitive source, I would like to be as accurate as I > can be. > > Thank you, > -Chris > > > -- > > 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 dan at su-root.co.uk Thu Apr 28 11:57:09 2016 From: dan at su-root.co.uk (Dan Liew) Date: Thu, 28 Apr 2016 16:57:09 +0100 Subject: [cmake-developers] RFC: LLVM community CMake documentation In-Reply-To: References: Message-ID: Hi Chris, Thanks for doing this. I've had a quick scan and I have a few minor comments. # Scripting overview This is personal preference but I don't like ``add_definitions()`` due to its global behaviour so I think its use should be discouraged. I much prefer ``target_compile_definitions()`` which isn't global. # Dereferencing One "Gotcha" I think that is worth mentioning is implicit derefencing of variables in ``if()`` conditionals for example ``` if ("${SOME_VAR}" STREQUAL "MSVC") ``` behaves very strangely because CMake will implicitly dereference "MSVC" (as if it was "${MSVC}") where as someone reading the code probably thinks that it is trying to check if the contents of the SOME_VAR as a string are "MSVC". This behaviour is prevented by setting CMP0054 to NEW but this was only introduced with CMake 3.1 and I don't think that's LLVM's minimum version so developers might hit this issue. Run ``cmake --help-policy CMP0054`` for more details. A hacky work around I employ is to write conditionals like that like this ``` if ("X${SOME_VAR}" STREQUAL "XMSVC") ``` It's not good though... # Scope You don't mention "GLOBAL" properties. IIRC LLVM's CMake code uses these so it might be worth mentioning these # LLVM specific macros/functions LLVM's CMake code pretty much avoids using many of the standard CMake commands for declaring targets favouring its own (sometimes confusingly named, e.g. add_llvm_library Vs. llvm_add_library) which I sometime find quite confusing. Seeing as this guide is aimed at LLVM developers I think this document (or an accompanying document) should describe these macros/functions. Thanks, Dan. From aklitzing at gmail.com Thu Apr 28 15:13:01 2016 From: aklitzing at gmail.com (A. Klitzing) Date: Thu, 28 Apr 2016 21:13:01 +0200 Subject: [cmake-developers] [CMake 0016082]: Support alternative download URL in ExternalProject_Add In-Reply-To: References: Message-ID: Hi there! I added that feature in the attached patch. Best regards Andr? Klitzing -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-multiple-alternative-URLs.patch Type: text/x-patch Size: 2200 bytes Desc: not available URL: From chris.bieneman at me.com Thu Apr 28 17:16:40 2016 From: chris.bieneman at me.com (Chris Bieneman) Date: Thu, 28 Apr 2016 14:16:40 -0700 Subject: [cmake-developers] RFC: LLVM community CMake documentation In-Reply-To: References: Message-ID: <961433AD-19F2-4829-928A-3A02821601A9@me.com> Thank you everyone for the feedback! I?ve updated the document based on the feedback. In addition to this document I?m also working on putting together a set of coding standards/guidelines/tips that are more LLVM-specific. When I get that together I?ll also send it over here for feedback. The only comment I think I didn?t directly update the document for was Dan?s comment about GLOBAL properties. I kinda have mixed feelings about GLOBAL properties. I know why we use them, but I?m not sure I want to encourage people to use them. I think some of the places we use them is just wrong. Many thanks! -Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: CMakePrimer.rst Type: application/octet-stream Size: 16022 bytes Desc: not available URL: -------------- next part -------------- > On Apr 27, 2016, at 1:39 PM, Chris Bieneman wrote: > > Hello cmake-developers, > > Earlier this year the LLVM community finished migrating to CMake as our one and only build system. One of the lingering things on my to-do list to help this transition is to write some basic documentation for the CMake language to help LLVM developers get a feel for the language. > > I?ve attached the working draft of my documentation, and would greatly appreciate any feedback from members of the CMake community. While it is not my goal to be a definitive source, I would like to be as accurate as I can be. > > Thank you, > -Chris > > -- > > 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 ruslan_baratov at yahoo.com Fri Apr 29 05:14:19 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 29 Apr 2016 16:14:19 +0700 Subject: [cmake-developers] CMake API for warnings In-Reply-To: <571A28F6.8070409@kitware.com> References: <56F85BE4.2070503@yahoo.com> <56F93A40.8090904@kitware.com> <56FA7E9A.7020704@yahoo.com> <56FA9014.70106@kitware.com> <56FA9E26.2090704@yahoo.com> <56FD2835.60301@kitware.com> <56FD5488.9010706@yahoo.com> <5703C5A4.6090506@kitware.com> <5703FE0C.5060401@yahoo.com> <570D37B5.6010502@kitware.com> <570DD705.5020306@yahoo.com> <5714FF33.4020700@kitware.com> <5717893E.1040304@yahoo.com> <571A28F6.8070409@kitware.com> Message-ID: This one looks like a plan. However I will not be able to work on the feature till ~15 May. So if anybody have a free time to start this work - feel free to do it and share patches :) Thanks, Ruslo On 22-Apr-16 20:36, Brad King wrote: > On 04/20/2016 09:50 AM, Ruslan Baratov wrote: >> 1) add_compile_warnings >> * similar to add_definitions, add_compile_options >> * modify COMPILE_WARNINGS directory property (append) >> 2) target_compile_warnings >> * similar to target_compile_options, target_compile_definitions >> * modify COMPILE_WARNINGS target property (append) >> 3) source_files_compile_warnings >> * similar to set_source_files_properties >> * modify COMPILE_WARNINGS sources property (append) > Sounds good. Note that cmTarget has dedicated storage with backtrace > information for other build system properties. Please use the same > pattern for these. I also suggest getting the directory/target level > working first and work on source files later. The infrastructure for > the latter is not as mature so it may need more work. > >> *_compile_warnings( >> >> DISABLE # add =off to COMPILE_WARNINGS >> property >> ENABLE # add =on to COMPILE_WARNINGS >> property >> TREAT_AS_ERROR # add =error to >> COMPILE_WARNINGS property >> ) > Sounds good. > >> * all (compiler specific "all", e.g. /Wall or -Wall) >> * default >> * level >> * none >> * everything (all possible warnings for compiler, if there is no such >> option use maximum level plus some warnings explicitly) > Okay. Let's drop level for now for the reason you outlined. > We can always add it later. > >> Properties will be set in form =on|off|error, e.g.: >> >> add_compile_warnings(DISABLE undef unused ENABLE inline TREAT_AS_ERROR everything) >> >> will set COMPILE_WARNINGS directory property to: >> >> undef=off unused=off inline=on everything=error > Good. > >> In case of any conflicts return CMake warning for developer message >> (cmake -Wdev/cmake -Wno-dev). > Good. > >> Directory properties affect targets and sources, target properties >> affect sources of this target. E.g.: >> >> add_compile_warnings(DISABLE undef) >> target_compile_warnings(foo DISABLE unused) >> >> effectively equivalent to: >> >> target_compile_warnings(foo DISABLE undef unused) >> >> Question: do we need to control this? probably by >> 'target_compile_warnings(foo DISABLE unused IGNORE DIRECTORY)' ? > It should be possible to merge the directory/target/source settings > with proper precedence. I don't understand your example well enough > to see what "IGNORE DIRECTORY" would mean. Either way, such information > needs to be encoded somehow in the property values. > >> may expand to nothing in case warning make no sense for >> current language or warning not implemented by compiler: > Okay. > >> After this feature implemented we need to introduce new policy to avoid >> adding warnings flags to CMAKE_CXX_FLAGS by default (e.g. "/W3" added by >> default for Visual Studio). > Yes. > >> Warnings should not be propagated via INTERFACE because unlike >> definitions or other compiler flags they doesn't affect final binary or >> compatibility. > Okay. > >> On 29-Mar-16 22:42, Ruslan Baratov wrote: >>> One more note. Properties is a good abstraction and works great for >>> the native CMake project. But there is a tricky scenario about them - >>> when we need to create ExternalProject_Add for the non-CMake project. >> Would be nice to have this one. > This is beyond the scope of this change and affects all flags, so > let's defer this for a later time. > >> Is it possible in general to control warnings globally? Imagine I have >> target that should ignore all warnings for any reason. If you able to >> control warnings globally this target will generate tons of useless >> messages. How to enable warnings for all targets except this one? > This thread has not yet designed any means for a user to control > warnings globally (e.g. via a cache entry). Project code should > be able to offer such options manually, but it would also be nice > to have a CMake-defined setting. The semantics of such a setting > will need to be defined carefully to allow the project to override > (or not override) settings for specific targets. > > -Brad > From brad.king at kitware.com Fri Apr 29 13:45:50 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 29 Apr 2016 13:45:50 -0400 Subject: [cmake-developers] [CMake 0016082]: Support alternative download URL in ExternalProject_Add In-Reply-To: References: Message-ID: <57239DCE.2010002@kitware.com> On 04/28/2016 03:13 PM, A. Klitzing wrote: > - message(FATAL_ERROR \"error: downloading '${remote}' failed > + message(WARNING \"downloading '\${url}' failed Thanks for working on this! Please revise the logic to collect the list of failed URLs in a list and report an error listing all URLs only after they all fail. Otherwise once the source moves all future builds will get warnings even though they succeed on one of the alternatives. Thanks, -Brad From aklitzing at gmail.com Fri Apr 29 15:40:46 2016 From: aklitzing at gmail.com (A. Klitzing) Date: Fri, 29 Apr 2016 21:40:46 +0200 Subject: [cmake-developers] [CMake 0016082]: Support alternative download URL in ExternalProject_Add In-Reply-To: <57239DCE.2010002@kitware.com> References: <57239DCE.2010002@kitware.com> Message-ID: Hi Brad, thanks for your advice! I APPEND the log of every failed download and print that only if no URL works now. So we reserve the detailed error log of a single download attempt. Best regards Andr? 2016-04-29 19:45 GMT+02:00 Brad King : > On 04/28/2016 03:13 PM, A. Klitzing wrote: >> - message(FATAL_ERROR \"error: downloading '${remote}' failed >> + message(WARNING \"downloading '\${url}' failed > > Thanks for working on this! Please revise the logic to collect > the list of failed URLs in a list and report an error listing > all URLs only after they all fail. Otherwise once the source > moves all future builds will get warnings even though they > succeed on one of the alternatives. > > Thanks, > -Brad > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-multiple-alternative-URLs.patch Type: text/x-patch Size: 2236 bytes Desc: not available URL: