[Cmake-commits] CMake branch, master, updated. v3.6.0-rc4-303-gb9eb340
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 b9eb3408b4bb750b2cc3f80803a5806d6ee46f13 (commit) from 7523267ca0e1a6c45f3b7eed332bca6e35f32752 (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 - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b9eb3408b4bb750b2cc3f80803a5806d6ee46f13 commit b9eb3408b4bb750b2cc3f80803a5806d6ee46f13 Author: Kitware Robot <kwro...@kitware.com> AuthorDate: Tue Jul 5 00:01:03 2016 -0400 Commit: Kitware Robot <kwro...@kitware.com> CommitDate: Tue Jul 5 00:01:03 2016 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index a9501fa..26e8219 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 6) -set(CMake_VERSION_PATCH 20160704) +set(CMake_VERSION_PATCH 20160705) #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
Re: [cmake-developers] cmake -E capabilities
Tobias Hunger wrote: > On So, 2016-07-03 at 12:33 +0200, Stephen Kelly wrote: >> Tobias Hunger wrote: >> >> > Either we should have multiConfig return a list of configuration names >> > that will be generated or I do not see any need to have the information >> > in the first place. >> >> I think when using qmake with QtCreator, the user can choose the >> configuration at build time by selecting it from the left-side menu. > > I do not understand what you are getting at. > > That widget already works for cmake projects in Qt Creator: It switches > between different build directories with different configurations. Ok. I'm not sure that worked when I tried it years ago :). >> Such a feature would also work with cmake projects if the user chooses to >> use the XCode generator on mac or VS generator on Windows (or if someday >> we have a multi-config Ninja generator or so). > > How is a multi-config ninja generator better than just having to build > directories next to each other, each with one configuration? You might > save a bit of disk space (probably not a lot). Will you save a significant > amount of processing time? > > The one benefit I can think of is switching between configurations will > probably be a lot faster. But that is nothing that is done so often that > it warrants optimizing for IMHO. What I have in mind is not optimization. As you say, if this is not needed at this point for IDE integration, then we can drop the idea. > Either the clients do not care or they need to know which configurations > those are going to be. This can be retrieved by reading the STRINGS property of the CMAKE_BUILD_TYPE cache variable. 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
Re: [CMake] CPack source package install location
Exactly on point, thank you. Domen Vrankar je 04. 07. 2016 ob 08:44 napisal: Hi, I have a very standard CPack configuration for deb package. I have two questions: 1. I generate the deb with: cpack --config CPackConfig.cmake -G "DEB" This is supposedly a binary package but when I install it on the machine I see header files being installed in /usr/include. Is this normal? I'm guessing that CPackConfig.cmake is generated by cmake and not hand written. CMake generates CPackConfig.cmake that can be used to create a package with content listed with 'install()' commands (see: https://cmake.org/cmake/help/v3.5/command/install.html). If those commands contain header files then those files will be part of the package. You could also split packages between bin and dev packages by using COMPONENT attribute in install commands and then generating component packages - one per component. 2. Header files are installed into /usr/include but there is one problem: other projects using the library are including header files with #include as a standard practice. So I actually want them installed in /usr/include/libname instead. After scouring the CPack variables in documentation I didn't really find anything suitable to do this. Is it possible to achieve? This would have to be changed in CMakeLists.txt (install commands) or is possibly already written with prefix variable in mind in which case you have to look into CMakeLists.txt install commands and set the variable that is used there for this purpose. Regards, Domen -- 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] (no subject)
Sir/Ma, I tried generating NEKTAR++ using CMAKE 3.5.2 but I keep receiving an error involving "CheckSymbolExists.c" and "CheckSymbolExists.obj". I could find "CheckSymbolExists.c" in one of the sub-directories of CMAKE directory but I couldn't find "CheckSymbolExists.obj". Please how can I download "CheckSymbolExists.obj"? -- 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] cmake -E capabilities
On So, 2016-07-03 at 12:33 +0200, Stephen Kelly wrote: > Tobias Hunger wrote: > > > Either we should have multiConfig return a list of configuration names > > that will be generated or I do not see any need to have the information in > > the first place. > > I think when using qmake with QtCreator, the user can choose the > configuration at build time by selecting it from the left-side menu. I do not understand what you are getting at. That widget already works for cmake projects in Qt Creator: It switches between different build directories with different configurations. > Such a feature would also work with cmake projects if the user chooses to > use the XCode generator on mac or VS generator on Windows (or if someday we > have a multi-config Ninja generator or so). How is a multi-config ninja generator better than just having to build directories next to each other, each with one configuration? You might save a bit of disk space (probably not a lot). Will you save a significant amount of processing time? The one benefit I can think of is switching between configurations will probably be a lot faster. But that is nothing that is done so often that it warrants optimizing for IMHO. > However, I don't think that is an immediate goal, and that information can > be added later easily if a client does need it. I still think the information "this generator can handle multiple configurations in one build directory" is useless to all clients I can think of. Either the clients do not care or they need to know which configurations those are going to be. Best Regards, Tobias -- Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- 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] Logical block opening error
Hello,
an editor with syntax highlighting and indention support would have
helped here.
On 04/07/16 01:26, Sambeet Panigrahi wrote:
IF(NOT NOT_BUILD_SHARED )
ADD_LIBRARY(orocos-rtt-mqueue-${OROCOS_TARGET}_dynamic SHARED ${CPPS})
TARGET_LINK_LIBRARIES(orocos-rtt-mqueue-${OROCOS_TARGET}_dynamic
orocos-rtt-${OROCOS_TARGET}_dynamic
${MQ_LIBRARIES} ${Boost_SERIALIZATION_LIBRARY}
)
SET_TARGET_PROPERTIES( orocos-rtt-mqueue-${OROCOS_TARGET}_dynamic
PROPERTIES
DEFINE_SYMBOL "RTT_MQ_DLL_EXPORT"
OUTPUT_NAME orocos-rtt-mqueue-${OROCOS_TARGET}
CLEAN_DIRECT_OUTPUT 1
LINK_FLAGS "${MQ_LDFLAGS} ${CMAKE_LD_FLAGS}"
COMPILE_DEFINITIONS "${OROCOS-RTT_DEFINITIONS}"
SOVERSION "${RTT_VERSION_MAJOR}.${RTT_VERSION_MINOR}"
VERSION "${RTT_VERSION}"
The SET_TARGET_PROPERTIES lacks a closing )
ENDIF(NOT NOT_BUILD_SHARED )
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
Re: [CMake] CPack source package install location
Hi, > I have a very standard CPack configuration for deb package. I have two > questions: > > 1. I generate the deb with: cpack --config CPackConfig.cmake -G "DEB" > > This is supposedly a binary package but when I install it on the machine I > see header files being installed in /usr/include. > > Is this normal? I'm guessing that CPackConfig.cmake is generated by cmake and not hand written. CMake generates CPackConfig.cmake that can be used to create a package with content listed with 'install()' commands (see: https://cmake.org/cmake/help/v3.5/command/install.html). If those commands contain header files then those files will be part of the package. You could also split packages between bin and dev packages by using COMPONENT attribute in install commands and then generating component packages - one per component. > 2. Header files are installed into /usr/include but there is one problem: > other projects using the library are including header files with #include > as a standard practice. > > So I actually want them installed in /usr/include/libname instead. After > scouring the CPack variables in documentation I didn't really find anything > suitable to do this. Is it possible to achieve? This would have to be changed in CMakeLists.txt (install commands) or is possibly already written with prefix variable in mind in which case you have to look into CMakeLists.txt install commands and set the variable that is used there for this purpose. Regards, Domen -- 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
