Re: [cmake-developers] Distinguishing MSYS2 (was: FindPythonLibs repaired for MINGW -vs- WIN32 version confusion)
On Fri, Aug 7, 2015 at 1:16 PM, Brad King brad.k...@kitware.com wrote: On 08/07/2015 05:25 AM, Ray Donnelly wrote: CMake needs to be able to identify MSYS2 distinctly from both MINGW and MSYS first. Would a patch making that distinction be acceptable to CMake? Yes, I think that makes sense since the MSYS2 environment is distinct from Windows, MinGW, MSYS, and Cygwin. What should CMAKE_SYSTEM_NAME be for MSYS2? Now that you mention it, I have the patch for CMakeDetermineSystem that does gets CMAKE_SYSTEM_NAME from uname -s as for unix. On Fri, Aug 7, 2015 at 5:33 AM, Ray Donnelly mingw.andr...@gmail.com wrote: On Fri, Aug 7, 2015 at 1:16 PM, Brad King brad.k...@kitware.com wrote: On 08/07/2015 05:25 AM, Ray Donnelly wrote: CMake needs to be able to identify MSYS2 distinctly from both MINGW and MSYS first. Would a patch making that distinction be acceptable to CMake? Yes, I think that makes sense since the MSYS2 environment is distinct from Windows, MinGW, MSYS, and Cygwin. What should CMAKE_SYSTEM_NAME be for MSYS2? Off the cuff, MSYS2 sounds reasonable, but I think we need to carefully think about this .. We have CMake packages built with MinGW-w64 and also CMake packages built with msys2 GCC (that are used for only a few of our packages). Do they need to be separately identifiable? I also wonder whether the msys2 CMake could be done away with if we used some functions to convert paths between shell-system and make-system .. I'll ask the MSYS2 developers who added the msys2 CMake package about this. Finally, there's the consideration as to whether MSYS2 implies you are using just the minimum amount of the MSYS2 shell or whether you've gone all-in with MSYS2 (so are happy to be using our Python's which are not found in the registry and have a Unix file layout prefixed in /mingw32 or /mingw64). I'd like to hear others' thoughts on this! Thanks, -Brad 0001-CMakeDetermineSystem-distinguishes-MSYS-MINGW32-for-.patch Description: Binary data -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Supporting monolithic and efficient CMake + Ninja builds for LLVM developers
Chris Bieneman wrote: One big things I’m working on is improving the way we build our runtime libraries. These libraries are built for the targets that the compiler supports generating code for, so they can use different architectures, headers, and libraries than are used to build the compiler itself. CMake does a great job of finding libraries and constructing the compiler commands, and we want to leverage that instead of re-implementing it. Right. You would need something like what this bug report tracks: http://public.kitware.com/Bug/view.php?id=14539 The design has not moved on from http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10873/focus=10928 but the refactoring of cmake to make multiple configuration steps possible is underway. You could consider whether it is worth your while to put energy into furthering that design. I think that with that and a way to specify the compiler with a generator expression (the easy part), you would have a working solution. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] CMakeDetermineSystem.cmake distinguishes-MSYS-MINGW32 (was Re: Distinguishing MSYS2
Here is a patch that incorporates mingw/msys run via MSYS Makefiles generator to obtain the system name via uname -s. On Fri, Aug 7, 2015 at 4:45 PM, Greg Jung gvj...@gmail.com wrote: On Fri, Aug 7, 2015 at 1:16 PM, Brad King brad.k...@kitware.com wrote: On 08/07/2015 05:25 AM, Ray Donnelly wrote: CMake needs to be able to identify MSYS2 distinctly from both MINGW and MSYS first. Would a patch making that distinction be acceptable to CMake? Yes, I think that makes sense since the MSYS2 environment is distinct from Windows, MinGW, MSYS, and Cygwin. What should CMAKE_SYSTEM_NAME be for MSYS2? Now that you mention it, I have the patch for CMakeDetermineSystem that does gets CMAKE_SYSTEM_NAME from uname -s as for unix. On Fri, Aug 7, 2015 at 5:33 AM, Ray Donnelly mingw.andr...@gmail.com wrote: On Fri, Aug 7, 2015 at 1:16 PM, Brad King brad.k...@kitware.com wrote: On 08/07/2015 05:25 AM, Ray Donnelly wrote: CMake needs to be able to identify MSYS2 distinctly from both MINGW and MSYS first. Would a patch making that distinction be acceptable to CMake? Yes, I think that makes sense since the MSYS2 environment is distinct from Windows, MinGW, MSYS, and Cygwin. What should CMAKE_SYSTEM_NAME be for MSYS2? Off the cuff, MSYS2 sounds reasonable, but I think we need to carefully think about this .. We have CMake packages built with MinGW-w64 and also CMake packages built with msys2 GCC (that are used for only a few of our packages). Do they need to be separately identifiable? I also wonder whether the msys2 CMake could be done away with if we used some functions to convert paths between shell-system and make-system .. I'll ask the MSYS2 developers who added the msys2 CMake package about this. Finally, there's the consideration as to whether MSYS2 implies you are using just the minimum amount of the MSYS2 shell or whether you've gone all-in with MSYS2 (so are happy to be using our Python's which are not found in the registry and have a Unix file layout prefixed in /mingw32 or /mingw64). I'd like to hear others' thoughts on this! Thanks, -Brad 0001-CMakeDetermineSystem-distinguishes-MSYS-MINGW32-for-.patch Description: Binary data -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015689]: target_include_directories INTERFACE does not work for IMPORTED targets
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15689 == Reported By:James Johnston Assigned To: == Project:CMake Issue ID: 15689 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-08-07 15:17 EDT Last Modified: 2015-08-07 15:17 EDT == Summary:target_include_directories INTERFACE does not work for IMPORTED targets Description: When target_include_directories is used with an INTERFACE option on an IMPORTED target, the command fails with an error. Since I specified INTERFACE and not PUBLIC or PRIVATE, I should expect the command to work without error on the IMPORTED target. As a workaround, I have to use the more verbose set_property command. Steps to Reproduce: add_library(MyLib SHARED IMPORTED) set_property(TARGET MyLib PROPERTY IMPORTED_LOCATION mylib.dll) set_property(TARGET MyLib PROPERTY IMPORTED_IMPLIB mylib.lib) # Following line fails with an error: target_include_directories(MyLib INTERFACE mylib/include) # The error is: # Cannot specify include directories for imported target MyLib. # Alternative command that works: # set_property(TARGET MyLib APPEND PROPERTY INTERFACE_INCLUDE_DIRECTORIES mylib/include) == Issue History Date ModifiedUsername FieldChange == 2015-08-07 15:17 James Johnston New Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Distinguishing MSYS2
On 08/07/2015 08:33 AM, Ray Donnelly wrote: Finally, there's the consideration as to whether MSYS2 implies you are using just the minimum amount of the MSYS2 shell or whether you've gone all-in with MSYS2 CMAKE_SYSTEM_NAME should refer to the target application environment. If you're building with the MinGW tools for Windows then the value of CMAKE_SYSTEM_NAME should simply be Windows. For Cygwin we have a CMake built to run in Cygwin and target native Cygwin builds, and that CMake is completely different from the one used for Windows builds. The Cygwin CMake cannot be used to host builds on Windows and the Windows CMake cannot be used to host builds on Cygwin. Does MSYS2 have its own runtime such that binaries can understand POSIX paths like in Cygwin? In that case there should be a separate non-Windows CMake for MSYS2 just like we have for Cygwin. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [patch] Support debug libraries for TIFF and Xerces-C libraries
Please find attached two patches which allow these libraries to detect debug versions of the libraries on Windows. I copied the behaviour from the PNG module as suggested on #cmake. Kind regards, Roger Leigh 0001-FindTIFF-Find-debug-libraries.patch Description: Binary data 0001-FindXercesC-Find-debug-libraries.patch Description: Binary data -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Distinguishing MSYS2
On Fri, Aug 7, 2015 at 2:21 PM, Brad King brad.k...@kitware.com wrote: On 08/07/2015 08:33 AM, Ray Donnelly wrote: Finally, there's the consideration as to whether MSYS2 implies you are using just the minimum amount of the MSYS2 shell or whether you've gone all-in with MSYS2 CMAKE_SYSTEM_NAME should refer to the target application environment. If you're building with the MinGW tools for Windows then the value of CMAKE_SYSTEM_NAME should simply be Windows. For Cygwin we have a CMake built to run in Cygwin and target native Cygwin builds, and that CMake is completely different from the one used for Windows builds. The Cygwin CMake cannot be used to host builds on Windows and the Windows CMake cannot be used to host builds on Cygwin. Does MSYS2 have its own runtime such that binaries can understand POSIX paths like in Cygwin? In that case there should be a separate non-Windows CMake for MSYS2 just like we have for Cygwin. Yes, it's very much like Cygwin (a fork with a few additions) and understands POSIX paths (C:\ - /c/, without the /cygdrive stuff). Our runtime DLL is called msys-2.0.dll instead of cygwin1.dll. It would seem that our msys/cmake package identifies CMAKE_SYSTEM_NAME as MSYS at present: https://github.com/Alexpux/MSYS2-packages/blob/master/cmake/cmake-3.2.3-msys.patch Cheers, Ray. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015688]: ADD_CUSTOM_TARGET with Fortran sources creates invalid Unix Makefiles
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15688 == Reported By:bburgerm Assigned To: == Project:CMake Issue ID: 15688 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-08-07 09:56 EDT Last Modified: 2015-08-07 09:56 EDT == Summary:ADD_CUSTOM_TARGET with Fortran sources creates invalid Unix Makefiles Description: The add_custom_target allows to specify sources for IDE display but if any Fortran source is specified (and Fortran enabled) make fails with make[2]: *** No rule to make target 'CMakeFiles/copy.dir/requires'. Stop. The Visual studio generator creates a *.vfproj project in this case where custom commands only work partially (with Intel Fortran Compiler) - instead of a *.vcxproj when no sources are specified. - I would expect the build of a custom target to behave identical with or without sources specified. Steps to Reproduce: Run cmake to create Unix Makefiles for attached CMakeLists.txt, run make - shows specified error Additional Information: Stripped down from a huge project with many targets and a common pre-processing script to combine the fortran inputs for automatic interface check (not just copy like in the example). Works if the sources argument is removed from the ADD_CUSTOM_TARGET but for better support by IDEs we like to add this argument. Adding SET_SOURCE_FILES_PROPERTIES(s1.f PROPERTIES LANGUAGE ) Enables to run the custom command, but the compile does nothing then. Adding SET(CMAKE_Fortran_SOURCE_FILE_EXTENSIONS FFF) SET(CMAKE_Fortran_IGNORE_EXTENSIONS f) has no effect at all (and would only help too if it can be reset for and add_executable/add_library) Identical behaviour of CMake-3.0.2 and CMake-3.3. == Issue History Date ModifiedUsername FieldChange == 2015-08-07 09:56 bburgerm New Issue 2015-08-07 09:56 bburgerm File Added: CMakeLists.txt == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015690]: ctest doing one more undesirable run
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15690
==
Reported By:Clinton Stimpson
Assigned To:
==
Project:CMake
Issue ID: 15690
Category: CTest
Reproducibility:have not tried
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-08-07 16:41 EDT
Last Modified: 2015-08-07 16:41 EDT
==
Summary:ctest doing one more undesirable run
Description:
I call
ctest -VV -S my.ctest
and it goes through my script, then decides to do one more configure/build/test,
which I don't want.
Steps to Reproduce:
Use this ctest script:
set(CTEST_SOURCE_DIRECTORY ${CMAKE_CURRENT_LIST_DIR}/src)
set(CTEST_BINARY_DIRECTORY ${CMAKE_CURRENT_LIST_DIR}/build)
set(CTEST_CMAKE_GENERATOR Unix Makefiles)
set(CTEST_PROJECT_NAME all)
set(CTEST_CONFIGURATION_TYPE Release)
set(CTEST_COMMAND ctest)
function(doit)
ctest_start(Experimental)
ctest_configure()
ctest_build()
endfunction()
doit()
Additional Information:
Notice how I'm using a function(). If I change to a macro(), then the problem
goes away. But I don't want to do that.
A workaround is to add
set(CTEST_RUN_CURRENT_SCRIPT OFF)
at the bottom of my script (yuck).
==
Issue History
Date ModifiedUsername FieldChange
==
2015-08-07 16:41 Clinton StimpsonNew Issue
==
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, next, updated. v3.3.0-2096-gf08cc08
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via f08cc08dc647b09d2b5d6e0f681bd551c957db97 (commit)
via 7ba7ce98d5f19b64c44d731344fdef26317cd69c (commit)
via 3cefadbff07d68c5a6846835ea87cc35eae55a0b (commit)
from 010f4f8c6a8e6d45d7f49aa083d12f65de714557 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f08cc08dc647b09d2b5d6e0f681bd551c957db97
commit f08cc08dc647b09d2b5d6e0f681bd551c957db97
Merge: 010f4f8 7ba7ce9
Author: Chuck Atkins chuck.atk...@kitware.com
AuthorDate: Fri Aug 7 15:46:22 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Aug 7 15:46:22 2015 -0400
Merge topic 'add-global-link-static-properties' into next
7ba7ce98 Allow LINK_SEARCH_{START,END}_STATIC props to have default values.
3cefadbf CMake Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7ba7ce98d5f19b64c44d731344fdef26317cd69c
commit 7ba7ce98d5f19b64c44d731344fdef26317cd69c
Author: Chuck Atkins chuck.atk...@kitware.com
AuthorDate: Fri Aug 7 15:11:57 2015 -0400
Commit: Chuck Atkins chuck.atk...@kitware.com
CommitDate: Fri Aug 7 15:27:30 2015 -0400
Allow LINK_SEARCH_{START,END}_STATIC props to have default values.
Use the CMAKE_LINK_SEARCH_START_STATIC and CMAKE_LINK_SEARCH_END_STATIC
variables to initialize the LINK_SEARCH_START_STATIC and
LINK_SEARCH_END_STATIC target properties respectively.
diff --git a/Help/prop_tgt/LINK_SEARCH_END_STATIC.rst
b/Help/prop_tgt/LINK_SEARCH_END_STATIC.rst
index fe105bd..cf9c871 100644
--- a/Help/prop_tgt/LINK_SEARCH_END_STATIC.rst
+++ b/Help/prop_tgt/LINK_SEARCH_END_STATIC.rst
@@ -10,5 +10,9 @@ paths are not known or (in some cases) are in implicit link
directories for the platform. By default CMake adds an option at the
end of the library list (if necessary) to set the linker search type
back to its starting type. This property switches the final linker
-search type to -Bstatic regardless of how it started. See also
-LINK_SEARCH_START_STATIC.
+search type to -Bstatic regardless of how it started.
+
+This property is initialized by the value of the variable
+CMAKE_LINK_SEARCH_END_STATIC if it is set when a target is created.
+
+See also LINK_SEARCH_START_STATIC.
diff --git a/Help/prop_tgt/LINK_SEARCH_START_STATIC.rst
b/Help/prop_tgt/LINK_SEARCH_START_STATIC.rst
index ca899fe..2e0f9bd 100644
--- a/Help/prop_tgt/LINK_SEARCH_START_STATIC.rst
+++ b/Help/prop_tgt/LINK_SEARCH_START_STATIC.rst
@@ -11,4 +11,9 @@ directories for the platform. By default the linker search
type is
assumed to be -Bdynamic at the beginning of the library list. This
property switches the assumption to -Bstatic. It is intended for use
when linking an executable statically (e.g. with the GNU -static
-option). See also LINK_SEARCH_END_STATIC.
+option).
+
+This property is initialized by the value of the variable
+CMAKE_LINK_SEARCH_START_STATIC if it is set when a target is created.
+
+See also LINK_SEARCH_END_STATIC.
diff --git a/Help/prop_tgt/LINK_SEARCH_END_STATIC.rst
b/Help/variable/CMAKE_LINK_SEARCH_END_STATIC.rst
similarity index 68%
copy from Help/prop_tgt/LINK_SEARCH_END_STATIC.rst
copy to Help/variable/CMAKE_LINK_SEARCH_END_STATIC.rst
index fe105bd..8a9951d 100644
--- a/Help/prop_tgt/LINK_SEARCH_END_STATIC.rst
+++ b/Help/variable/CMAKE_LINK_SEARCH_END_STATIC.rst
@@ -1,5 +1,5 @@
-LINK_SEARCH_END_STATIC
---
+CMAKE_LINK_SEARCH_END_STATIC
+
End a link line such that static system libraries are used.
@@ -10,5 +10,9 @@ paths are not known or (in some cases) are in implicit link
directories for the platform. By default CMake adds an option at the
end of the library list (if necessary) to set the linker search type
back to its starting type. This property switches the final linker
-search type to -Bstatic regardless of how it started. See also
-LINK_SEARCH_START_STATIC.
+search type to -Bstatic regardless of how it started.
+
+This variable is used to initialize the target property
+LINK_SEARCH_END_STATIC for all targets.
+
+See also CMAKE_LINK_SEARCH_START_STATIC.
diff --git a/Help/prop_tgt/LINK_SEARCH_START_STATIC.rst
b/Help/variable/CMAKE_LINK_SEARCH_START_STATIC.rst
similarity index 73%
copy from Help/prop_tgt/LINK_SEARCH_START_STATIC.rst
copy to Help/variable/CMAKE_LINK_SEARCH_START_STATIC.rst
index ca899fe..715db4b 100644
--- a/Help/prop_tgt/LINK_SEARCH_START_STATIC.rst
+++ b/Help/variable/CMAKE_LINK_SEARCH_START_STATIC.rst
@@ -1,5 +1,5 @@
-LINK_SEARCH_START_STATIC
-
+CMAKE_LINK_SEARCH_START_STATIC
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
I have two changes in FindPythonLibs that should make for less failure
in
the MINGW/MSYS camp.
While I support this stuff, I think for it to not
break other people (who use either mingw.org/MinGW-w64 compilers or
the old MSYS with 'normal' Windows CPython),
If there is not a python installation to be found in the mingw path, the
patched routine will drop into the registry search. which will look exactly
like previous.
I think you explicitly mean the MSYS2 camp here. We have our own
Pythons (4 of them, 2 native and 2 cygwin-y) all of which use a
Linux-y layout.
I've been running with msys2, and lately I've done a lot of test-running
of plplot using plain vanilla
CMake without the patches I used to think were needed. I found that from
the CMake point of view,
msys1 or msys2 is a distinction without a difference.
CMake needs to be able to
identify MSYS2 distinctly from both MINGW and MSYS first. Would a
patch making that distinction be acceptable to CMake?
I have used CMakeFindMSYSmake and CMakeFindUnixMake to set a variable
designating
what /usr translates to:
#
# the variable MSYS_USR_PATH is here created for use
# where the /usr provided by an MSYS app needs to be translated for Windows.
#
unset(_BIN)
find_path( _BIN msys-1.0.dll NAMES msys-2.0.dll HINTS ENV PATH
NO_DEFAULT_PATH)
if(_BIN)
set(MSYS 1)
find_path( MSYS_USR_PATH bin PATHS ${_BIN}/../NO_DEFAULT_PATH)
mark_as_advanced(MSYS_USR_PATH)
message(STATUS CMakeUnixFindMake: MSYS dll found on
${MSYS_USR_PATH})
endif()
unset(_BIN)
On Fri, Aug 7, 2015 at 2:25 AM, Ray Donnelly mingw.andr...@gmail.com
wrote:
On Fri, Aug 7, 2015 at 7:58 AM, Greg Jung gvj...@gmail.com wrote:
Hi there,
A patch for review:
I have two changes in FindPythonLibs that should make for less failure
in
the MINGW/MSYS camp.
I think you explicitly mean the MSYS2 camp here. We have our own
Pythons (4 of them, 2 native and 2 cygwin-y) all of which use a
Linux-y layout. While I support this stuff, I think for it to not
break other people (who use either mingw.org/MinGW-w64 compilers or
the old MSYS with 'normal' Windows CPython), CMake needs to be able to
identify MSYS2 distinctly from both MINGW and MSYS first. Would a
patch making that distinction be acceptable to CMake?
1. Distinguish mingw and win32. Avoid the registry lookup.
if(WIN32) = if(WIN32 AND NOT (MINGW OR MSYS)) for the DEBUG library
search,
a full unix-style find_library call without reference to possible
registry
entries.
+NAMES
+python${_CURRENT_VERSION_NO_DOTS}
+python${_CURRENT_VERSION}mu
+python${_CURRENT_VERSION}m
+python${_CURRENT_VERSION}u
+python${_CURRENT_VERSION}
+#
+NAMES_PER_DIR
+# Avoid finding the .dll in the PATH. We want the .lib.
+# The NAMES_PER_DIR above should allow the library to be found where it
was
desired
+# in the prioritized location of PATH - cmake V3.3 behavior;
+#NO_SYSTEM_ENVIRONMENT_PATH works counter to cmake-3.3 improvement
where CMake will look into path.
+#
+ )
+endif()
2. NAMES_PER_DIR replaces NO_SYSTEM_ENVIRONMENT_PATH to modify the search
such that windows/system32/python27.dll
(for instance) is not picked up before finding the proper library under
path component/lib
Instead of throwing all of the possible locations into a single
find_library(), for WIN32+MINGW builds this may latch into a windows'
python.
This is not an issue when CMake is run from /MINGW.
CMake-3.3.0 (and above) can use PATH to discover targets of find_library,
allowing
a user with several MINGW installations to use a single cmake (and
cmake-gui) instead of
installing several copies for each mingw to be built with. Unless the
find_path or
find_library uses NO_SYSTEM_ENVIRONMENT_PATH which kills the new
feature.
Even though /mingw32/bin is frontmost in the path,
windows/system32/python27.dll
was latched onto because the name matches earlier in the NAMES list than
python2.7.
to avoid this all of the names are tested as the direcftories are
presented,
this via the
NAMES_PER_DIR qualifier.
This makes is possible for me to run builds using Cmake-gui without
installing cmake-gui
in /mingw32/bin (and qt5 along with it!).
Regards,
Greg
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
Re: [cmake-developers] Fixing bug #12506 (iOS install)
Hi,
On 07/08/15 00:43, Ruslan Baratov via cmake-developers wrote:
Hi,
I'm thinking about fixing bug
http://public.kitware.com/Bug/view.php?id=12506 and before I go deeper
in CMake internals just want to ask is there any work-in-progress
attempts already or hints/directions of how it can be done?
I started to look into this and as far as I remember built a PoC for the
case where you do not build Simulator and non-Simulator within the same
Xcode project. But I never found the time to write down a summary of
that complicated topic.
Currently I work around by calling from my build script:
${CMAKE} -DBUILD_TYPE=${CONFIG} -P ${BUILD_DIR}/cmake_install.cmake
I will try to attach something to the bug report within the next days.
Thanks,
Gregor
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
On Fri, Aug 7, 2015 at 7:58 AM, Greg Jung gvj...@gmail.com wrote:
Hi there,
A patch for review:
I have two changes in FindPythonLibs that should make for less failure in
the MINGW/MSYS camp.
I think you explicitly mean the MSYS2 camp here. We have our own
Pythons (4 of them, 2 native and 2 cygwin-y) all of which use a
Linux-y layout. While I support this stuff, I think for it to not
break other people (who use either mingw.org/MinGW-w64 compilers or
the old MSYS with 'normal' Windows CPython), CMake needs to be able to
identify MSYS2 distinctly from both MINGW and MSYS first. Would a
patch making that distinction be acceptable to CMake?
1. Distinguish mingw and win32. Avoid the registry lookup.
if(WIN32) = if(WIN32 AND NOT (MINGW OR MSYS)) for the DEBUG library search,
a full unix-style find_library call without reference to possible registry
entries.
+NAMES
+python${_CURRENT_VERSION_NO_DOTS}
+python${_CURRENT_VERSION}mu
+python${_CURRENT_VERSION}m
+python${_CURRENT_VERSION}u
+python${_CURRENT_VERSION}
+#
+NAMES_PER_DIR
+# Avoid finding the .dll in the PATH. We want the .lib.
+# The NAMES_PER_DIR above should allow the library to be found where it was
desired
+# in the prioritized location of PATH - cmake V3.3 behavior;
+#NO_SYSTEM_ENVIRONMENT_PATH works counter to cmake-3.3 improvement
where CMake will look into path.
+#
+ )
+endif()
2. NAMES_PER_DIR replaces NO_SYSTEM_ENVIRONMENT_PATH to modify the search
such that windows/system32/python27.dll
(for instance) is not picked up before finding the proper library under
path component/lib
Instead of throwing all of the possible locations into a single
find_library(), for WIN32+MINGW builds this may latch into a windows'
python.
This is not an issue when CMake is run from /MINGW.
CMake-3.3.0 (and above) can use PATH to discover targets of find_library,
allowing
a user with several MINGW installations to use a single cmake (and
cmake-gui) instead of
installing several copies for each mingw to be built with. Unless the
find_path or
find_library uses NO_SYSTEM_ENVIRONMENT_PATH which kills the new feature.
Even though /mingw32/bin is frontmost in the path,
windows/system32/python27.dll
was latched onto because the name matches earlier in the NAMES list than
python2.7.
to avoid this all of the names are tested as the direcftories are presented,
this via the
NAMES_PER_DIR qualifier.
This makes is possible for me to run builds using Cmake-gui without
installing cmake-gui
in /mingw32/bin (and qt5 along with it!).
Regards,
Greg
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Java support
Hi, New version of patch attached. I added a check on java tool to execute test only if java and shared library built by test have same architecture (32 or 64bit). Marc On 05/08/15 17:49, Brad King brad.k...@kitware.com wrote: On 08/05/2015 03:15 AM, CHEVRIER, Marc wrote: For point 2., The best approach is to install 32 and 64bit versions of Java SDK (Windows versions, not some cygwin or MSYS versions) and ensure JAVA_HOME is NOT set in the environment nor referenced in the PATH. In this case, CMake FindJava.cmake module will look at the registry to retrieve the correct java version. CMake's test suite needs to adapt to the environment in which it is run and not run this test unless the architecture of java and the toolchain match. Certainly we can set up an environment in which it works but we should not fail just because that hasn't been done. On 08/05/2015 06:24 AM, CHEVRIER, Marc wrote: Again, a new version for patch 4. Thanks. I'd prefer not to enable CXX as a language in the project() command such that it affects the other Java tests. Please create a separate source tree for the new test. Sorry I didn't notice this earlier. Meanwhile the other three patches now tested cleanly. Thanks, -Brad 0004-Add-support-for-javah-tool.patch Description: 0004-Add-support-for-javah-tool.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015687]: target_include_directories(): SYSTEM option does not seem to work when targeting Xcode.
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15687
==
Reported By:Adn
Assigned To:
==
Project:CMake
Issue ID: 15687
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-08-07 04:07 EDT
Last Modified: 2015-08-07 04:07 EDT
==
Summary:target_include_directories(): SYSTEM option does not
seem to work when targeting Xcode.
Description:
Following the documentation for target_include_directories():
http://www.cmake.org/cmake/help/v3.0/command/target_include_directories.html
We tried to provide the SYSTEM argument to target_include_directories(), to
prevent a third party library to issue a lot of warnings. We expected it to put
the library's include path on the C++ flags line, behind -isystem, but it had
actually no effect, still using this path as if SYSTEM was not given.
We attached in Steps To Reproduce the minimal example reproducing this problem
in our environment:
*CMake v3.3.0 (also tested with v3.0.0 for the same results)
*OS X 10.9.5
*Xcode 5.1.1
There is a mailing list thread discussion this issue, that seems to point to the
incriminated code:
http://www.cmake.org/pipermail/cmake/2015-August/061322.html
Steps to Reproduce:
cmake_minimum_required(VERSION 3.0)
find_package(Boost 1.49 COMPONENTS)
project(system_dependencies)
add_executable(${PROJECT_NAME} main.cpp)
target_include_directories(${PROJECT_NAME} SYSTEM PUBLIC ${Boost_INCLUDE_DIRS})
Additional Information:
There is also a Stack Overflow question:
http://stackoverflow.com/q/31722426
==
Issue History
Date ModifiedUsername FieldChange
==
2015-08-07 04:07 AdnNew Issue
==
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[CMake] emulating cmake-gui behaviour with cmake commandline on windows
Hi, I am trying to build the CMake project 3dtk with the following CMakeLists.txt: https://sourceforge.net/p/slam6d/code/HEAD/tree/trunk/CMakeLists.txt This works well on linux with ccmake and also on windows with cmake-gui. Now I'm trying to let it work on windows with the cmake command line program to automate the configuration. Unfortunately I'm running into a problem with cmake on windows that I did not encounter with cmake-gui. The CMakeLists.txt file at several occasions uses the add_subdirectory directive but always without the second argument (the build_dir). This seems to work fine for cmake-gui on windows and ccmake on linux. But with cmake on windows I now get the following message for every add_subdirectory directive: CMake Error at Z:/CMakeLists.txt:471 (add_subdirectory): add_subdirectory not given a binary directory but the given source directory Z:/src/slam6d is not a subdirectory of Z:/. When specifying an out-of-tree source a binary directory must be explicitly specified. This error message is also strange because clearly, Z:/src/slam6d is a subdirectory of Z:/. I would like to know the command line option that I have to supply to cmake on windows to get the same behaviour as with cmake-gui on windows. In my case, the source is in Z:/ and in cmake-gui I specify Z:/lib64-msvc-12.0 as the value of Where to build the binaries and as explained above this works completely well. But after successfully configuring and generating the project in Z:/lib64-msvc-12.0 using the cmake-gui method, when I cd into Z:/lib64-msvc-12.0 and just run cmake .. I get the error messages above. Same happens when I create a new directory Z:/cmaketest, cd into it and then run cmake .., I again get the errors above. So in summary, with or without an existing CMakeCache.txt, I'm running into the error messages above on windows when using cmake (and not cmake-gui). So I suspect that I'm missing an option to cmake to make it behave like cmake-gui. I don't think my CMakeLists.txt is the culprit because that one works totally fine on linux and also works well with cmake-gui. What could the problem be? Thanks! cheers, josch signature.asc Description: signature -- 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
[cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
Hi there,
A patch for review:
I have two changes in FindPythonLibs that should make for less failure in
the MINGW/MSYS camp.
1. Distinguish mingw and win32. Avoid the registry lookup.
if(WIN32) = if(WIN32 AND NOT (MINGW OR MSYS)) for the DEBUG library search,
a full unix-style find_library call without reference to possible registry
entries.
+NAMES
+python${_CURRENT_VERSION_NO_DOTS}
+python${_CURRENT_VERSION}mu
+python${_CURRENT_VERSION}m
+python${_CURRENT_VERSION}u
+python${_CURRENT_VERSION}
+#
+NAMES_PER_DIR
+# Avoid finding the .dll in the PATH. We want the .lib.
+# The NAMES_PER_DIR above should allow the library to be found where it
was desired
+# in the prioritized location of PATH - cmake V3.3 behavior;
+#NO_SYSTEM_ENVIRONMENT_PATH works counter to cmake-3.3 improvement
where CMake will look into path.
+#
+ )
+endif()
2. NAMES_PER_DIR replaces NO_SYSTEM_ENVIRONMENT_PATH to modify the search
such that windows/system32/python27.dll
(for instance) is not picked up before finding the proper library under
path component/lib
Instead of throwing all of the possible locations into a single
find_library(), for WIN32+MINGW builds this may latch into a windows'
python.
This is not an issue when CMake is run from /MINGW.
CMake-3.3.0 (and above) can use PATH to discover targets of find_library,
allowing
a user with several MINGW installations to use a single cmake (and
cmake-gui) instead of
installing several copies for each mingw to be built with. Unless the
find_path or
find_library uses NO_SYSTEM_ENVIRONMENT_PATH which kills the new feature.
Even though /mingw32/bin is frontmost in the path,
windows/system32/python27.dll
was latched onto because the name matches earlier in the NAMES list than
python2.7.
to avoid this all of the names are tested as the direcftories are
presented, this via the
NAMES_PER_DIR qualifier.
This makes is possible for me to run builds using Cmake-gui without
installing cmake-gui
in /mingw32/bin (and qt5 along with it!).
Regards,
Greg
0001-FindPythonLibs-avoids-registry-if-MINGWE-or-MSYS.patch
Description: Binary data
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] target_include_directories(): SYSTEM option does not seem to work on recent versions of CMake, when targeting Xcode.
Opened issue 15687 for this problem:
http://www.cmake.org/Bug/view.php?id=15687
Thank again for your help Nils.
(ps: sorry, just realize now that I forgot to forward other answers to the
list... Pasting the content below)
2015-08-07 9:27 GMT+02:00 A D boitole...@gmail.com:
2015-08-06 10:57 GMT+02:00 Nils Gladitz nilsglad...@gmail.com:
suggesting that even though the compiler might support -isystem, Xcode
itself does (or did) not. I can't tell if that is something that may or may
not have changed with current Xcode releases.
Xcode has been calling Clang behind the scene (I think it was a custom
Apple GCC before). There is an Xcode setting for header search path,
which is a list of 'non-system' headers. Even if there is not a separate
Xcode settings for system headers, there is a setting for the cpp flags
that are directly forwarded to the compiler: in practice, this allows to
achieve everything that would be possible by invoking Clang directly. In
particular, if I take the path from header search path setting, and put
it as -isystem ${path_value} in the Other C++ flags setting, I obtain
the expected result.
If you have reason to believe it is supported now (e.g. because you are
able to create and Xcode project without cmake that has explicit system
includes) you may want to open an issue.
Thank you for this suggestion, I will report the issue referring to this
exchange.
Best regards,
2015-08-07 9:55 GMT+02:00 A D boitole...@gmail.com:
2015-08-07 9:31 GMT+02:00 Nils Gladitz nilsglad...@gmail.com:
One issue you might want to look for when passing the flag directly to
the compiler without allowing IDE interpretation might be that the internal
code model used by Xcode for e.g. auto-completion might then not know about
it.
That is a good point indeed. So I just tried, and both the linter and
auto-completion seem to make no difference with regard to how the header
path is provided to the project (they kept working in the same way):
* The linter stopped 'underlining' the boost include as soon as I gave the
'-isystem path' to the C++ flags
* Adding a new library to this '-isystem' flag, auto-completion was aware
of its symbols as soon as I included its headers in a compilation units.
--
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
Re: [cmake-developers] Fixing bug #12506 (iOS install)
On 07-Aug-15 11:31, Gregor Jasny wrote:
Hi,
On 07/08/15 00:43, Ruslan Baratov via cmake-developers wrote:
Hi,
I'm thinking about fixing bug
http://public.kitware.com/Bug/view.php?id=12506 and before I go deeper
in CMake internals just want to ask is there any work-in-progress
attempts already or hints/directions of how it can be done?
I started to look into this and as far as I remember built a PoC for
the case where you do not build Simulator and non-Simulator within the
same Xcode project. But I never found the time to write down a summary
of that complicated topic.
Currently I work around by calling from my build script:
${CMAKE} -DBUILD_TYPE=${CONFIG} -P ${BUILD_DIR}/cmake_install.cmake
I will try to attach something to the bug report within the next days.
Thanks,
Gregor
Hi,
I've tried it with simple example and have an error:
rm -rf _builds
cmake -H. -B_builds -GXcode -DCMAKE_INSTALL_PREFIX=`pwd`/_install
cmake -DBUILD_TYPE=Debug -P _builds/cmake_install.cmake
-- Install configuration: Debug
CMake Error at _builds/cmake_install.cmake:32 (file):
file INSTALL cannot find
/.../_builds/Debug$(EFFECTIVE_PLATFORM_NAME)/libfoo.a.
Executable runs fine on device. Library builds fine too but install step
fail. See CMakeLists.txt in attachment.
What generator and toolchain are you using?
Ruslo
cmake_minimum_required(VERSION 3.0)
project(Foo)
set(CMAKE_OSX_SYSROOT iphoneos)
set(CMAKE_XCODE_EFFECTIVE_PLATFORMS -iphoneos;-iphonesimulator)
set(CMAKE_MACOSX_BUNDLE YES)
set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY iPhone Developer)
set(MACOSX_BUNDLE_GUI_IDENTIFIER com.example)
add_executable(foo_exe foo.cpp)
add_library(foo foo.cpp)
install(TARGETS foo DESTINATION lib)
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] Imported OpenSSL
Hi developers and experts OpenSSL! I added a little boring and dense of code at the end FindOpenSSL.cmake module. I just want to have imported the OpenSSL library for creating relocatable packages. I created a theme topic-imported-openssl on my server: http://git.podsvirov.pro/?p=kitware/cmake.git;a=shortlog;h=refs/heads/topic-imported-openssl Now I have a single commit: http://git.podsvirov.pro/?p=kitware/cmake.git;a=commit;h=b47293f212f270844dcd32e36cff2a8668080c46 If I did everything correctly, then please apply my changes or to help with advice or deed :-) -- Regards, Konstantin Podsvirov -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] emulating cmake-gui behaviour with cmake commandline on windows
Put your source in a sub-directory. CMake simply does not work at the root of a drive letter on Windows. CMakeLists.txt MUST be in at least one sub-directory underneath a root drive letter path. HTH, David C. On Fri, Aug 7, 2015 at 5:08 AM, Johannes Schauer jo...@debian.org wrote: Hi, I am trying to build the CMake project 3dtk with the following CMakeLists.txt: https://sourceforge.net/p/slam6d/code/HEAD/tree/trunk/CMakeLists.txt This works well on linux with ccmake and also on windows with cmake-gui. Now I'm trying to let it work on windows with the cmake command line program to automate the configuration. Unfortunately I'm running into a problem with cmake on windows that I did not encounter with cmake-gui. The CMakeLists.txt file at several occasions uses the add_subdirectory directive but always without the second argument (the build_dir). This seems to work fine for cmake-gui on windows and ccmake on linux. But with cmake on windows I now get the following message for every add_subdirectory directive: CMake Error at Z:/CMakeLists.txt:471 (add_subdirectory): add_subdirectory not given a binary directory but the given source directory Z:/src/slam6d is not a subdirectory of Z:/. When specifying an out-of-tree source a binary directory must be explicitly specified. This error message is also strange because clearly, Z:/src/slam6d is a subdirectory of Z:/. I would like to know the command line option that I have to supply to cmake on windows to get the same behaviour as with cmake-gui on windows. In my case, the source is in Z:/ and in cmake-gui I specify Z:/lib64-msvc-12.0 as the value of Where to build the binaries and as explained above this works completely well. But after successfully configuring and generating the project in Z:/lib64-msvc-12.0 using the cmake-gui method, when I cd into Z:/lib64-msvc-12.0 and just run cmake .. I get the error messages above. Same happens when I create a new directory Z:/cmaketest, cd into it and then run cmake .., I again get the errors above. So in summary, with or without an existing CMakeCache.txt, I'm running into the error messages above on windows when using cmake (and not cmake-gui). So I suspect that I'm missing an option to cmake to make it behave like cmake-gui. I don't think my CMakeLists.txt is the culprit because that one works totally fine on linux and also works well with cmake-gui. What could the problem be? Thanks! cheers, josch -- 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 -- 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
Re: [CMake] emulating cmake-gui behaviour with cmake commandline on windows
Hi, Quoting David Cole (2015-08-07 18:27:40) Put your source in a sub-directory. CMake simply does not work at the root of a drive letter on Windows. CMakeLists.txt MUST be in at least one sub-directory underneath a root drive letter path. oh wow that was a simple fix. Thanks for the quick reply! Is this documented anywhere? Maybe there could be a warning somewhere if one attempts to have the source directory directly at the root of a drive letter on windows? But then why does it work with cmake-gui on windows? Is this a bug that can be fixed? Thanks! cheers, josch signature.asc Description: signature -- 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
[Cmake-commits] CMake branch, next, updated. v3.3.0-2093-g010f4f8
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 010f4f8c6a8e6d45d7f49aa083d12f65de714557 (commit)
via 03dd19a3eef57d6edfff017dae4aba0a62d9f165 (commit)
via 3bbd5425d31e179dbb1b70d944ac24523b0eb46b (commit)
via 197f4de110a59332757360110b1e90f6b07e1c97 (commit)
via 44e071aeff4d533f116a7721919f9036c5d5a1d1 (commit)
via 772ecef4b8037d5ce59d24772c05829872aff406 (commit)
via 1f54bc1cf35707a5f1410ff4c6632d7cba351c40 (commit)
via 7568199b4de18ed56ad8ef735c145c4a44327355 (commit)
from ffdce7ed84af2fd2e4e189789ea83a70785f03ad (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=010f4f8c6a8e6d45d7f49aa083d12f65de714557
commit 010f4f8c6a8e6d45d7f49aa083d12f65de714557
Merge: ffdce7e 03dd19a
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Aug 7 11:06:31 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Aug 7 11:06:31 2015 -0400
Merge topic 'use-generator-target' into next
03dd19a3 cmTarget: Use a simpler delete algorithm.
3bbd5425 cmTarget: Split storage of sources from genexes.
197f4de1 cmTarget: Split storage of compile definitions from genexes.
44e071ae cmTarget: Split storage of compile features from genexes.
772ecef4 cmTarget: Split storage of compile options from genexes.
1f54bc1c cmTarget: Split storage of include directories from genexes.
7568199b cmTarget: Request only the link libraries where needed.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=03dd19a3eef57d6edfff017dae4aba0a62d9f165
commit 03dd19a3eef57d6edfff017dae4aba0a62d9f165
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Aug 4 23:16:12 2015 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Fri Aug 7 17:06:20 2015 +0200
cmTarget: Use a simpler delete algorithm.
This way, the methods can be moved without requiring a local algorithm.
The containers use automatic storage.
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index d30f2f5..f1a05ff 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -193,14 +193,6 @@ public:
cmLinkImplItem cmTargetInternals::TargetPropertyEntry::NoLinkImplItem;
//
-static void deleteAndClear(
- std::vectorcmTargetInternals::TargetPropertyEntry* entries)
-{
- cmDeleteAll(entries);
- entries.clear();
-}
-
-//
cmTargetInternals::~cmTargetInternals()
{
}
@@ -817,7 +809,7 @@ void cmTarget::GetSourceFiles(std::vectorstd::string
files,
this-LinkImplementationLanguageIsContextDependent = false;
}
- deleteAndClear(linkInterfaceSourcesEntries);
+ cmDeleteAll(linkInterfaceSourcesEntries);
}
//
@@ -2172,7 +2164,7 @@ cmTarget::GetIncludeDirectories(const std::string config,
debugIncludes,
language);
- deleteAndClear(linkInterfaceIncludeDirectoriesEntries);
+ cmDeleteAll(linkInterfaceIncludeDirectoriesEntries);
return includes;
}
@@ -2293,7 +2285,7 @@ void cmTarget::GetCompileOptions(std::vectorstd::string
result,
debugOptions,
language);
- deleteAndClear(linkInterfaceCompileOptionsEntries);
+ cmDeleteAll(linkInterfaceCompileOptionsEntries);
}
//
@@ -2395,7 +2387,7 @@ void
cmTarget::GetCompileDefinitions(std::vectorstd::string list,
debugDefines,
language);
- deleteAndClear(linkInterfaceCompileDefinitionsEntries);
+ cmDeleteAll(linkInterfaceCompileDefinitionsEntries);
}
//
@@ -2462,7 +2454,7 @@ void
cmTarget::GetCompileFeatures(std::vectorstd::string result,
config,
debugFeatures);
- deleteAndClear(linkInterfaceCompileFeaturesEntries);
+ cmDeleteAll(linkInterfaceCompileFeaturesEntries);
}
//
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3bbd5425d31e179dbb1b70d944ac24523b0eb46b
commit 3bbd5425d31e179dbb1b70d944ac24523b0eb46b
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Aug 4 21:46:15 2015 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Fri Aug 7 17:06:19 2015
[Cmake-commits] CMake branch, next, updated. v3.3.0-2085-gffdce7e
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via ffdce7ed84af2fd2e4e189789ea83a70785f03ad (commit)
via 95f456d39b5983119956e071d9d2ac8084eb86d5 (commit)
via 0cc9e0588bdca72028ae13571470f3a11fe80b1a (commit)
via bc0e24a0d70a4042d505fb9324e5a718603ef75c (commit)
from a4634fb344e70d913df2d9dbeb41ec697648f4b0 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ffdce7ed84af2fd2e4e189789ea83a70785f03ad
commit ffdce7ed84af2fd2e4e189789ea83a70785f03ad
Merge: a4634fb 95f456d
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Aug 7 11:05:52 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Aug 7 11:05:52 2015 -0400
Merge topic 'use-generator-target' into next
95f456d3 Revert cmGlobalGenerator: Return null generator target for
target.
0cc9e058 Revert cmGeneratorTarget: Move GetLinkInterface from cmTarget.
bc0e24a0 Revert cmGeneratorTarget: Move link iface helpers from cmTarget.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=95f456d39b5983119956e071d9d2ac8084eb86d5
commit 95f456d39b5983119956e071d9d2ac8084eb86d5
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Aug 7 17:05:09 2015 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Fri Aug 7 17:05:09 2015 +0200
Revert cmGlobalGenerator: Return null generator target for target.
This reverts commit 239c6d37e28e3a979122999e8555696865fb4824.
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index 195fa0d..50e2cd9 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -1618,11 +1618,6 @@ void cmGlobalGenerator::ClearGeneratorMembers()
cmGeneratorTarget*
cmGlobalGenerator::GetGeneratorTarget(cmTarget const* t) const
{
- if (!t)
-{
-return 0;
-}
-
cmGeneratorTargetsType::const_iterator ti = this-GeneratorTargets.find(t);
if(ti == this-GeneratorTargets.end())
{
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0cc9e0588bdca72028ae13571470f3a11fe80b1a
commit 0cc9e0588bdca72028ae13571470f3a11fe80b1a
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Aug 7 17:05:04 2015 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Fri Aug 7 17:05:04 2015 +0200
Revert cmGeneratorTarget: Move GetLinkInterface from cmTarget.
This reverts commit ae94ca1c5902dc12ddd7eb7a9e4b197ddde5c884.
diff --git a/Source/cmComputeLinkDepends.cxx b/Source/cmComputeLinkDepends.cxx
index b657765..8ba8847 100644
--- a/Source/cmComputeLinkDepends.cxx
+++ b/Source/cmComputeLinkDepends.cxx
@@ -363,10 +363,8 @@ void cmComputeLinkDepends::FollowLinkEntry(BFSEntry const
qe)
if(entry.Target)
{
// Follow the target dependencies.
-cmGeneratorTarget* gtgt =
-this-GlobalGenerator-GetGeneratorTarget(entry.Target);
-if(cmGeneratorTarget::LinkInterface const* iface =
- gtgt-GetLinkInterface(this-Config, this-Target-Target))
+if(cmTarget::LinkInterface const* iface =
+ entry.Target-GetLinkInterface(this-Config, this-Target-Target))
{
const bool isIface =
entry.Target-GetType() == cmTarget::INTERFACE_LIBRARY;
@@ -400,8 +398,7 @@ void cmComputeLinkDepends::FollowLinkEntry(BFSEntry const
qe)
//
void
cmComputeLinkDepends
-::FollowSharedDeps(int depender_index,
- cmGeneratorTarget::LinkInterface const* iface,
+::FollowSharedDeps(int depender_index, cmTarget::LinkInterface const* iface,
bool follow_interface)
{
// Follow dependencies if we have not followed them already.
@@ -464,10 +461,8 @@ void
cmComputeLinkDepends::HandleSharedDependency(SharedDepEntry const dep)
// Target items may have their own dependencies.
if(entry.Target)
{
-cmGeneratorTarget* gtgt =
-this-GlobalGenerator-GetGeneratorTarget(entry.Target);
-if(cmGeneratorTarget::LinkInterface const* iface =
- gtgt-GetLinkInterface(this-Config, this-Target-Target))
+if(cmTarget::LinkInterface const* iface =
+ entry.Target-GetLinkInterface(this-Config, this-Target-Target))
{
// Follow public and private dependencies transitively.
this-FollowSharedDeps(index, iface, true);
@@ -937,10 +932,8 @@ int cmComputeLinkDepends::ComputeComponentCount(NodeList
const nl)
{
if(cmTarget const* target = this-EntryList[*ni].Target)
{
- cmGeneratorTarget* gtgt =
- this-GlobalGenerator-GetGeneratorTarget(target);
- if(cmGeneratorTarget::LinkInterface const*
Re: [CMake] emulating cmake-gui behaviour with cmake commandline on windows
It's in the bug database here: http://www.cmake.org/Bug/view.php?id=15134 Not sure how easy it would be to fix... Also, this CLOSED bug is in there (and some related issues): http://www.cmake.org/Bug/view.php?id=10072 D On Fri, Aug 7, 2015 at 12:37 PM, Johannes Schauer jo...@debian.org wrote: Hi, Quoting David Cole (2015-08-07 18:27:40) Put your source in a sub-directory. CMake simply does not work at the root of a drive letter on Windows. CMakeLists.txt MUST be in at least one sub-directory underneath a root drive letter path. oh wow that was a simple fix. Thanks for the quick reply! Is this documented anywhere? Maybe there could be a warning somewhere if one attempts to have the source directory directly at the root of a drive letter on windows? But then why does it work with cmake-gui on windows? Is this a bug that can be fixed? Thanks! cheers, josch -- 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
[Cmake-commits] CMake branch, next, updated. v3.3.0-2098-g67df5c9
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 67df5c9aeee85453af8e53562b97f21dd4a40c55 (commit)
via 6e13042cec7ca40cdb1a52ae92ccb6693bcba53b (commit)
from f08cc08dc647b09d2b5d6e0f681bd551c957db97 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=67df5c9aeee85453af8e53562b97f21dd4a40c55
commit 67df5c9aeee85453af8e53562b97f21dd4a40c55
Merge: f08cc08 6e13042
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Aug 7 15:55:05 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Aug 7 15:55:05 2015 -0400
Merge topic 'use-generator-target' into next
6e13042c Revert cmTarget: Split storage of sources from genexes.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6e13042cec7ca40cdb1a52ae92ccb6693bcba53b
commit 6e13042cec7ca40cdb1a52ae92ccb6693bcba53b
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Aug 7 21:54:31 2015 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Fri Aug 7 21:54:31 2015 +0200
Revert cmTarget: Split storage of sources from genexes.
This reverts commit 3bbd5425d31e179dbb1b70d944ac24523b0eb46b.
diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index b094125..ce806ba 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -313,9 +313,7 @@ bool
cmQtAutoGenerators::InitializeAutogenTarget(cmLocalGenerator* lg,
makefile-AppendProperty(ADDITIONAL_MAKE_CLEAN_FILES,
mocCppFile.c_str(), false);
-std::vectorstd::string mocCppFiles;
-mocCppFiles.push_back(mocCppFile);
-target-AddTracedSources(mocCppFiles);
+target-AddSource(mocCppFile);
}
// create a custom target for running generators at buildtime:
std::string autogenTargetName = getAutogenTargetName(target);
@@ -739,7 +737,12 @@ void cmQtAutoGenerators::SetupSourceFiles(cmTarget const*
target)
}
}
- const_castcmTarget*(target)-AddTracedSources(newRccFiles);
+ for(std::vectorstd::string::const_iterator fileIt = newRccFiles.begin();
+ fileIt != newRccFiles.end();
+ ++fileIt)
+{
+const_castcmTarget*(target)-AddSource(*fileIt);
+}
}
void cmQtAutoGenerators::SetupAutoMocTarget(cmTarget const* target,
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index f1a05ff..d3170e4 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -180,9 +180,7 @@ public:
std::vectorstd::string CompileDefinitionsEntries;
std::vectorcmListFileBacktrace CompileDefinitionsBacktraces;
std::vectorTargetPropertyEntry* CompileDefinitionsItems;
- std::vectorstd::string SourceEntries;
- std::vectorcmListFileBacktrace SourceBacktraces;
- std::vectorTargetPropertyEntry* SourceItems;
+ std::vectorTargetPropertyEntry* SourceEntries;
std::vectorcmValueWithOrigin LinkImplementationPropertyEntries;
void AddInterfaceEntries(
@@ -442,8 +440,7 @@ void cmTarget::SetMakefile(cmMakefile* mf)
void CreatePropertyGeneratorExpressions(
std::vectorstd::string const entries,
std::vectorcmListFileBacktrace const backtraces,
-std::vectorcmTargetInternals::TargetPropertyEntry* items,
-bool evaluateForBuildsystem = false)
+std::vectorcmTargetInternals::TargetPropertyEntry* items)
{
std::vectorcmListFileBacktrace::const_iterator btIt = backtraces.begin();
for (std::vectorstd::string::const_iterator it = entries.begin();
@@ -451,7 +448,6 @@ void CreatePropertyGeneratorExpressions(
{
cmGeneratorExpression ge(*btIt);
cmsys::auto_ptrcmCompiledGeneratorExpression cge = ge.Parse(*it);
-cge-SetEvaluateForBuildsystem(evaluateForBuildsystem);
items.push_back(new cmTargetInternals::TargetPropertyEntry(cge));
}
}
@@ -477,11 +473,6 @@ void cmTarget::Compute()
this-Internal-CompileDefinitionsEntries,
this-Internal-CompileDefinitionsBacktraces,
this-Internal-CompileDefinitionsItems);
-
- CreatePropertyGeneratorExpressions(
-this-Internal-SourceEntries,
-this-Internal-SourceBacktraces,
-this-Internal-SourceItems, true);
}
//
@@ -734,11 +725,13 @@ void cmTarget::GetSourceFiles(std::vectorstd::string
files,
// for TARGET_OBJECTS instead for backwards compatibility with OLD
// behavior of CMP0024 and CMP0026 only.
-for(std::vectorstd::string::const_iterator
+typedef cmTargetInternals::TargetPropertyEntry
+TargetPropertyEntry;
+for(std::vectorTargetPropertyEntry*::const_iterator
i =
[Cmake-commits] CMake branch, next, updated. v3.3.0-2100-gfef2009
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via fef2009bd53ee5089d51ff253d603097a9dfebab (commit)
via 29886ce76482a8c857841015b58d1e91a9ee5c8e (commit)
from 67df5c9aeee85453af8e53562b97f21dd4a40c55 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fef2009bd53ee5089d51ff253d603097a9dfebab
commit fef2009bd53ee5089d51ff253d603097a9dfebab
Merge: 67df5c9 29886ce
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Fri Aug 7 15:55:28 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Aug 7 15:55:28 2015 -0400
Merge topic 'use-generator-target' into next
29886ce7 cmTarget: Use a simpler delete algorithm.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=29886ce76482a8c857841015b58d1e91a9ee5c8e
commit 29886ce76482a8c857841015b58d1e91a9ee5c8e
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Aug 4 23:16:12 2015 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Fri Aug 7 21:55:17 2015 +0200
cmTarget: Use a simpler delete algorithm.
This way, the methods can be moved without requiring a local algorithm.
The containers use automatic storage.
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 1277fc2..d3170e4 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -191,14 +191,6 @@ public:
cmLinkImplItem cmTargetInternals::TargetPropertyEntry::NoLinkImplItem;
//
-static void deleteAndClear(
- std::vectorcmTargetInternals::TargetPropertyEntry* entries)
-{
- cmDeleteAll(entries);
- entries.clear();
-}
-
-//
cmTargetInternals::~cmTargetInternals()
{
}
@@ -810,7 +802,7 @@ void cmTarget::GetSourceFiles(std::vectorstd::string
files,
this-LinkImplementationLanguageIsContextDependent = false;
}
- deleteAndClear(linkInterfaceSourcesEntries);
+ cmDeleteAll(linkInterfaceSourcesEntries);
}
//
@@ -2172,7 +2164,7 @@ cmTarget::GetIncludeDirectories(const std::string config,
debugIncludes,
language);
- deleteAndClear(linkInterfaceIncludeDirectoriesEntries);
+ cmDeleteAll(linkInterfaceIncludeDirectoriesEntries);
return includes;
}
@@ -2293,7 +2285,7 @@ void cmTarget::GetCompileOptions(std::vectorstd::string
result,
debugOptions,
language);
- deleteAndClear(linkInterfaceCompileOptionsEntries);
+ cmDeleteAll(linkInterfaceCompileOptionsEntries);
}
//
@@ -2395,7 +2387,7 @@ void
cmTarget::GetCompileDefinitions(std::vectorstd::string list,
debugDefines,
language);
- deleteAndClear(linkInterfaceCompileDefinitionsEntries);
+ cmDeleteAll(linkInterfaceCompileDefinitionsEntries);
}
//
@@ -2462,7 +2454,7 @@ void
cmTarget::GetCompileFeatures(std::vectorstd::string result,
config,
debugFeatures);
- deleteAndClear(linkInterfaceCompileFeaturesEntries);
+ cmDeleteAll(linkInterfaceCompileFeaturesEntries);
}
//
---
Summary of changes:
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
Re: [cmake-developers] Distinguishing MSYS2 (was: FindPythonLibs repaired for MINGW -vs- WIN32 version confusion)
On Fri, Aug 7, 2015 at 1:16 PM, Brad King brad.k...@kitware.com wrote: On 08/07/2015 05:25 AM, Ray Donnelly wrote: CMake needs to be able to identify MSYS2 distinctly from both MINGW and MSYS first. Would a patch making that distinction be acceptable to CMake? Yes, I think that makes sense since the MSYS2 environment is distinct from Windows, MinGW, MSYS, and Cygwin. What should CMAKE_SYSTEM_NAME be for MSYS2? Off the cuff, MSYS2 sounds reasonable, but I think we need to carefully think about this .. We have CMake packages built with MinGW-w64 and also CMake packages built with msys2 GCC (that are used for only a few of our packages). Do they need to be separately identifiable? I also wonder whether the msys2 CMake could be done away with if we used some functions to convert paths between shell-system and make-system .. I'll ask the MSYS2 developers who added the msys2 CMake package about this. Finally, there's the consideration as to whether MSYS2 implies you are using just the minimum amount of the MSYS2 shell or whether you've gone all-in with MSYS2 (so are happy to be using our Python's which are not found in the registry and have a Unix file layout prefixed in /mingw32 or /mingw64). I'd like to hear others' thoughts on this! Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Distinguishing MSYS2 (was: FindPythonLibs repaired for MINGW -vs- WIN32 version confusion)
On 08/07/2015 05:25 AM, Ray Donnelly wrote: CMake needs to be able to identify MSYS2 distinctly from both MINGW and MSYS first. Would a patch making that distinction be acceptable to CMake? Yes, I think that makes sense since the MSYS2 environment is distinct from Windows, MinGW, MSYS, and Cygwin. What should CMAKE_SYSTEM_NAME be for MSYS2? Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, master, updated. v3.3.0-762-g101ba25
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 101ba25e6a2c177f9f3a81f3879a171256806756 (commit) from 3cefadbff07d68c5a6846835ea87cc35eae55a0b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=101ba25e6a2c177f9f3a81f3879a171256806756 commit 101ba25e6a2c177f9f3a81f3879a171256806756 Author: Kitware Robot kwro...@kitware.com AuthorDate: Sat Aug 8 00:01:08 2015 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Sat Aug 8 00:01:08 2015 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 533a881..e982b81 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 3) -set(CMake_VERSION_PATCH 20150807) +set(CMake_VERSION_PATCH 20150808) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.3.0-2103-g9b72aec
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 9b72aec7b3624b6bb8e409e52a29263591856f81 (commit)
via 203b20df98512094cc74061fd1b76e87bd2d3afb (commit)
via b28b07db47b181718643399bd2aedc3e6d1b29c4 (commit)
from fef2009bd53ee5089d51ff253d603097a9dfebab (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9b72aec7b3624b6bb8e409e52a29263591856f81
commit 9b72aec7b3624b6bb8e409e52a29263591856f81
Merge: fef2009 203b20d
Author: James Johnston johnstonj.pub...@codenest.com
AuthorDate: Sat Aug 8 01:27:54 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Aug 8 01:27:54 2015 -0400
Merge topic 'fix-process-error-handling' into next
203b20df cmcmd: Improve error handling when executing a process.
b28b07db cmCTestCoverageHandle: Improve error handling.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=203b20df98512094cc74061fd1b76e87bd2d3afb
commit 203b20df98512094cc74061fd1b76e87bd2d3afb
Author: James Johnston johnstonj.pub...@codenest.com
AuthorDate: Sat Aug 8 01:06:27 2015 -0400
Commit: James Johnston johnstonj.pub...@codenest.com
CommitDate: Sat Aug 8 01:06:27 2015 -0400
cmcmd: Improve error handling when executing a process.
diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx
index 71f47f3..7bee0ea 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -1468,18 +1468,24 @@ bool cmcmd::RunCommand(const char* comment,
std::string output;
int retCode =0;
// use rc command to create .res file
- cmSystemTools::RunSingleCommand(command,
- output, output,
- retCode, 0, cmSystemTools::OUTPUT_NONE);
+ bool res = cmSystemTools::RunSingleCommand(command,
+ output, output,
+ retCode, 0,
+ cmSystemTools::OUTPUT_NONE);
// always print the output of the command, unless
// it is the dumb rc command banner, but if the command
// returned an error code then print the output anyway as
// the banner may be mixed with some other important information.
if(output.find(Resource Compiler Version) == output.npos
- || retCode !=0)
+ || !res || retCode)
{
std::cout output;
}
+ if (!res)
+{
+std::cout comment failed to run. std::endl;
+return false;
+}
// if retCodeOut is requested then always return true
// and set the retCodeOut to retCode
if(retCodeOut)
@@ -1593,7 +1599,10 @@ int
cmcmd::VisualStudioLinkIncremental(std::vectorstd::string args,
mtCommand.push_back(tempManifest);
// now run mt.exe to create the final manifest file
int mtRet =0;
- cmcmd::RunCommand(MT, mtCommand, verbose, mtRet);
+ if(!cmcmd::RunCommand(MT, mtCommand, verbose, mtRet))
+{
+return -1;
+}
// if mt returns 0, then the manifest was not changed and
// we do not need to do another link step
if(mtRet == 0)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b28b07db47b181718643399bd2aedc3e6d1b29c4
commit b28b07db47b181718643399bd2aedc3e6d1b29c4
Author: James Johnston johnstonj.pub...@codenest.com
AuthorDate: Sat Aug 8 00:28:38 2015 -0400
Commit: James Johnston johnstonj.pub...@codenest.com
CommitDate: Sat Aug 8 00:28:38 2015 -0400
cmCTestCoverageHandle: Improve error handling.
diff --git a/Source/CTest/cmCTestCoverageHandler.cxx
b/Source/CTest/cmCTestCoverageHandler.cxx
index 6369e17..65599e0 100644
--- a/Source/CTest/cmCTestCoverageHandler.cxx
+++ b/Source/CTest/cmCTestCoverageHandler.cxx
@@ -1474,7 +1474,12 @@ int cmCTestCoverageHandler::HandleLCovCoverage(
std::endl, this-Quiet);
std::vectorstd::string files;
- this-FindLCovFiles(files);
+ if (!this-FindLCovFiles(files))
+{
+cmCTestLog(this-CTest, ERROR_MESSAGE,
+ Error while finding LCov files.\n);
+return 0;
+}
std::vectorstd::string::iterator it;
if (files.empty())
@@ -1745,18 +1750,28 @@ void
cmCTestCoverageHandler::FindGCovFiles(std::vectorstd::string files)
}
//
-void cmCTestCoverageHandler::FindLCovFiles(std::vectorstd::string files)
+bool cmCTestCoverageHandler::FindLCovFiles(std::vectorstd::string files)
{
cmsys::Glob gl;
gl.RecurseOff(); // No need of recurse if -prof_dir${BUILD_DIR} flag is
// used while compiling.
gl.RecurseThroughSymlinksOff();
std::string prevBinaryDir;
- cmSystemTools::ChangeDirectory(
-
