Re: [CMake] linker error while executing with clang and llvm binaries for mingw32
2012/3/27 akshay ratnaparkhi ackk...@gmail.com: Hi all, I am new for clang and llvm and this mailing forum. I am trying build cland on my windows xp 32 bit system using cland binaries for mingw32 version 2.9 and llvm binaries for mingw32 version 2.9. I follow following This mailing list concerns CMake, CPack, CTest and not clang or mingw32 you should ask on appropriate mailing list or forum for your issue. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.7-3354-gaa05637
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 aa056370541417f070a6516d0888a70d24e1a3b7 (commit)
via 3a0c60d3bf8dab326e7dc409632a70ac63e358c1 (commit)
from e26272157599349803ca853abab89bc7c4bc8544 (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=aa056370541417f070a6516d0888a70d24e1a3b7
commit aa056370541417f070a6516d0888a70d24e1a3b7
Merge: e262721 3a0c60d
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Tue Mar 27 15:47:55 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Mar 27 15:47:55 2012 -0400
Merge topic 'CPackPM-fixAmazonLinux' into next
3a0c60d Override topdir from rpm command line seems necessary on Amazon
linux.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3a0c60d3bf8dab326e7dc409632a70ac63e358c1
commit 3a0c60d3bf8dab326e7dc409632a70ac63e358c1
Author: Tom Hughes tomtheengin...@gmail.com
AuthorDate: Tue Mar 27 21:43:35 2012 +0200
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Tue Mar 27 21:43:35 2012 +0200
Override topdir from rpm command line seems necessary on Amazon linux.
This modification should be harmless on other distro.
Signed-off-by: Eric NOULARD eric.noul...@gmail.com
diff --git a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
index 442d7c4..cba746f 100644
--- a/Modules/CPackRPM.cmake
+++ b/Modules/CPackRPM.cmake
@@ -899,6 +899,7 @@ IF(RPMBUILD_EXECUTABLE)
# Now call rpmbuild using the SPECFILE
EXECUTE_PROCESS(
COMMAND ${RPMBUILD_EXECUTABLE} -bb
+--define _topdir ${CPACK_RPM_DIRECTORY}
--buildroot
${CPACK_RPM_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME}${CPACK_RPM_PACKAGE_COMPONENT_PART_PATH}
${CPACK_RPM_BINARY_SPECFILE}
WORKING_DIRECTORY
${CPACK_TOPLEVEL_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME}${CPACK_RPM_PACKAGE_COMPONENT_PART_PATH}
---
Summary of changes:
Modules/CPackRPM.cmake |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
Re: [CMake] make install uses outdated libstdc++.so.6
2012/3/26 Mirko Vukovic mirko.vuko...@gmail.com: Hello, I am building cmake on RHEL6. I need a version higher than the one that comes with RHEL6. After doing bootstrap and make, Did you try to build cmake with cmake instead? I get an error with make install: /home/sm/software/cmake/cmake-2.8.7/Bootstrap.cmk/cmake: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /home/sm/software/cmake/cmake-2.8.7/Bootstrap.cmk/cmake) make: *** [cmake_check_build_system] Error 1 Now, RHEL6 comes with gcc 4.4.6. I have installed 4.6.3, and if I do strings /usr/local/lib64/libstdc++.so.6 | grep GLIBC I do see GLIBCXX_3.4.15. I have set my LD_LIBRARY_PATH to the local lib: echo $LD_LIBRARY_PATH /usr/local/lib64 (prior to starting the build, I set PATH, LIBRARY_PATH, LD_LIBRARY_PATH to the new gcc and its libraries, all in /usr/local. So, what else can I do so that cmake uses that library instead of the one in /usr/lib64? I prefer not to uninstall the system gcc. Why didn't you build CMake with system gcc then? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] make install uses outdated libstdc++.so.6
2012/3/26 Mirko Vukovic mirko.vuko...@gmail.com: On Mon, Mar 26, 2012 at 2:30 PM, Eric Noulard eric.noul...@gmail.com wrote: 2012/3/26 Mirko Vukovic mirko.vuko...@gmail.com: Hello, I am building cmake on RHEL6. I need a version higher than the one that comes with RHEL6. After doing bootstrap and make, Did you try to build cmake with cmake instead? I get an error with make install: /home/sm/software/cmake/cmake-2.8.7/Bootstrap.cmk/cmake: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /home/sm/software/cmake/cmake-2.8.7/Bootstrap.cmk/cmake) make: *** [cmake_check_build_system] Error 1 Now, RHEL6 comes with gcc 4.4.6. I have installed 4.6.3, and if I do strings /usr/local/lib64/libstdc++.so.6 | grep GLIBC I do see GLIBCXX_3.4.15. I have set my LD_LIBRARY_PATH to the local lib: echo $LD_LIBRARY_PATH /usr/local/lib64 (prior to starting the build, I set PATH, LIBRARY_PATH, LD_LIBRARY_PATH to the new gcc and its libraries, all in /usr/local. So, what else can I do so that cmake uses that library instead of the one in /usr/lib64? I prefer not to uninstall the system gcc. Why didn't you build CMake with system gcc then? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org When I use the system gcc, I get the GLIBCXX_3.4.15' not found error. Same if I use cmake You mean the system-installed CMake? If this is the case the system installation is broken. CMake shouldn't have been installed without its dependencies. Did you try without modifying LD_LIBRARY_PATH ? That is when you use the system installed cmake to build newer CMake on a pristine user account you ge the GLIBCXX_3.4.15' not found error ? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] make install uses outdated libstdc++.so.6
2012/3/26 Mirko Vukovic mirko.vuko...@gmail.com: I can certainly try again (remove /usr/local from PATH variables). But as I am not familiar with cmake, can you please spell out for me how to use it? I am much more used to make configure. I tried with cmake -i, but I not sure if I did everything correctly. Usually you do something like: 1) tar zxvf your-software.tar.gz - this creates a your-software/ directory 2) mkdir build 3) cd build 4) cmake ../your-software 5) make 6) make install at step 4) you may configure the install prefix with cmake -DCMAKE_INSTALL_PREFIX=/where/you/want at the same step 4) you may launch cmake-gui ../your-software and chose option; install prefix etc... from the GUI instead of the command line. at step 6) you may try to build a package instead of installing: for RPM: cpack -G RPM for DEB: cpack -G DEB for TGZ: cpack -G TGZ then you'll be able to install the built package. That said if you just want to use an up to date CMake you should first try to use pre-compiled binaries taken from Kitware: http://www.cmake.org/cmake/resources/software.html CMake binaries are as static as then can so it's usually enough to unarchive the tarball somewhere and directly use the cmake (or cpack or ctest) binary from there. Is anybody here using RHEL6 with recent CMake version who can help? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] WIN32 vs CMAKE_HOST_WIN32
2012/3/26 Eric Noulard eric.noul...@gmail.com: 2012/3/26 Robert Dailey rcdailey.li...@gmail.com: Ever since I started using CMake, I always assumed that the WIN32 variable represented what system CMake is currently running on. Looking more carefully at the documentation, however, it seems this describes what system CMake is generating for. Could someone explain this a bit better? What would be an example of when WIN32 would be true but I'm not actually on Windows? When you cross-compile Windows binaries on a Linux host. see: http://www.cmake.org/Wiki/CMake_Cross_Compiling http://www.cmake.org/Wiki/CmakeMingw If you want to give it a try on a sample project you can try this one: https://github.com/TheErk/CMake-tutorial/tree/master/examples It may be cross-compiled on a Linux host with mingw cross-compiler installed. try: $ mkdir build-win32 $ cd build-win32 $ cmake -DCMAKE_TOOLCHAIN_FILE=../totally-free/Toolchain-cross-mingw32-linux.cmake ../totally-free/ -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.7-3352-ge262721
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 e26272157599349803ca853abab89bc7c4bc8544 (commit) via 8fe0da598172265594e43ca5f12e8698c7d13f25 (commit) from cee132f0cea0c8ff7e6cb0c0ec3b3c3987c4bc5c (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=e26272157599349803ca853abab89bc7c4bc8544 commit e26272157599349803ca853abab89bc7c4bc8544 Merge: cee132f 8fe0da5 Author: Eric Noulard eric.noul...@gmail.com AuthorDate: Tue Mar 27 01:58:59 2012 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Mar 27 01:58:59 2012 -0400 Merge topic 'CPackNSIS-smallDocTypoFix' into next 8fe0da5 Fix some doc typo and add an undocumented var. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8fe0da598172265594e43ca5f12e8698c7d13f25 commit 8fe0da598172265594e43ca5f12e8698c7d13f25 Author: Eric NOULARD eric.noul...@gmail.com AuthorDate: Tue Mar 27 07:55:02 2012 +0200 Commit: Eric NOULARD eric.noul...@gmail.com CommitDate: Tue Mar 27 07:55:02 2012 +0200 Fix some doc typo and add an undocumented var. diff --git a/Modules/CPackNSIS.cmake b/Modules/CPackNSIS.cmake index 7d9f29b..90f6536 100644 --- a/Modules/CPackNSIS.cmake +++ b/Modules/CPackNSIS.cmake @@ -15,16 +15,20 @@ ##end # ##variable -# CPACK_NSIS_MUI_ICON - The icon file (.ico) for the generated +# CPACK_NSIS_MUI_ICON - The icon file (dotico) for the generated # install program. ##end # ##variable -# CPACK_NSIS_MUI_UNIICON - The icon file (.ico) for the generated +# CPACK_NSIS_MUI_UNIICON - The icon file (dotico) for the generated # uninstall program. ##end # ##variable +# CPACK_NSIS_INSTALLER_MUI_ICON_CODE - undocumented. +##end +# +##variable # CPACK_NSIS_EXTRA_INSTALL_COMMANDS - Extra NSIS commands that will # be added to the install Section. ##end @@ -40,7 +44,8 @@ ##end # ##variable -# CPACK_NSIS_MODIFY_PATH - If this is set to ON, then an extra page +# CPACK_NSIS_MODIFY_PATH - Modify PATH toggle. +# If this is set to ON, then an extra page # will appear in the installer that will allow the user to choose # whether the program directory should be added to the system PATH # variable. --- Summary of changes: Modules/CPackNSIS.cmake | 11 --- 1 files changed, 8 insertions(+), 3 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
Re: [CMake] [CPACK] symlink problem and man cpack issue
2012/3/25 kassim orra kassimo...@gmail.com: Hi David, First, thanks for the help. I didn't use any argument, I posted all my cpack script. I really don't know why, there is somewhere I could change the /lib path inside the cpack script ? May be the problem is not with CPack but with your install rule for this lib. Did you use ABSOLUTE install path DESTINATION? Could you copy/paste us the install command you use for libQtDeclarative target? I posted all my cpack code, I'm starting to write it and when I finally work's, Im gonna change it for relative path's. Your CPack code is strange: set(CPACK_INSTALL_DIRECTORY MedSquare) this one is usually set by CPack generic generator itself. set(CPACK_SOURCE_INSTALLED_DIRECTORIES /root/medsquare/;source) this one is usually set by CPack.cmake inclusion set(CPACK_DEFAULT_LOCATION ./) This one is not used anywhere by CPack, where did you picked the name? set(CPACK_INCLUDE_TOPLEVEL_DIRECTORY 1) This one is automatically set to 1 by Archive Generators (including TZ) set(CPACK_INSTALL_CMAKE_PROJECTS /root/medsquare/source) this one is usually set by CPack.cmake inclusion set(CPACK_INTALL_PREFIX /root/medsquare/installer) you miss the 'S' for INSTALL. set(CPACK_PACKAGE_FILE_NAME medsquare) set(CPACK_PACKAGE_INSTALL_DIRECTORY /root/medsquare) set(CPACK_PACKAGING_INSTALL_PREFIX /root/medsquare) include(CPack) Here is all my log: [root@root source]# cpack -E -E is not a CPack option and you are running CPack as 'root' which may be very bad idea if you used ABSOLUTE destination. Could you try: 1) to only use relative install path 2) get rid of unecessary CPACK_xxx var definition 3) run CPack as a normal user If you get errors then try: cpack --verbose --debug and send us the resulting output + the portion of CMakeLists.txt where the install command for the failing target(s) are. By the way which version of CMake/CPack are you using. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Different targets for different configurations
2012/3/23 Mike Krus m...@mve.com:
Hi
I would like run a script with different options for debug and release
builds. I can do this easily for Makefiles but am struggling to get it to
work for Visual Studio.
I basically:
- add a custom command the output of which depends on the configuration
- add a custom target for that command
- add that target as a dependency of my other targets (I want the
script to run first)
Why can't you use the PRE_BUILD options of add_custom_command
with TARGET target signature?
It is not possible because this script should be run before any target?
Here's the CMake code below...
My problem is that for Visual Studio ${CMAKE_BUILD_TYPE} is not set (normal)
and CMake doesn't know about $(CONFIGURATION) since it's a build time thing
(again, normal).
So as it stands, the scripts always runs at every build because it's not
picking up the correct output file.
Did have a look at generator expressions they are meant to be used
in your precise case,
i.e. they are evaluated at build time and not at CMake time.
Valid expressions are:
$CONFIGURATION = configuration name
$TARGET_FILE:tgt= main file (.exe, .so.1.2, .a)
$TARGET_LINKER_FILE:tgt = file used to link (.a, .lib, .so)
$TARGET_SONAME_FILE:tgt = file with soname (.so.3)
more doc in:
cmake --help-command add_custom_command
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.7-3322-g31accb3
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 31accb307a7a6c76184468859062b6376b67323f (commit)
via 87d5f1f1a69a1bed94e65a5dd1fdfe2f05eaa772 (commit)
from 407d2b73fa3de19590943d025cec93ad7d352b6c (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=31accb307a7a6c76184468859062b6376b67323f
commit 31accb307a7a6c76184468859062b6376b67323f
Merge: 407d2b7 87d5f1f
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Tue Mar 20 17:44:00 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Mar 20 17:44:00 2012 -0400
Merge topic 'CPackNSIS-fixMODIFY_PATH' into next
87d5f1f CPackNSIS merge patch from bug #13055.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=87d5f1f1a69a1bed94e65a5dd1fdfe2f05eaa772
commit 87d5f1f1a69a1bed94e65a5dd1fdfe2f05eaa772
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Tue Mar 20 22:41:10 2012 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Tue Mar 20 22:41:10 2012 +0100
CPackNSIS merge patch from bug #13055.
diff --git a/Modules/CPack.cmake b/Modules/CPack.cmake
index 571770e..e1ceed9 100644
--- a/Modules/CPack.cmake
+++ b/Modules/CPack.cmake
@@ -342,7 +342,7 @@ cpack_set_if_not_set(CPACK_RESOURCE_FILE_WELCOME
cpack_set_if_not_set(CPACK_MODULE_PATH ${CMAKE_MODULE_PATH})
IF(CPACK_NSIS_MODIFY_PATH)
- SET(CPACK_NSIS_MODIFY_PATH ON)
+ SET(CPACK_NSIS_MODIFY_PATH ON)
ENDIF(CPACK_NSIS_MODIFY_PATH)
SET(__cpack_system_name ${CMAKE_SYSTEM_NAME})
---
Summary of changes:
Modules/CPack.cmake |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
Re: [cmake-developers] New OBJECT library feature
2012/3/19 Brad King brad.k...@kitware.com: Hi Folks, I've just pushed a new 'object-library' topic and merged to 'next' for testing. David Cole and I have been working on it for a couple of weeks. The following documentation added to the add_library command explains: -- The signature add_library(name OBJECT src...) creates a special object library target. An object library compiles source files but does not archive or link their object files into a library. Instead other targets created by add_library or add_executable may reference the objects using an expression of the form $TARGET_OBJECTS:objlib as a source, where objlib is the object library name. For example: add_library(... $TARGET_OBJECTS:objlib ...) add_executable(... $TARGET_OBJECTS:objlib ...) will include objlib's object files in a library and an executable along with those compiled from their own sources. Object libraries may contain only sources (and headers) that compile to object files. They may contain custom commands generating such sources, but not PRE_BUILD, PRE_LINK, or POST_BUILD commands. Object libraries cannot be imported, exported, installed, or linked. That's a great feature. This would be useful for cross-compiled target. Is there a feature that could guarantee the order of appearance of those objects / object library on the link line generated for add_executable ? By the way why wouldn't you authorize target_link_libraries(exetarget objlibname) ? -- Many of the documented restrictions are temporary until meaningful behavior can be defined and implemented for them in a future version. It is easiest to simply disallow all but the basic use case for now. Ok this answers my previous question. This feature plays a role similar to autotools convenience libraries but works with all toolchains and under VS and Xcode. We've updated all primary generators to support object libraries including the Ninja generator. Until this goes into master watch out for conflicts when making changes to the other generators. I'll test the feature. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] New OBJECT library feature
2012/3/19 Brad King brad.k...@kitware.com:
On 3/19/2012 1:56 PM, Eric Noulard wrote:
That's a great feature.
Thanks.
Is there a feature that could guarantee the order of appearance of
those objects / object library on the link line generated for
add_executable ?
Currently no order is guaranteed other than that all the object files
from directly compiled sources, external objects, and object libraries
will all come before any _linked_ libraries. I'm not sure whether it
is even possible to guarantee an order in all our target build systems.
Can you enumerate use cases when the order of objects matters? Unlike
static libraries *all* objects will be included. If there are duplicate
symbols it is an error. If there are not duplicate symbols then how
does order matter?
I have to dig into an exotic build system I converted from makefile to CMake
in order to fully understand why. As far as I remember it was
mandatory but I cannot
remember the reason.
This use cases I do compile object using add_library and a single
file using a custom command because the final link step
(done with a custom command as well) requires this last object object file
to be given first on the command line.
The custom command likn step looks like:
COMMAND ${CMAKE_LINKER} --oformat binary -Ttext ${BM_IMAGE_ADDRESS}
-melf_i386 -e _start -o ${BM_APPNAME}.bin ${BM_STARTUPOBJ}
--start-group $TARGET_LINKER_FILE:system $TARGET_LINKER_FILE:xc
$TARGET_LINKER_FILE:${BM_APPNAME} --end-group ${BM_LDSCRIPT}
${BM_STARTUPOBJ} is the specific object file compiled on its own using
custom command.
Now that I think about it, before that I was forced to create a custom
command in order
to compile the file ('with the same option as the one compiled by add_library)
but now I will be able to build an OBJECT library containing a single file
and refer to it using $TARGET_OBJECTS:objlib which is perfectly fine for
ensuring the ordering I may need for the link step.
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] cmake generates broken project file when path includes whitespace (in this case at least)
2012/3/19 Ajay Panyala a...@csc.lsu.edu:
Please notice the linebreak after Foo, this causes the linker to fail,
saying it can not find C:/Projects/Foo.
I guess this is a cmake bug, but I need to find a workaround for this one. I
am using cmake 2.8.2 on Windows 7.
I have the exact same whitespace issue with a custom command. I am using
cmake 2.8.4 with Cygwin
on Windows XP. I have not tried to fix it yet since it was not too urgent
for me.
My guess is (I maybe wrong) that it may have something to do with the way
Windows paths ( C:/Projects/Foo)
are specified. I think CMake has something to handle this, but I do not know
what that would be.
Did you try playing around with:
file(TO_CMAKE_PATH path result)
file(TO_NATIVE_PATH path result)
cmake --help-command file
Thanks
Ajay
On Mon, Mar 19, 2012 at 7:51 AM, Paul Baumer paul.baum...@googlemail.com
wrote:
Hello,
I have the following in my Cmakelists.txt file:
set_target_properties( MyApp PROPERTIES STATIC_LIBRARY_FLAGS
${SOME_LIB_FILENAME})
If the SOME_LIB_FILENAME path includes white space such as
c:/Projects/Foo 4/Src/somelib.lib
the generated visual studio 2008 file includes the following fragment:
Tool Name=VCLibrarianTool
AdditionalOptions='C:/Projects/Foo
4/Src/somelib.lib'
Please notice the linebreak after Foo, this causes the linker to fail,
saying it can not find C:/Projects/Foo.
I guess this is a cmake bug, but I need to find a workaround for this one.
I am using cmake 2.8.2 on Windows 7.
Any ideas?
Paul
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake generates broken project file when path includes whitespace (in this case at least)
2012/3/19 Ajay Panyala a...@csc.lsu.edu: Did you try playing around with: file(TO_CMAKE_PATH path result) file(TO_NATIVE_PATH path result) I did try file(TO_NATIVE_PATH path result) at the time, but it was not useful in my case. The result is still a unix style path (maybe because I am using Cygwin) Did you use cygwin CMake or win32 CMake? I think using win32 CMake with cygwin does not play well, one should use cygwin CMake. I'm no expert in this area but the ML archive should contain answers to this kind of problem. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] specifying complex test behavior
2012/3/18 Ajay Panyala a...@csc.lsu.edu: Hello, Is it possible to specify complex behavior for determining if a test was successful. For example, if we have add_test(Differ executable args) I want to specify that the test named Differ is successful if the output obtained by running the specified executable matches a certain file, i.e the diff of the output and a specified file is empty. Then you should probably write a test driver script that does just that and do add_test(NAME Differ COMMAND driverScript referenceFile $TARGET_FILE:executable args) so that the driverScript will call executable with args and compare its output to referenceFile. In your case this script may probably written as a CMake script using execute_process and cmake -E compare_files etc... I am not sure how set_property should be specified in such cases. Clearly using set_property by specifying a regular expression is not sufficient. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.7-3199-ga36e092
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 a36e092d605afc283eb12a22abb7605577540b6e (commit)
via 4576f40ee0f1306189179919efb35c915fe49cf1 (commit)
via 1bfe81e01e1fb8b4e790082d15ca7cf7d7b7f6ae (commit)
via 6330f67a2511067b820dcbaa34f7d890f7c92c96 (commit)
via b4f949a3dd05c90814fb69372e1268718b1a586c (commit)
via acc3862d0add923d0ec91356b39aa0e030a5d211 (commit)
via 50fe2c6460d42fdd6edafbe2b64087b687f3bd16 (commit)
from f5243578b93208ede6243223e2ae800196976a66 (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=a36e092d605afc283eb12a22abb7605577540b6e
commit a36e092d605afc283eb12a22abb7605577540b6e
Merge: f524357 4576f40
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Sun Mar 18 12:55:55 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sun Mar 18 12:55:55 2012 -0400
Merge topic 'CPack-fixSTGZpermission-bug13046' into next
4576f40 CPack STGZ put execute permission on all packages files (component
case)
1bfe81e KWSys Nightly Date Stamp
6330f67 KWSys Nightly Date Stamp
b4f949a KWSys Nightly Date Stamp
acc3862 KWSys Nightly Date Stamp
50fe2c6 KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4576f40ee0f1306189179919efb35c915fe49cf1
commit 4576f40ee0f1306189179919efb35c915fe49cf1
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Sun Mar 18 17:52:56 2012 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Sun Mar 18 17:52:56 2012 +0100
CPack STGZ put execute permission on all packages files (component case)
diff --git a/Source/CPack/cmCPackSTGZGenerator.cxx
b/Source/CPack/cmCPackSTGZGenerator.cxx
index 184c557..966a231 100644
--- a/Source/CPack/cmCPackSTGZGenerator.cxx
+++ b/Source/CPack/cmCPackSTGZGenerator.cxx
@@ -54,21 +54,32 @@ int cmCPackSTGZGenerator::InitializeInternal()
//--
int cmCPackSTGZGenerator::PackageFiles()
{
+ bool retval = true;
if ( !this-Superclass::PackageFiles() )
{
return 0;
}
- return cmSystemTools::SetPermissions(packageFileNames[0].c_str(),
+
+ /* TGZ generator (our Superclass) may
+ * have generated several packages (component packaging)
+ * so we must iterate over generated packages.
+ */
+ for (std::vectorstd::string::iterator it=packageFileNames.begin();
+ it != packageFileNames.end(); ++it)
+ {
+retval = cmSystemTools::SetPermissions((*it).c_str(),
#if defined( _MSC_VER ) || defined( __MINGW32__ )
-S_IREAD | S_IWRITE | S_IEXEC
+ S_IREAD | S_IWRITE | S_IEXEC
#elif defined( __BORLANDC__ )
-S_IRUSR | S_IWUSR | S_IXUSR
+ S_IRUSR | S_IWUSR | S_IXUSR
#else
-S_IRUSR | S_IWUSR | S_IXUSR |
-S_IRGRP | S_IWGRP | S_IXGRP |
-S_IROTH | S_IWOTH | S_IXOTH
+ S_IRUSR | S_IWUSR | S_IXUSR |
+ S_IRGRP | S_IWGRP | S_IXGRP |
+ S_IROTH | S_IWOTH | S_IXOTH
#endif
- );
+);
+ }
+ return retval;
}
//--
---
Summary of changes:
Source/CPack/cmCPackSTGZGenerator.cxx | 25 ++---
Source/kwsys/kwsysDateStamp.cmake |2 +-
2 files changed, 19 insertions(+), 8 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.7-3201-g4f0ba8e
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 4f0ba8e30a59d1e1bb2ca463e46a59e77aa202a3 (commit)
via 805c1b21d63ccc6b02b1a43f438a3b409dd12056 (commit)
from a36e092d605afc283eb12a22abb7605577540b6e (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=4f0ba8e30a59d1e1bb2ca463e46a59e77aa202a3
commit 4f0ba8e30a59d1e1bb2ca463e46a59e77aa202a3
Merge: a36e092 805c1b2
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Sun Mar 18 16:15:50 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sun Mar 18 16:15:50 2012 -0400
Merge topic 'CPack-fixCPACK_MONOLITHIC_INSTALL-handling' into next
805c1b2 Handle CPACK_MONOLITHIC_INSTALL in some rare use cases.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=805c1b21d63ccc6b02b1a43f438a3b409dd12056
commit 805c1b21d63ccc6b02b1a43f438a3b409dd12056
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Sun Mar 18 20:21:35 2012 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Sun Mar 18 20:21:35 2012 +0100
Handle CPACK_MONOLITHIC_INSTALL in some rare use cases.
For example, when CPACK_GEN_COMPONENT_INSTALL and
CPACK_MONOLITHIC_INSTALL are both set. Previously, this
combination of variable settings produced an error without
any explanation. Now, in this case CPACK_MONOLITHIC_INSTALL wins
without trouble.
This is useful for when e.g. CPACK_ARCHIVE_COMPONENT_INSTALL is
globally on and one wants MONOLITHIC install for STGZ (but not
other generators). The same behavior may be obtained by re-setting
CPACK_ARCHIVE_COMPONENT_INSTALL to 0 but in any case the
'both set' case should have been handled without error.
diff --git a/Source/CPack/cmCPackArchiveGenerator.cxx
b/Source/CPack/cmCPackArchiveGenerator.cxx
index 0ff9050..6e7b8d7 100644
--- a/Source/CPack/cmCPackArchiveGenerator.cxx
+++ b/Source/CPack/cmCPackArchiveGenerator.cxx
@@ -247,7 +247,7 @@ int cmCPackArchiveGenerator::PackageFiles()
cmCPackLogger(cmCPackLog::LOG_DEBUG, Toplevel:
toplevel std::endl);
- if (SupportsComponentInstallation()) {
+ if (WantsComponentInstallation()) {
// CASE 1 : COMPONENT ALL-IN-ONE package
// If ALL COMPONENTS in ONE package has been requested
// then the package file is unique and should be open here.
diff --git a/Source/CPack/cmCPackDebGenerator.cxx
b/Source/CPack/cmCPackDebGenerator.cxx
index b707e96..178a18d 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -236,7 +236,7 @@ int cmCPackDebGenerator::PackageFiles()
int retval = -1;
/* Are we in the component packaging case */
- if (SupportsComponentInstallation()) {
+ if (WantsComponentInstallation()) {
// CASE 1 : COMPONENT ALL-IN-ONE package
// If ALL GROUPS or ALL COMPONENTS in ONE package has been requested
// then the package file is unique and should be open here.
diff --git a/Source/CPack/cmCPackGenerator.cxx
b/Source/CPack/cmCPackGenerator.cxx
index f7d8a4d..0f832b3 100644
--- a/Source/CPack/cmCPackGenerator.cxx
+++ b/Source/CPack/cmCPackGenerator.cxx
@@ -1437,6 +1437,12 @@ bool cmCPackGenerator::SupportsComponentInstallation()
const
}
//--
+bool cmCPackGenerator::WantsComponentInstallation() const
+{
+ return (!IsOn(CPACK_MONOLITHIC_INSTALL) SupportsComponentInstallation());
+}
+
+//--
cmCPackInstallationType*
cmCPackGenerator::GetInstallationType(const char *projectName,
const char *name)
diff --git a/Source/CPack/cmCPackGenerator.h b/Source/CPack/cmCPackGenerator.h
index 52def9d..55afb44 100644
--- a/Source/CPack/cmCPackGenerator.h
+++ b/Source/CPack/cmCPackGenerator.h
@@ -189,7 +189,21 @@ protected:
virtual int InstallProjectViaInstallCMakeProjects(
bool setDestDir, const char* tempInstallDirectory);
+ /**
+ * Does the CPack generator support component installation?.
+ * Some Generators requires the user to set
+ * CPACK_GENNAME_COMPONENT_INSTALL in order to make this
+ * method return true.
+ * @return true if supported, false otherwise
+ */
virtual bool SupportsComponentInstallation() const;
+ /**
+ * Does the currently running generator want a component installation.
+ * The generator may support component installation but he may
+ * be requiring monolithic install using CPACK_MONOLITHIC_INSTALL.
+ * @return true if component installation is supported and wanted.
+ */
+ virtual
[CMake] Fwd: CPack : RPM : architecture in the name
Retransmiyt without attached file which is blocked because it's too big
-- Forwarded message --
From: Eric Noulard eric.noul...@gmail.com
Date: 2012/3/16
Subject: Re: [CMake] CPack : RPM : architecture in the name
To: a.neundorf-w...@gmx.net
Cc : cmake@cmake.org, Barth barthelemy.von.hal...@cern.ch
2012/3/15, Alexander Neundorf a.neundorf-w...@gmx.net:
On Thursday 15 March 2012, Barth wrote:
Dear all,
I found a mail in the archives discussing the naming of RPMs (30 dec.
2009). Indeed, a standard RPM name contains the architecture and not
Linux.
I am wondering if it is possible to do it now ? I use CMake 2.8.6. I still
get an error when setting CPACK_RPM_PACKAGE_ARCHITECTURE but is there
another way to achieve this ?
CPACK_RPM_PACKAGE_ARCHITECTURE is not used for the RPM package name
but for putting the appropriate value in the spec file.
The appropriate value for this is usually correctly guessed by
rpmbuild (used by CPackRPM)
but this var may be set to noarch if you know that the RPM is not depending
on any arch. Setting this var to any other value may produce unexpected result.
I append the architecture string simply to CPACK_SYSTEM_NAME. Not sure
whether
there is a better way.
The main var to choose the package file name is CPACK_PACKAGE_FILE_NAME :
the default value for this variable is:
${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION}-${CPACK_SYSTEM_NAME}
the default value of CPACK_SYSTEM_NAME is CPACK_SYSTEM_NAME
but you can set it to whatever value you want like Alex does.
All CPack variables should be documented in the next CPack release.
I join to this mail the current doc from git master.
CPack package naming is currently evolving to be more flexible in the future
see: http://public.kitware.com/Bug/view.php?id=12997
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[cmake-developers] Fwd: Preferred variable retrieval within Cpack generator.
Forgot to cc the list. -- Forwarded message -- From: Eric Noulard eric.noul...@gmail.com Date: 2012/3/10 Subject: Re: [cmake-developers] Preferred variable retrieval within Cpack generator. To: Schwartz, Philip Marc (RIS-BCT) philip.schwa...@lexisnexis.com 2012/3/10 Schwartz, Philip Marc (RIS-BCT) philip.schwa...@lexisnexis.com: What is the preferred method of variable retrieval and/pr parameter passing in the cpack generator structure. I have seen a mixture of passing values into functions and also using GetOption to obtain the wanted value. Usually using GetOption means that we want to give user some control so that this CPACK_xxx value may be set in CMakeLists.txt, CPack project config file or CPack command line arg. GetOption is not used to pass value from cmCPackGenerator class to its daughter classes. I am currently looking at adding new functionality to allow for better control of package naming when working with generation of packages. This will include using a variable template for creation of the naming schema to be used. Currently I am allowing the package specific generator to build a map of the parameters for naming and pass the map into the function GetComponentPackageFileName. This will allow for the specific generator to control the values, but I am not sure if it is more efficient to use GetOption directly in the function. If the feature may be shared by all generators then it ought to be defined in the cmCPackGenerator base class. (let's call it generic CPack generator) If some data are processed by the generic CPack generator and then used by some daughter classes then you can add a protected field member. This is the case for cmCPackGenerator::Components, or even cmCPackGenerator::files. What are the thoughts of the other developers working on CMake and CPack? I'm not sure I did catch all the implication of I am allowing the package specific generator to build a map of the parameters for naming and pass the map into the function GetComponentPackageFileName may you can provide us with a first patch? Attached to http://public.kitware.com/Bug/view.php?id=12997. Then we (at least I) may see more clearly what you mean? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Preferred variable retrieval within Cpack generator.
2012/3/12 Schwartz, Philip Marc (RIS-BCT) philip.schwa...@lexisnexis.com: Usually using GetOption means that we want to give user some control so that this CPACK_xxx value may be set in CMakeLists.txt, CPack project config file or CPack command line arg. GetOption is not used to pass value from cmCPackGenerator class to its daughter classes. It is looking like this will be the preferred option as I want to be able to define this for all classes that inherit from cmCPackGenerator allowing the variables to be set for all generators that might use them. The important question is would this option be settable by user in the CMake script? If yes then you soud use GetOption. If the feature may be shared by all generators then it ought to be defined in the cmCPackGenerator base class. (let's call it generic CPack generator) If some data are processed by the generic CPack generator and then used by some daughter classes then you can add a protected field member. This is the case for cmCPackGenerator::Components, or even cmCPackGenerator::files. I don't think I am creating anything that will require this. The focus is around changing how the name is handled, not adding further variables in the generator to the mix. Ok. I'm not sure I did catch all the implication of I am allowing the package specific generator to build a map of the parameters for naming and pass the map into the function GetComponentPackageFileName Be for deciding on using GetOption to allow the variables to be set by a cmake file directly in the cmCPackGenerator class, I was doing this work in the subclass for the type specific generator and creating a std::mapstd::string, std::string that contained a value map. This was a bad way of doing it and reason for the first email and after reading the email has been changed. I go on vacation on Friday and I am out for a week. I am hoping to have the first version of the patch out in the bug before then. OK then. I'll go answer on the tracker as well. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Automatically add a revision number to the CPack installer name
2012/3/9 Glenn Ramsey g...@componic.co.nz: Thanks Eric, this lead me to a solution that works for me, where the revision number is updated at build time. For future reference here is what I did: [...] This is a nice and relatively easy solution. Thank you for sharing the final solution. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[cmake-developers] CPack more flexible package name feature
Hi all, People interested in discussing a new flexible way to create package file name with CPack may follow/throw ideas on the concerned feature request on the tracker: http://www.cmake.org/Bug/view.php?id=12997 Philip has volunteered to work on this, I'll be reviewing/helping as much as I can. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] CPack more flexible package name feature
Hi all, People interested in discussing a new flexible way to create package file name with CPack may follow/throw ideas on the concerned feature request on the tracker: http://www.cmake.org/Bug/view.php?id=12997 Philip has volunteered to work on this, I'll be reviewing/helping as much as I can. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Reviewing work on CPack documentation
Hi All, I have been working on enhancing CPack documentation. http://public.kitware.com/Bug/view.php?id=10067 Some fair amount of work has now reached 'master'. The two main features are: cpack --help-variable-* cpack --help-command-* command line options. As you will see: $ cpack --help-variable-list | wc -l 120 there is already a bunch of CPACK_xxx variables whose documentation is now easily visible to the user. I need reviewers for all this. You may review the whole doc with: cpack --help-html cpack-doc.html and read the cpack-doc.html with your favorite browser. Most of the work was to retrieve the informations from C++ source and/or CPack*.cmake scripts files. Some builtin CPack variables have their documentation written in C++ code but... if you have a look at git master CPack*.cmake files you'll see that variables defined/used in the file(s) may now be documented in the script file itself using a primitive structured markup. If you notice: - any error in the current documentation - any missing CPACK_xxx variable documentation please comment on the tracker: http://public.kitware.com/Bug/view.php?id=10067 and/or attach a patch. with your help CPack 2.8.8 may have a nice documentation. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automatically add a revision number to the CPack installer name
2012/3/8 Glenn Ramsey g...@componic.co.nz:
Yes, you can use add_custom_command(...) to run a script to get the revision
number, but I don't think you can use that to alter CPACK_PACKAGE_FILE_NAME,
which has been set at cmake time.
This true but how wouldn't a revision update trigger a CMake re-run?
Whatever the reason if you want to change/alter/set a CPACK_xxx value
at CPack time ,
independently of CMakre re-run, you can use a CPACK_PROJECT_CONFIG_FILE:
CPACK_PROJECT_CONFIG_FILE
CPack-time project CPack configuration file.
This file included at cpack time, once per generator after CPack has
set CPACK_GENERATOR to the actual generator being used. It allows
per-generator setting of CPACK_* variables at cpack time.
In your CMakeLists.txt you have to:
set(CPACK_PROJECT_CONFIG_FILE ${CMAKE_CURRENT_SOURCE_DIR}/MyCPackConf.cmake)
then write the logic you want in MyCPackConf.cmake.
see:
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29
This CPACK_PROJECT_CONFIG_FILE is a CMake script file loaded by CPack
(which includes
a CMake script interpreter) you cannot use non scriptable CMake command in there
(and no add_xxx to make it simple) but you can perfectly use
execute_process in order to run
some SCM commands.
You should be able to override CPACK_PACKAGE_FILE_NAME dynamically in there.
You have access to all CPACK_xxx variable value.
However, in this script file you do not have access to CMAKE_xxx
variables you can usually access in CMakeLists.txt
(no CMAKE_PROJECT_NAME, nor orther variables YOU defined in the CMakeLists.txt
besides CPACK_xxx ones)
If you need some of these values you'll have to create a
MyCPackConf.cmake.in
which will be configured **at CMake-time**
into
MyCPackConf.cmake
CMake itself is using this with the CMakeCPackOptions.cmake.in file
at the root of CMake
sources.
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] CPack: GetPrerequisites: cross-compiling from Linux to Windows
2012/3/6 Dominik Schmidt do...@tomahawk-player.org: Hey Eric, thanks for the quick reply! You are welcome. This is the reason my code in the patch is not in the WIN32 block above and I couldn't guess the gp_tool correctly. In order to be sure that nothing else is breaking you can try to [manually] add the missing definition in the CPackConfig.cmake file. This file is loaded by CPack at CPack-time so that any definitions in there will be seen during CPack run. Went fine. An alternative would be to do it in a CPack Project Config file: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29 Might make sense, indeed. That way you could explicitly say if you want to cross-package or not. It is even necessary for more than just testing because the CPackConfig.cmake file may be overwritten by CPack next time you change your CMakeLists.txt. CPackConfig.cmake is generated by the include(CPack) in your CMakeLists.txt. Ultimately it may be useful to configure_file your CPackProjectConfig.cmake.[in] and put some generated logic in it depending on any CMake variable. The patch is probably not ready to be upstreamed but I'm happy to fix issues or follow a nicer approach if you point me to it. Before going on may be you could explain us what kind of cross-packaging your are targeting: NSIS, Archive generator, etc... NSIS is the one I'm aiming for :-) Ok. Setting WIN32 and/or CMAKE_CROSSCOMPILING may be done in CPack list interpreter but it remains to be seen whether it would be enough in order to achieve what you want. I think so, it already works when gp_tool is manually set to objdump! If you manage to do that kind of cross-packaging it could be worth a page on the Wiki. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] [cmake-developers] CPack: GetPrerequisites: cross-compiling from Linux to Windows
2012/3/6 Dominik Schmidt do...@tomahawk-player.org:
On Tue, Mar 6, 2012 at 4:05 PM, Eric Noulard eric.noul...@gmail.com wrote:
So the next step would be to configure e.g. CPACK_CROSSPACKAGING and
CPACK_WIN32 in my project config file and try to make GetPrerequisites
work
with them?
That's not what I was thinking about.
May be you could just add something like:
if (CPACK_CROSSPACKAGING)
set(WIN32 @WIN32@)
set(CMAKE_CROSSCOMPILING @CMAKE_CROSSCOMPILING@)
endif(CPACK_CROSSPACKAGING)
So that if CPACK_CROSSPACKAGING is set in your CMakeLists.txt
it will trigger the definition of WIN32 and CMAKE_CROSSCOMPILING in your
configured CPackProjectConfig file.
Neither works. I took a closer look at CPackConfig.cmake in my build
dir and saw
SET(CPACK_SYSTEM_NAME win32) is defined.
(which I didnt define, btw
http://www.vtk.org/Wiki/CMake:CPackConfiguration say it defaults to
CMAKE_SYSTEM_NAME which is Windows in my case tho)
When I tried to print it in GetPrerequisites, it was empty.
So variables defined there aren't available when needed here it seems.
message(FATAL_ERROR CPACK_SYSTEM_NAME is: ${CPACK_SYSTEM_NAME})
CMake Error at
/home/domme/dev/installs/share/cmake-2.8/Modules/GetPrerequisites.cmake:626
(message):
CPACK_SYSTEM_NAME is:
Call Stack (most recent call first):
/home/domme/dev/installs/share/cmake-2.8/Modules/BundleUtilities.cmake:432
(get_prerequisites)
/home/domme/dev/installs/share/cmake-2.8/Modules/BundleUtilities.cmake:612
(get_bundle_keys)
/home/domme/dev/sources/my_client/cmake/modules/DeployQt4.cmake:116
(fixup_bundle)
/home/domme/dev/sources/my_client/win/cmake_install.cmake:43
(FIXUP_QT4_BUNDLE)
This is the interesting part.
This installation part is launched by CPack before packaging.
GetPrerequisites may simply works after that (as far as I understood
your previous e-mail).
Err well. with the rest of my patch applied :-)
So I misunderstood, one of your previous answer
In order to be sure that nothing else is breaking you can try to
[manually] add the missing definition in the CPackConfig.cmake file.
This file is loaded by CPack at CPack-time so that any definitions in
there
will be seen during CPack run.
Went fine.
I have not the rime now to dive into CPack source code in order to check
which context comes with the installation step launched by CPack.
Does the [cross-]DeployQt4 works if you simply do
make install
?
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CPack: GetPrerequisites: cross-compiling from Linux to Windows
2012/3/6 David Cole david.c...@kitware.com: Just an FYI from the original author of GetPrerequisites here: cross-packaging was not even considered as we developed it. If it works at all, it's by happy accident. I always envisioned packaging as occurring on a host == target platform. Thus my initial remark: Cross-compiling is one thing, cross packaging is another one (which may be difficult or impossible in the general case). If we want to support cross-packaging for real in CMake/CPack, then we need some dashboard submissions that build such a beast, and submit nightly... so that we can monitor for errors when we do make changes to the source tree. Thanks, and best of luck here, I just wanted to help Dominik to go as far as I can but I won't certainly have time to create test cases nor dashboard for that. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Impossible to link SDLmain and LibXml2
2012/3/6 julien@redaction-developpez.com:
Hi,
I have a problem with cmake not to compile but to link my .exe.
I use SDL, OpenGL, FMOD, LibXml2 and a personal library. But when I try to
compile my program LibXml2 and SDLmain are not include into the command line
to link my .exe.
Enclosed my CMakeList.txt and CMakeCache.txt and here the line for the
linker into build.make:
Output/shootspace.exe: C:/MinGW/lib/libSDL.dll.a
Output/shootspace.exe: C:/MinGW/lib/libfmodex.a
Output/shootspace.exe: CMakeFiles/shootspace.dir/build.make
Output/shootspace.exe: CMakeFiles/shootspace.dir/objects1.rsp
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR)
--red --bold Linking CXX executable Output/shootspace.exe
/c/Program Files (x86)/CMake 2.8/bin/cmake.exe -E remove
-f CMakeFiles/shootspace.dir/objects.a
/C/MinGW/bin/ar.exe cr CMakeFiles/shootspace.dir/objects.a
@CMakeFiles/shootspace.dir/objects1.rsp
/C/MinGW/bin/g++.exe -Wl,--whole-archive
CMakeFiles/shootspace.dir/objects.a -Wl,--no-whole-archive -o
Output/shootspace.exe -Wl,--out-implib,Output/libshootspace.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
-Lsource/lib/gtl/lib/mingw -lmingw32 /C/MinGW/lib/libSDL.dll.a -lpthread
-lglu32 -lopengl32 /C/MinGW/lib/libfmodex.a -lgtl -lkernel32 -luser32
-lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
As you can see, LibXml2 library and SDLmain library are found in
CMakeCache.txt but not include in build.make because –lxml2 and –lSDLmain
are missing.
Why ? I do something wrong in my CMakeList.txt ?
yes.
since you did
Find_Package(LibXml2 REQUIRED)
you'll have to:
target_link_libraries(
shootspace
${LIBXML2_LIBRARIES}
and not XML2_LIBRARY
in you CMakeCache.txt you'll see that SDLmain is not found.
//Path to a library.
SDLMAIN_LIBRARY:FILEPATH=SDLMAIN_LIBRARY-NOTFOUND
for SDL I suggest you read the documentation of the module:
cmake --help-module FindSDL
there are some explanation about SDLmain or not.
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Making GUI applications by default
2012/3/5 Stephen Kelly steve...@gmail.com:
Clinton Stimpson wrote:
I happened to read a little bit about CPack recently
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overview
The recommendation is to not use MACOSX_BUNDLE when using cpack,
I don't see that as a general recommendation for GUI applications on Mac
OS X.
Yes, my statement was a little over-general.
Its only true if you use the Bundle generator, which does the
equivalent of the MACOSX_BUNDLE conversion at cpack time (not install
time). I wouldn't base a general statement on a generator where one has a
broken make install just to make a cpack generator work.
If you use any other cpack generator with a GUI application, you do use
MACOSX_BUNDLE.
I imagined that users could set the value of CMAKE_MACOSX_BUNDLE to True by
default, but False if (${CPACK_GENERATOR} STREQUAL MACOSX_BUNDLE).
Is that realistic? I don't really know much about cpack, bundles or Mac OSX
in general.
Not really, you may decide run MacOSXBundle CPack generator outside
CMakeLists.txt
i.e. at CPack time and not at CMake time:
cpack -G OSXX11
I don't know much about this CPack generator but from my point of view
the generator
itself should check whether if the executable have been built properly
and warn/error out
with appropriate message if not.
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introducing: message(DEBUG)
2012/3/5 Rolf Eike Beer e...@sf-mail.de:
On 3/3/2012 5:25 AM, Rolf Eike Beer wrote:
+ else if (*i == DEBUG)
+ {
...
+ status = true;
Rather than being a conditional version of STATUS I think full stack
information is useful for debugging. Add to the cmake::MessageType
enumeration a DEBUG value and teach cmake::IssueMessage to handle it.
The output should look like an error or warning but with CMake Debug
as the header instead of CMake Error or CMake Warning.
I would like to have that switchable in some way. E.g. for Boost_DEBUG I
don't have stack traces at the moment, but the contents are the
information I need. Stacktraces are useful, but not always.
Then may be you can have a bunch of control var for that:
CMAKE_DEBUG_MESSAGES_STACKTRACE ON/OFF
CMAKE_DEBUG_MESSAGES_FILEPREFIX ON/OFF
CMAKE_DEBUG_MESSAGES_USERPREFIX stringvalue
then you display some prefix depending on ON/OFF value and if
USERPREFIX is set.
Once the decision to display the message has a cmListFileBacktrace
instance available for the context then you can have fancier rules
for deciding what messages to display.
I don't think I fully understand what you are trying to say here.
May be something like my previous proposal?
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introducing: message(DEBUG)
2012/3/5 Brad King brad.k...@kitware.com: On 3/5/2012 10:22 AM, Rolf Eike Beer wrote: Rather than being a conditional version of STATUS I think full stack information is useful for debugging. Add to the cmake::MessageType enumeration a DEBUG value and teach cmake::IssueMessage to handle it. The output should look like an error or warning but with CMake Debug as the header instead of CMake Error or CMake Warning. I would like to have that switchable in some way. E.g. for Boost_DEBUG I don't have stack traces at the moment, but the contents are the information I need. Stacktraces are useful, but not always. I'm not opposed to a switch but extra verbosity rarely hurts debug output IMO. Even a switch at the call site may be the wrong place because it is up to the viewer of the message whether the full context is important. Perhaps the switch can be based on something similar to the context filters (see below). Once the decision to display the message has a cmListFileBacktrace instance available for the context then you can have fancier rules for deciding what messages to display. I don't think I fully understand what you are trying to say here. Elsewhere in this thread discussion proposed filters on messages based on their context. Filters based on the full backtrace should be possible and would give a lot of control. You mean something like a regex? So that if the stacktrace and/or prefix (and/or the whole message) matches the regex it is displayed ? It may cost a lot at runtime? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Build faild on Darwin? Don't know why?
2012/2/20 David Cole david.c...@kitware.com: The lesson here is: - ignore dashboard failures for the BundleGenerator test on Mac machines unless it is happening consistently build after build after build - also ignore any test failures that contain references to a failed run of hdiutil which fails sporadically -- only consider it a real problem with the CMake code if it happens consistently If anybody can actually figure out a good way for us to work-around or really fix these issues on the Mac, so we never see sporadic failures as build/test problems on the CMake dashboard, I'll gladly buy you dinner!! David, Did you see this bug report: http://public.kitware.com/Bug/view.php?id=13017 this may explain the sporadic failure on MacOS? Now I see that there is already a retry loop, [...] // since we get random dashboard failures with this one // try running it more than once int numTries = 4; bool res = false; while(numTries 0) [...] but if anti-virus is the reason for hdiutil failure may be there is a way to tell the anti-virus to stay away from mounted image? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] MSVC_VERSION for VC11?
2012/3/5 Robert Dailey rcdai...@gmail.com: The docs aren't updated to reflect this so I just wanted to make sure. Patch for documentation may be accepted as well :-] I didn't have time to run through the source code (you Linux people and your fancy 'git grep' commands :P ) You Windows people and your need to check compiler version before trying to compile a portable piece of code :P !! -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] recognizing shell in use
2012/3/6 Ajay Panyala a...@csc.lsu.edu:
Hello,
Is there anyway that cmake could figure out the shell (bash,csh,..)
that is being use when cmake is invoked on the command line ?
May be you can check $ENV{SHELL} ?
Why would you like to do that?
Usually when using CMake one tries to avoid shell/command interpreter
dependency??
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[cmake-developers] No next-master merge this week?
Hi guys, There was no next-master merge this week? Is there any issue? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Two pull requests
2012/3/1 Brad King brad.k...@kitware.com: On 3/1/2012 10:47 AM, Eric Noulard wrote: Last time I tried to enable KWStyle hooks following this: http://www.cmake.org/Wiki/Git/Hooks#Setup That page is generic for many of Kitware's projects and is not specific to CMake. The same hooks are also used for ITK. For a while the kwstyle and uncrustify hooks were added and used by ITK. Later they were moved over to ITK proper and are now invoked through the generic hooks' chaining feature. They no longer exist in the generic hooks outright. I removed the discussion of them from the wiki page. I'm not a big fan of automatic code formatting and layout tools. There are almost always exceptions and special cases. I'd rather cover that during code review. Yes I agree with that but may be using them as pre-commit warning on changed files may be interesting. Nevertheless checking for no more than 79 column style certainly does not require such tool. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] New platform which did not deserve upstream: how to avoid warning?
Hi, I'm working on a research platform for which I wrote a toolchain file. Let's say this platform is called Blah how do I avoid the System is unknown to cmake, create: Platform/Blah to use this system, please send your config file to cm...@www.cmake.org so it can be added to cmake Besides that all is OK (because the C compiler is GCC based). So I wonder how I can do to avoid the warning. There is no benefit to put this platform in upstream CMake so I can write a dummy Blah.cmake platform? Putting the file in a local (to my project) Platform/ directory seems ok if I modify the CMAKE_MODULE_PATH before project() command but is this the correct way of work? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] New platform which did not deserve upstream: how to avoid warning?
2012/3/1 Alexander Neundorf a.neundorf-w...@gmx.net: On Thursday 01 March 2012, Eric Noulard wrote: Hi, I'm working on a research platform for which I wrote a toolchain file. Let's say this platform is called Blah how do I avoid the System is unknown to cmake, create: Platform/Blah to use this system, please send your config file to cm...@www.cmake.org so it can be added to cmake Besides that all is OK (because the C compiler is GCC based). So I wonder how I can do to avoid the warning. There is no benefit to put this platform in upstream CMake so I can write a dummy Blah.cmake platform? Putting the file in a local (to my project) Platform/ directory seems ok if I modify the CMAKE_MODULE_PATH before project() command but is this the correct way of work? I'd say so. What kind of platform is it ? Intel SCC: http://techresearch.intel.com/ProjectDetails.aspx?Id=1 Something small embedded ? Not so small and not embbedable in a foreseen future. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake snippets
2012/2/29 Andrea Crotti andrea.crott...@gmail.com: If anyone is interested, I'm collecting cmake-mode yasnippet snippets for Emacs: https://github.com/AndreaCrotti/yasnippet-snippets/tree/master/cmake-mode Is anyone else using it and has some nice snippets to share? I'm not using it (yasnippet) but this seems interesting. Can you complete then expand the snippets? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] find_package(Subversion) fails when run by an automated Jenkins build
2012/2/29 Massaro Alessio alessio.mass...@mediobanca.co.uk:
Hi there,
Awkward behaviour:
My CMakeLists.txt do a find_package(Subversion)
Now, I have a Jenkins build server running under domain user XYZ
The Jenkins CMake plugin tells me it’s trying to do the following:
“c:\Program Files\CMake 2.8\bin\cmake.exe” -G Visual Studio 9
2008
-DCMAKE_BUILD_TYPE=Release
D:\path\to\where\jenkins\puts\mysource
And fails with
-- Could NOT find Subversion (missing: Subversion_SVN_EXECUTABLE)
But if I logon to that very same server with that very same domain user,
check-out the code from svn elsewhere on the server disk and run the above
command (adjusting for the different path to the source), then the
find_package will work just fine.
Does anyone have a clue on what the problem might be?
What might be causing the difference in behaviour?
May be the path is set to a different value in the Jenkins context.
You could try to make your CMakeLists.txt display the content of
the PATH variable with something like;
MESSAGE(PATH=$ENV{PATH})
that way you'll see if something is different
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Nightly Binary not building on windows
2012/2/28 Bill Hoffman bill.hoff...@kitware.com: The nightly binary for CMake is not building because of a test failure: http://open.cdash.org/testDetails.php?test=136868750build=2046004 CMake Error at CMakeLists.txt:52 (message): Subversion_VERSION_SVN has unexpected content Call Stack (most recent call first): CMakeLists.txt:74 (check_version_string) The following tests FAILED: 185 - CMakeOnly.AllFindModules (Failed) This commit cffce2ffb366cd5c598f56e8f0789124a6d1b7a9 added at least this check_version_string(SUBVERSION Subversion_VERSION_SVN) Subversion_VERSION_SVN seems empty (from the error message)? The module is named FindSubversion.cmake make be check_version_string(SUBVERSION Subversion_VERSION_SVN) should simply be: check_version_string(Subversion Subversion_VERSION_SVN) upper/lower case trouble? Mixed-case leads to trouble since (from FindSubversion.cmake) we have: # Subversion_FOUND - true if the command line client was found # SUBVERSION_FOUND - same as Subversion_FOUND, set for compatiblity reasons -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] smarter shortcuts with NSIS
2012/2/28 Andrea Crotti andrea.crott...@gmail.com:
Alright moving the include after did the trick, I get my code in the final
nsi file, as below:
set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS
PageEx directory
DirVar PythonDir
PageExEnd
CreateShortCut \\\$DESKTOP${PROJECT_NAME}.lnk\\\
\\\$INSTDIRbuilt_eggrun.exe\\\ \$PythonDirpythonw.exe\ \\
\\ \.$INSTDIR\ \Run project ${PROJECT_NAME}\
)
The problem is that it fails for this reason:
Error: command PageEx not valid in Section
which makes sense, but is there a way to avoid that PageEx to end up in a
section at all?
Is that the only way to inject NSIS code?
Yes currently that's the case if you use the CMake-provided NSIS.template.in
but...
At worst is there a way to just create my own .nsi file and use it directly?
I need to create a page which simply asks for a directory to the user, and
then use that to create a shortcut..
Any idea (also other solutions might be fine).
1) Copy the current NSIS.template.in in your project.
and update it the way you like.
2) update CMAKE_MODULE_PATH
list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/packaging)
in order to make your NSIS.template.in in the CMAKE_MODULE_PATH
(you can even use CPACK_MODULE_PATH)
3) run-rerun packaging an dmake sure that cpack is using your projevtc specific
NSIS.template.in
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] smarter shortcuts with NSIS
2012/2/27 John Drescher dresche...@gmail.com: Ah yes you're right, last time I checked I didn't see them.. Anyway my extra_commands don't appear anywhere in the nsi file, is that normal? No i'ts not. Did you set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS ...) BEFORE include(CPack) ? The process is relatively simple. 0) Your CPACK_xxx vars are set and processed by the inclusion of CPack.cmake (the include(CPack) of your CMakeLists.txt) 1) CPack NSIS generator configures the NSIS.template.in file by replacing occurences of CPACK_NSIS_... specific vars in there. 2) makensis is launched using the generated project.nsi CPack private installation of your project in a _CPackPackage subdir is done somewhere between 0) and 1). You need awkward extra escape in CPACK_NSIS_xxx because of the double CMake script processing 0) and 1). Is it clearer? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cpack Nsis not installing libraries
2012/2/27 Mauricio Klein mauricio.klein@gmail.com:
Hello everybody!
I'm creating a NSIS package using CPack to install my software.
The code is compilled using Visual Studio 9, and the compilation + packing
is working well.
But, once i install the software using the generated NSIS package, the
program doesn't start because NSIS did't installed the required libraries.
The strange is that in my CMakeLists.txt, i tell that my binary requires
these libraries.
The libraries are:
* OpenSSL
* Pthreads
(both found using find macros)
The piece of configuration that defines these relashionship is showed
bellow:
-
find_package(Pthreads REQUIRED)
find_package(OpenSSL REQUIRED)
include_directories(${OPENSSL_INCLUDE_DIR})
include_directories(${PTHREADS_INCLUDE_DIR})
install(TARGETS MyBin DESTINATION MyBin1-0/bin)
install(TARGETS ${PTHREADS} DESTINATION MyBin1-0/bin)
install(TARGETS ${OPENSSL} DESTINATION MyBin1-0/bin)
${PTHREADS} and ${OPENSSL} seems wrong
usually those are:
${PTHREADS_LIBRARIES}
${OPENSSL_LIBRARIES}
moreover you cannot use install(TARGETS ) for those
because they are not TARGET unless you somehow define
them as IMPORTED library.
Usually third party libs (those which are not built in your project)
are not installed because they may be found on the host where
your software is installed already.
If you are interested in creating autonomous bundle
have a look at the BundleUtilities module.
The MyBin binary is installed well, but the libraries of Pthreads and
OpenSSL not!
Any hint??
Thanks in advance for your attention, and any help is very welcome!
May be you can tell us which version of CMake you are using
and which system you are targeting (Windows, Linux, MacOS Xetc...)
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.7-2875-g4f279c6
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 4f279c603a4a1dca275d393286506f3054feadd2 (commit) via b3851f504dc8404384aa14b62ca4765f3a4dc955 (commit) from 6cda64102debcd49b3d24aaf69a91a254d381f83 (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=4f279c603a4a1dca275d393286506f3054feadd2 commit 4f279c603a4a1dca275d393286506f3054feadd2 Merge: 6cda641 b3851f5 Author: Eric Noulard eric.noul...@gmail.com AuthorDate: Sat Feb 25 13:21:33 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Sat Feb 25 13:21:33 2012 -0500 Merge topic 'CPack-fixCPackDMG-docLayout' into next b3851f5 Fix CPack Drag and Drop generator documentation layout. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b3851f504dc8404384aa14b62ca4765f3a4dc955 commit b3851f504dc8404384aa14b62ca4765f3a4dc955 Author: Eric NOULARD eric.noul...@gmail.com AuthorDate: Sat Feb 25 19:18:52 2012 +0100 Commit: Eric NOULARD eric.noul...@gmail.com CommitDate: Sat Feb 25 19:18:52 2012 +0100 Fix CPack Drag and Drop generator documentation layout. diff --git a/Modules/CPackDMG.cmake b/Modules/CPackDMG.cmake index caa8dc8..e866bab 100644 --- a/Modules/CPackDMG.cmake +++ b/Modules/CPackDMG.cmake @@ -7,53 +7,53 @@ ##end # ##variable -# CPACK_DMG_VOLUME_NAME - The volume name of the generated disk -# image. Defaults to CPACK_PACKAGE_FILE_NAME. +# CPACK_DMG_VOLUME_NAME - The volume name of the generated disk +# image. Defaults to CPACK_PACKAGE_FILE_NAME. ##end # ##variable -# CPACK_DMG_FORMAT - The disk image format. Common values are UDRO -# (UDIF read-only), UDZO (UDIF zlib-compressed) or UDBZ (UDIF -# bzip2-compressed). Refer to hdiutil(1) for more information on -# other available formats. +# CPACK_DMG_FORMAT - The disk image format. Common values are UDRO +# (UDIF read-only), UDZO (UDIF zlib-compressed) or UDBZ (UDIF +# bzip2-compressed). Refer to hdiutil(1) for more information on +# other available formats. ##end # ##variable -# CPACK_DMG_DS_STORE - Path to a custom .DS_Store file which e.g. -# can be used to specify the Finder window position/geometry and -# layout (such as hidden toolbars, placement of the icons etc.). -# This file has to be generated by the Finder (either manually or -# through OSA-script) using a normal folder from which the .DS_Store -# file can then be extracted. +# CPACK_DMG_DS_STORE - Path to a custom DS_Store file. This .DS_Store +# file e.g. can be used to specify the Finder window +# position/geometry and layout (such as hidden toolbars, placement of the +# icons etc.). This file has to be generated by the Finder (either manually or +# through OSA-script) using a normal folder from which the .DS_Store +# file can then be extracted. ##end # ##variable -# CPACK_DMG_BACKGROUND_IMAGE - Path to an image file which is to be -# used as the background for the Finder Window when the disk image -# is opened. By default no background image is set. The background -# image is applied after applying the custom .DS_Store file. +# CPACK_DMG_BACKGROUND_IMAGE - Path to a background image file. This +# file will be used as the background for the Finder Window when the disk +# image is opened. By default no background image is set. The background +# image is applied after applying the custom .DS_Store file. ##end # ##variable -# CPACK_COMMAND_HDIUTIL - Path to the hdiutil(1) command used to -# operate on disk image files on Mac OS X. This variable can be used -# to override the automatically detected command (or specify its -# location if the auto-detection fails to find it.) +# CPACK_COMMAND_HDIUTIL - Path to the hdiutil(1) command used to +# operate on disk image files on Mac OS X. This variable can be used +# to override the automatically detected command (or specify its +# location if the auto-detection fails to find it.) ##end # ##variable -# CPACK_COMMAND_SETFILE - Path to the SetFile(1) command used to set -# extended attributes on files and directories on Mac OS X. This -# variable can be used to override the automatically detected -# command (or specify its location if the auto-detection fails to -# find it.) +# CPACK_COMMAND_SETFILE - Path to the SetFile(1) command used to set +# extended attributes on files and directories on Mac OS X. This +# variable can be used to override the automatically detected +# command (or specify its location if the auto-detection fails to +# find it.) ##end # ##variable -# CPACK_COMMAND_REZ - Path to the Rez(1) command used to compile -# resources
[Cmake-commits] CMake branch, next, updated. v2.8.7-2882-g733a122
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 733a1221b1915df101eeb1a6f6d8dc0694f0b753 (commit) via 98d158376eacacd12a765675272268be27609192 (commit) from da1e14700e6a9768a64730a64cd3d9e43d2e94f1 (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=733a1221b1915df101eeb1a6f6d8dc0694f0b753 commit 733a1221b1915df101eeb1a6f6d8dc0694f0b753 Merge: da1e147 98d1583 Author: Eric Noulard eric.noul...@gmail.com AuthorDate: Sat Feb 25 17:29:12 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Sat Feb 25 17:29:12 2012 -0500 Merge topic 'CPack-cygwinGeneratorDoc' into next 98d1583 Provide template for CPack Cygwin generator specific variables. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=98d158376eacacd12a765675272268be27609192 commit 98d158376eacacd12a765675272268be27609192 Author: Eric NOULARD eric.noul...@gmail.com AuthorDate: Sat Feb 25 23:26:41 2012 +0100 Commit: Eric NOULARD eric.noul...@gmail.com CommitDate: Sat Feb 25 23:26:41 2012 +0100 Provide template for CPack Cygwin generator specific variables. diff --git a/Modules/CPackCygwin.cmake b/Modules/CPackCygwin.cmake new file mode 100644 index 000..7ed7f67 --- /dev/null +++ b/Modules/CPackCygwin.cmake @@ -0,0 +1,33 @@ +##section Variables specific to CPack Cygwin generator +##end +##module +# - Cygwin CPack generator (Cygwin). +# The following variable is specific to installers build on +# and/or for Cygwin: +##end +# +##variable +# CPACK_CYGWIN_PATCH_NUMBER - The Cygwin patch number. +# FIXME: This documentation is incomplete. +##end +##variable +# CPACK_CYGWIN_PATCH_FILE - The Cygwin patch file. +# FIXME: This documentation is incomplete. +##end +##variable +# CPACK_CYGWIN_BUILD_SCRIPT - The Cygwin build script. +# FIXME: This documentation is incomplete. +##end + +#= +# Copyright 2006-2012 Kitware, Inc. +# +# Distributed under the OSI-approved BSD License (the License); +# see accompanying file Copyright.txt for details. +# +# This software is distributed WITHOUT ANY WARRANTY; without even the +# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +# See the License for more information. +#= +# (To distribute this file outside of CMake, substitute the full +# License text for the above reference.) --- Summary of changes: Modules/CPackCygwin.cmake | 33 + 1 files changed, 33 insertions(+), 0 deletions(-) create mode 100644 Modules/CPackCygwin.cmake hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
Re: [CMake] simplest possible NSIS package
2012/2/23 Andrea Crotti andrea.crott...@gmail.com: On 02/23/2012 04:48 PM, John Drescher wrote: Just to make you laugh I found the source of the problem. Apparently if you try to run an installer from a directory which is on a shared directory (with the virtualbox sharing) it just won't run :D Copying it somewhere else works perfectly, quite amazing issue. Thanks for reporting back. That was very puzzling to me since my NSIS builds have worked for a long time. John My pleasure, I would have never thought of something so stupid actually :/ But is it true that NSIS is quite a dead project? The last version is from 2009 as far as I can see.. Are there plans to support other package managers for windows? WiX has been proposed (including a patch) http://public.kitware.com/Bug/view.php?id=11575 I think the bug has been backloged because of lack of manpower to work on it and the lack of test in the proposed patch. May be you can try to resume this work? I may help for understanding CPack internals, but I may not be of great help for testing since I'm not using Windows very often. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack issues
2012/2/21 Andrea Crotti andrea.crott...@gmail.com:
I'm trying to finally create an installer for my project, with CPack and
NSIS.
The project is really really simple, I just need to copy over a directory
somewhere.
And I did something like:
get_filename_component(userprofile $ENV{USERPROFILE} REALPATH)
install(
DIRECTORY ${EGG_BUILD_DIRECTORY}
DESTINATION ${userprofile}/${PROJECT_NAME}
)
Is userprofile an absolute path? (sorry I'm not working on Windows very often)
if this is the case this will not work.
DO NEVER install with absolute install path on Windows:
1) the installed pieces won't be put in the installer
2) the files/dirs/whatever MAY (if you have enough privilege) be
installed on the machine
on which you are trying to build the package!!
I think we should forcibly forbid absolute install path on
windows...but that's another story.
The first line is because CPack was exploding using the USERPROFILE, because
it was getting non quoted backslash.
So is it the way to handle windows path variables?
Usually you go from to native path representation using
file(TO_NATIVE_PATH path result)
file(TO_CMAKE_PATH path result)
see:
cmake --help-command file
The packing, however, doesn't work and I get something like (from the NSIS
generated log file):
!insertmacro: end of MUI_RESERVEFILE_INSTALLOPTIONS
Section: -Core installation
SetOutPath: $INSTDIR
File: Returning to: H:/long_path/_CPack_Packages/win32/NSIS/Minimum
Drag-0.1.1-win32
File: H:/long_path/_CPack_Packages/win32/NSIS/Minimum Drag-0.1.1-win32\*.*
- no files found.
Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] |
/oname=outfile one_file_only)
Error in script
H:/git_projs/Minimum_Drag/airbus.application.minimum_drag/_CPack_Packages/win32/NSIS/project.nsi
on line 640 -- aborting creation process
These are the variables that I defined
set(CPACK_NSIS_INSTALLED_ICON_NAME ${PROJECT_NAME})
this one looks wrong:
CPACK_NSIS_INSTALLED_ICON_NAME
A path to the executable that contains the installer icon.
set(CPACK_PACKAGE_ICON Company)
same for this one:
CPACK_PACKAGE_ICON
A branding image that will be displayed inside the installer.
the documentation currently found in CPack.cmake
or http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#NSIS
(and soon from cpack --help-variable)
could be improved but both the previous variables should refer to files.
set(CPACK_NSIS_PACKAGE_NAME ${PROJECT_NAME})
set(CPACK_RESOURCE_FILE_LICENSE ${CMAKE_CURRENT_SOURCE_DIR}/COPYRIGHT.txt)
set(CPACK_PACKAGE_VERSION_MAJOR 0)
set(CPACK_PACKAGE_VERSION_MINOR 1)
set(CPACK_CREATE_DESKTOP_LINKS ${PROJECT_NAME})
I think this one refers to a executable installed by the project.
(but there is not documentation [yet] for CPACK_CREATE_DESKTOP_LINKS :-]
set(CPACK_PACKAGE_INSTALL_DIRECTORY ${PROJECT_NAME}) # add the version
numbers
set(CPACK_PACKAGE_DESCRIPTION Package ${PROJECT_NAME})
there is no such variable.
There is:
CPACK_PACKAGE_DESCRIPTION_SUMMARY
Short description of the project (only a few words).
CPACK_PACKAGE_DESCRIPTION_FILE
A text file used to describe the project.
Used, for example, the introduction screen of a CPack-generated
Windows installer to describe the project.
is there anything missing?
Any idea what that could be?
A lot of things...
first did have a look at the error:
H:/long_path/_CPack_Packages/win32/NSIS/Minimum Drag-0.1.1-win32\*.*
is it true?
then open the project.nsi file and try to fix things by hand.
then go back to your
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building and executing tests when building updated libraries
2012/2/21 Robert Dailey rcdai...@gmail.com: I apologize if I sounded like your suggestion wasn't meaningful or useful. I would much rather prefer to do it how you suggest (running all tests), but this leaves me with some concerns: If the developer is running all unit tests on their local machine, what is the purpose of then running them on the server? If the server does it again in response to the commit, wouldn't that be considered redundant? The server may catch interaction between modifications that make some tests fails when features are merged but not when tested alone. This would depend on you VCS as well. With a centralized VCS like (CVS, Subversion etc...) this would be odd if this happened. With DVCS with some non-conflicting merge workflow (think of the 'next' CMake branch) then server may reveal errors that developers cannot catch. Moreover in portable project like those I know using CMake the server may in fact be serversssZZ which may have very different setup than the one the developper is running on. (I do break MacOS X or Windows whatever version compile when I develop on my Linux box). The server breakage may reveal that the project is lacking some test which would have ease the unitary catch. Do you have 100% coverage with your tests? Let's assume that the time it takes to run all tests takes about 1 hour. Not only does this slow down productivity, but it also makes practices like continuous integration impossible to perform, since a lot of people can commit work in that 1 hour window, in which case you'd have to run the tests again after updating. It's a recursive issue. If the whole test is lengthly may be the tested project is beginning to be too big to be tested as a whole. Imagine the test suite a for a whole operating system... Then the project may be subdivided into smaller independent projects, that can be tested independently safely in a shorter time. Then you create some integration project (and put someone responsible for it) which essentially consist integration tests which aggregate use the smaller projects. This integration test suite may be run extensively before each combo release and/or periodically like once a week. How would you address the concerns I have noted above? My 2 cents just above. Plus ask some people with a huge number of tests like OTB: http://dash.orfeo-toolbox.org/index.php?project=OTBdate=2012-02-21 Totals 5 Builds ... 10464 tests :-] I bet they don't run the whole test suite each time they commit. My tests are labeled in such a way that they are easy to spot and work with in the solution explorer. For example: projectA projectA_test_iostreams projectA_test_fileio projectA_test_graphics projectA_test_input Then you have a neat way to run ctest efficiently on those using ctest -L (or ctest -R if your are speaking of test names and not label). By the way would someone explain me (or point me to appropriate place) on test label usage, are those derived from labels that could be put on target or may I put label on test as well (I know I can try, but sometimes I like to read as well). In my example above, target named projectA has 4 unit tests. Each test can be responsible for 1 or more translation units (there is no strict rule here). If I change the way files are loaded by library projectA, then I would run the fileio test. However, in this case it's really easy for the developer to spot the tests for that project and run all of them if they are unsure. Would you also mind commenting on this structure? It seems to ease the concern you mentioned about people not always being able to know which tests to run. Thanks for your feedback. Keep in mind that not only am I covering general testing principles, but I also want to know how to best apply them to the tools (CMake, CTest). This is where your expertise becomes valuable to me :) -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] more targets to run in parallel
2012/2/20 Andrea Crotti andrea.crott...@gmail.com:
On 02/17/2012 03:35 PM, Andrea Crotti wrote:
..
I can make the question much simpler, is it possible to generate targets
dynamically with CMake?
As far as I know you can generate targets at CMake-time but not at build-time.
So from my point of view this computed target but not really dynamic target.
I was trying the following (nonsense), a simple loop over a list
that first generates a custom command and another loop
that generates a target for every command.
set(target_list uno due tre)
foreach (t ${target_list})
set(t_cmd ${t}.out)
add_custom_command(OUTPUT ${t_cmd}
COMMAND ls ${t} ${t_cmd}
)
endforeach ()
foreach (t ${target_list})
message(analyzing target ${t})
set(t_cmd ${t}.out)
add_custom_target(${t}
COMMAND ${t_cmd}
)
This cannot work because ${t_cmd} is NOT a command
this is the OUTPUT of a custom command (which is't named).
I would suppose that this should work but it doesn't:
make[3]: uno.out: Command not found
Precisely.
Any idea why?
if you want your target to trigger the command you may
add the OUTPUT of the command as a dependency of the target.
add_custom_target(${t}
DEPENDS ${t_cmd}
)
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] more targets to run in parallel
2012/2/20 Andrea Crotti andrea.crott...@gmail.com:
On 02/20/2012 03:15 PM, David Cole wrote:
Use:
COMMAND ls -l
Not:
COMMAND ls -l
Yes thanks, I started using the because I noticed that sometimes they are
needed.
So suppose I want to split the options and the command, this:
set(myoptions one two three)
set(mycmd ls -l)
message(${mycmd} ${myoptions})
will produce
ls-lonetwothree
Which is not what I want, but with I get even a more strange result:
message(${mycmd} ${myoptions})
ls;-l one;two;three
and in the list command I don't see any way to simply concatenate two lists,
so how should I merge two different lists to produce a command?
You may avoid to create a list in the first place:
set(myoptions one two three)
instead of
set(myoptions one two three)
see
cmake --help-command list
or you can
string(REPLACE ; stringopts ${myoptions})
message(STATUS ${stringopts})
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] How to cleanly get rid of CMake specific properties?
2012/2/18 Eric Noulard eric.noul...@gmail.com: 2012/2/18 Alexander Neundorf neund...@kde.org: On Saturday 18 February 2012, Eric Noulard wrote: Hi all, I'm pursuing my quest for a better CPack doc. First set of modifications are in master: cpack --help-command-xxx cpack --help-variable-xxx works. However variables are somehow problematic because I get all the properties defined for CMake in the doc because variables are a special kind of properties. CPack (or CTest) is using a instance of cmake object which does: this-InitializeProperties(); in its constructor so that I end up with a lot more properties in full doc i.e. in cpack --help-full Than I thought I shall. Now there is two options: 1) Avoid InitializeProperties(); in cmake object constructor and do that elsewhere for CMake and nowhere for CTest and CPack. 2) Let CTest and CPack keep the CMake inherited properties and filter out the unwaned CMake specific section in the doc. 1) is definitely easier but raise a question: Do CTest and CPack NEED the cmake property definition? Is this a wanted behavior or just an oversight? i.e. is set_property(...) supposed to work in a ctest or cpack loaded script? 2) is doable but require more work. in the same way should the standard variable doc section be inherited from CMake to CTest/CPack? try (I know it's not supposed to work but nevertheless): ctest --help-variable-list and you'll see what I mean. 2) sounds like a hack. If the properties are there, there should be a reason for it, and then they should also appear in the documentation. Agreed but it strange to have documentation for ALLOW_DUPLICATE_CUSTOM_TARGETS RULE_LAUNCH_COMPILE COMPILE_DEFINITIONS etc... for either CPack or CTest. nevertheless they ARE currently defined in the CMake script interpreter used by CTest or CPack because as I said they are defined in the cmake object constructor. They do not appear in the CTest doc because --help-variable is not implemented they do now in cpack because of that. Concerning CPack I'm pretty sure no part of CPack code uses CMake inherited properties, cpack's cmake interpreter is not supposed to load For CTest I doubt it but the fact is I don't really know. A small test of CMake in scripting mode (see script attached try it with cmake -P scriptable.cmake) tells me some properties may be useful but may be not all of them... Your opinion? Just a precision, I did test CMake in script mode because it is basically the mode used by CTest and CPack. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja spaces in the path do not work on linux
Le 19 février 2012 15:19, Nicolas Desprès nicolas.desp...@gmail.com a écrit : Thanks for this Peter. I have just tried the new stage/ninja-generator branch with spaces in both the source and the binary directory and I got this result for the test suite: The following tests FAILED: 83 - CPackComponents (Failed) 217 - CMake.CheckSourceTree (Failed) Note that on my Linux box: - CMake.CheckSourceTree always fail even on the master branch (I never tried to understand why). Because you should have some local modification in the source tree. Try: ctest -V -R CMake.CheckSourceTree and you'll possibly get an explanation like: 232: additions='0' 232: conflicts='0' 232: modifications='0' 232: nonadditions='1' ... 232: CMake Error at CheckSourceTreeTest.cmake:422 (message): 232: test fails: local source tree non-additions: use git add before committing, 232: or remove the files from the source tree - CPackComponents fails only when there are spaces but the Unix Makefiles generator has the same issue. I think this should not happen, normally CPack generators that cannot handle space in build tree (like CPackRPM) should be filtered out. In order to know the culprit same method applies here: ctest -V -R ^CPackComponents$ (you can do ctest -V -R CPackComponents but you'll get more tests) -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CPackComponents fails with spaces in paths
Le 19 février 2012 16:07, Nicolas Desprès nicolas.desp...@gmail.com a écrit : Hi, The CPackComponents test fails on master where there is a space in the source tree. Here I think the trace: $ ctest -V -R 'CPackComponents$' == UpdateCTestConfiguration from :/home/despre_n/tmp/cmake space/_build/DartConfiguration.tcl Parse Config file:/home/despre_n/tmp/cmake space/_build/DartConfiguration.tcl Add coverage exclude regular expressions. Add coverage exclude: XCode Add coverage exclude: Kdevelop Add coverage exclude: /Source/(cm|kw)sys/ Add coverage exclude: /CMakeFiles/CMakeTmp/ Add coverage exclude: [A-Za-z]./[Qq]t/qt-.+-opensource-src UpdateCTestConfiguration from :/home/despre_n/tmp/cmake space/_build/DartConfiguration.tcl Parse Config file:/home/despre_n/tmp/cmake space/_build/DartConfiguration.tcl Test project /home/despre_n/tmp/cmake space/_build Constructing a list of tests Guessing configuration NoConfig Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 89 Start 89: CPackComponents 89: Test command: /home/despre_n/tmp/cmake\ space/_build/bin/ctest --build-and-test /home/despre_n/tmp/cmake space/Tests/CPackComponents /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents --build-generator Unix Makefiles --build-project CPackComponents --build-makeprogram /usr/bin/make --build-two-config --build-target package --build-options -DCPACK_BINARY_DEB:BOOL=ON -DCPACK_BINARY_RPM:BOOL=ON -DCPACK_BINARY_NSIS:BOOL=ON --graphviz=CPackComponents.dot --test-command /home/despre_n/tmp/cmake space/_build/bin/cmake -DCPackComponents_BINARY_DIR:PATH=/home/despre_n/tmp/cmake space/_build/Tests/CPackComponents -P /home/despre_n/tmp/cmake space/Tests/CPackComponents/VerifyResult.cmake 89: Test timeout computed to be: 1500 89: Generate graphviz: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylib... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylib.dependers... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp.dependers... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot... 89: Generate graphviz: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylib... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylib.dependers... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp.dependers... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot... 89: Internal cmake changing into directory: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents 89: CMake output == 89: Configuring 89: Configuring done 89: Generating 89: Generating done 89: Build files have been written to: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents 89: Configuring 89: Configuring done 89: Generating 89: Generating done 89: Build files have been written to: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents 89: End CMake output == 89: Change Dir: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents 89: 89: Run Clean Command:/usr/bin/make clean 89: 89: Run Build Command:/usr/bin/make package 89: [ 50%] Building CXX object CMakeFiles/mylib.dir/mylib.cpp.o 89: Linking CXX static library libmylib.a 89: [ 50%] Built target mylib 89: [100%] Building CXX object CMakeFiles/mylibapp.dir/mylibapp.cpp.o 89: Linking CXX executable mylibapp 89: [100%] Built target mylibapp 89: Run CPack packaging tool... 89: CMake Warning (dev) at /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackConfig.cmake:54 (SET): 89: Syntax error in cmake code at 89: 89: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackConfig.cmake:54 89: 89: when parsing string 89: 89: C:\Program Files\CMake Tests Install Root 89: 89: Invalid escape sequence \P 89: 89: Policy CMP0010 is not set: Bad variable reference syntax is an error. Run 89: cmake --help-policy CMP0010 for policy details. Use the cmake_policy 89: command to set the policy and suppress this warning. 89: This warning is for project developers. Use -Wno-dev to suppress it. 89: 89: CPack: Create package using DEB 89: CPack: Install projects 89: CPack: - Run preinstall
Re: [cmake-developers] CPackComponents fails with spaces in paths
Le 19 février 2012 17:20, Nicolas Desprès nicolas.desp...@gmail.com a écrit : 2012/2/19 Eric Noulard eric.noul...@gmail.com Le 19 février 2012 16:07, Nicolas Desprès nicolas.desp...@gmail.com a écrit : Hi, The CPackComponents test fails on master where there is a space in the source tree. Here I think the trace: $ ctest -V -R 'CPackComponents$' == UpdateCTestConfiguration from :/home/despre_n/tmp/cmake space/_build/DartConfiguration.tcl Parse Config file:/home/despre_n/tmp/cmake space/_build/DartConfiguration.tcl Add coverage exclude regular expressions. Add coverage exclude: XCode Add coverage exclude: Kdevelop Add coverage exclude: /Source/(cm|kw)sys/ Add coverage exclude: /CMakeFiles/CMakeTmp/ Add coverage exclude: [A-Za-z]./[Qq]t/qt-.+-opensource-src UpdateCTestConfiguration from :/home/despre_n/tmp/cmake space/_build/DartConfiguration.tcl Parse Config file:/home/despre_n/tmp/cmake space/_build/DartConfiguration.tcl Test project /home/despre_n/tmp/cmake space/_build Constructing a list of tests Guessing configuration NoConfig Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 89 Start 89: CPackComponents 89: Test command: /home/despre_n/tmp/cmake\ space/_build/bin/ctest --build-and-test /home/despre_n/tmp/cmake space/Tests/CPackComponents /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents --build-generator Unix Makefiles --build-project CPackComponents --build-makeprogram /usr/bin/make --build-two-config --build-target package --build-options -DCPACK_BINARY_DEB:BOOL=ON -DCPACK_BINARY_RPM:BOOL=ON -DCPACK_BINARY_NSIS:BOOL=ON --graphviz=CPackComponents.dot --test-command /home/despre_n/tmp/cmake space/_build/bin/cmake -DCPackComponents_BINARY_DIR:PATH=/home/despre_n/tmp/cmake space/_build/Tests/CPackComponents -P /home/despre_n/tmp/cmake space/Tests/CPackComponents/VerifyResult.cmake 89: Test timeout computed to be: 1500 89: Generate graphviz: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylib... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylib.dependers... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp.dependers... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot... 89: Generate graphviz: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylib... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylib.dependers... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp.dependers... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot... 89: Internal cmake changing into directory: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents 89: CMake output == 89: Configuring 89: Configuring done 89: Generating 89: Generating done 89: Build files have been written to: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents 89: Configuring 89: Configuring done 89: Generating 89: Generating done 89: Build files have been written to: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents 89: End CMake output == 89: Change Dir: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents 89: 89: Run Clean Command:/usr/bin/make clean 89: 89: Run Build Command:/usr/bin/make package 89: [ 50%] Building CXX object CMakeFiles/mylib.dir/mylib.cpp.o 89: Linking CXX static library libmylib.a 89: [ 50%] Built target mylib 89: [100%] Building CXX object CMakeFiles/mylibapp.dir/mylibapp.cpp.o 89: Linking CXX executable mylibapp 89: [100%] Built target mylibapp 89: Run CPack packaging tool... 89: CMake Warning (dev) at /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackConfig.cmake:54 (SET): 89: Syntax error in cmake code at 89: 89: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackConfig.cmake:54 89: 89: when parsing string 89: 89: C:\Program Files\CMake Tests Install Root 89: 89: Invalid escape sequence \P 89: 89: Policy CMP0010 is not set: Bad variable reference syntax is an error. Run 89: cmake --help-policy CMP0010 for policy details
Re: [cmake-developers] Making Config.cmake files easier to write
2012/2/17 Eric Noulard eric.noul...@gmail.com:
2012/2/17 Alexander Neundorf neund...@kde.org:
On Friday 17 February 2012, Eric Noulard wrote:
2012/2/17 Alexander Neundorf neund...@kde.org:
On Thursday 16 February 2012, Brad King wrote:
On 2/16/2012 1:24 PM, Alexander Neundorf wrote:
Actually I expected I would prefer this over the fixed names, but now
that I've done it and look at what Config.cmake.in file I have to
write, I think I liked the previous version with the fixed names
(CONFIG_HELPER) better. I think it was easier to do, a simple scheme.
I think the fixed names are better/simpler too. I'm not fond of
CONFIG_HELPER specifically. The information stored in them is
about the *package* that the file is configuring, which is why
I originally proposed the prefix PACKAGE_. The INCLUDE_INSTALL_DIR
is where the *package* goes, not where the config helper is/goes.
I pushed a branch MakingConfigFilesEasier_ConfigureMacro to stage.
It has documentation and a test.
An example Config.cmake.in file is attached.
I can still change names etc. tomorrow.
The macro is in CMakePackageHelpers.cmake.
Nice piece of work. Should be helpful to many of us.
Some more tuning remarks.
Why not offering more bundled interface to this feature ?
currently you have to:
1) include(CMakePackageConfigHelpers)
2) configure_package_config_file(FooConfig.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
INSTALL_DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake
PATH_VARS INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR)
3) write_basic_package_version_file(
${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
VERSION 1.2.3 COMPATIBILITY
SameMajorVersion)
4) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake )
Yes, these are all simple orthogonal functions, which can be described with
one sentence without using and.
1) is mandatory of course
3) is optional
2) and 4) should be using the same INSTALL_DESTINATION and
DESTINATION in order to be consistent.
I cannot imagine doing 2) or 3) without 4).
You are right.
It is a somewhat problematic point that the destinations must match.
So in the end, wouldn't it be simpler (for the user/developer) to have
something like:
include(CMakePackageConfigHelpers)
create_and_install_package_config_files(NAME Foo
CONFIG_TEMPLATE FooConfig.cmake.in
DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake
PATH_VARS INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR
VERSION 1.2.3
VERSION_COMPATIBILITY SameMajorVersion)
[...]
So the point is, is there any usefulness from the CMake user point of view,
in providing such higher-level (but less powerful) API for CMake
config file at all.
No obvious sign of interest for this idea on the list.
I won't work on create_and_install_package_config_files and rather continue
my work on improving CPack doc.
May come to that later after Alex's macros has been merged to master.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] How to cleanly get rid of CMake specific properties?
Hi all, I'm pursuing my quest for a better CPack doc. First set of modifications are in master: cpack --help-command-xxx cpack --help-variable-xxx works. However variables are somehow problematic because I get all the properties defined for CMake in the doc because variables are a special kind of properties. CPack (or CTest) is using a instance of cmake object which does: this-InitializeProperties(); in its constructor so that I end up with a lot more properties in full doc i.e. in cpack --help-full Than I thought I shall. Now there is two options: 1) Avoid InitializeProperties(); in cmake object constructor and do that elsewhere for CMake and nowhere for CTest and CPack. 2) Let CTest and CPack keep the CMake inherited properties and filter out the unwaned CMake specific section in the doc. 1) is definitely easier but raise a question: Do CTest and CPack NEED the cmake property definition? Is this a wanted behavior or just an oversight? i.e. is set_property(...) supposed to work in a ctest or cpack loaded script? 2) is doable but require more work. in the same way should the standard variable doc section be inherited from CMake to CTest/CPack? try (I know it's not supposed to work but nevertheless): ctest --help-variable-list and you'll see what I mean. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Build faild on Darwin? Don't know why?
My recent commit on CPack-dynamicDocSection http://cmake.org/gitweb?p=cmake.git;a=shortlog;h=e175af3e74006e6f3a4fdaead20522b29034c45b may have broken this build http://open.cdash.org/testDetails.php?test=135708291build=2018382 the trouble is I cannot imagine why, since most of the modification where done inside comment of some CPackXXX.cmake scripts. The part of my commit located in C++ files should be unrelated to CPack Bundle generator? I'm not a Mac OS user and the error: CPack Error: Error executing: /Developer/Tools/SetFile -a C /Volumes/BundleGeneratorTest-0.1-Darwin 1 CPack Error: Error assigning custom icon to temporary disk image. CPack Error: Problem compressing the directory CPack Error: Error when generating package: BundleGeneratorTest does not give me much information. Could someone help me with that, by may be ctest -R BundleGeneratorTest on current next or stage/CPack-dynamicDocSection ? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, next, updated. v2.8.7-2712-g48382d5
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 48382d577d3bda377183c781096b595dc3f260ad (commit)
via b8a274c091b63e6203b61f5aee40393d1409c9fc (commit)
via a6bce55aefd332f148a2753d5be0ec4383534473 (commit)
from 7339cab0d39c5bcdceca220d4397b796a6fbab56 (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=48382d577d3bda377183c781096b595dc3f260ad
commit 48382d577d3bda377183c781096b595dc3f260ad
Merge: 7339cab b8a274c
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Sat Feb 18 16:12:29 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Feb 18 16:12:29 2012 -0500
Merge topic 'CPack-dynamicDocSection' into next
b8a274c Add structured documentation for NSIS
a6bce55 Dynamically add documentation section specified in documented
script.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b8a274c091b63e6203b61f5aee40393d1409c9fc
commit b8a274c091b63e6203b61f5aee40393d1409c9fc
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Sat Feb 18 22:10:19 2012 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Sat Feb 18 22:10:19 2012 +0100
Add structured documentation for NSIS
diff --git a/Modules/CPackNSIS.cmake b/Modules/CPackNSIS.cmake
index d9dab53..093d0fc 100644
--- a/Modules/CPackNSIS.cmake
+++ b/Modules/CPackNSIS.cmake
@@ -1,70 +1,112 @@
+##section Variables specific to CPack Debian (DEB) generator
+##end
+##module
# - CPack NSIS generator specific options
#
# The following variables are specific to the graphical installers built
# on Windows using the Nullsoft Installation System.
+##end
#
+##variable
# CPACK_PACKAGE_INSTALL_REGISTRY_KEY - Registry key used when
# installing this project.
+##end
#
+##variable
# CPACK_NSIS_INSTALL_ROOT - The default installation directory presented
# to the end user by the NSIS installer is under this root dir. The full
# directory presented to the end user is:
# ${CPACK_NSIS_INSTALL_ROOT}/${CPACK_PACKAGE_INSTALL_DIRECTORY}
+##end
#
+##variable
# CPACK_NSIS_MUI_ICON - The icon file (.ico) for the generated
# install program.
+##end
#
+##variable
# CPACK_NSIS_MUI_UNIICON - The icon file (.ico) for the generated
# uninstall program.
+##end
#
+##variable
# CPACK_PACKAGE_ICON - A branding image that will be displayed inside
# the installer.
+##end
#
+##variable
# CPACK_NSIS_EXTRA_INSTALL_COMMANDS - Extra NSIS commands that will
# be added to the install Section.
+##end
#
+##variable
# CPACK_NSIS_EXTRA_UNINSTALL_COMMANDS - Extra NSIS commands that will
# be added to the uninstall Section.
+##end
#
+##variable
# CPACK_NSIS_COMPRESSOR - The arguments that will be passed to the
# NSIS SetCompressor command.
+##end
#
+##variable
# CPACK_NSIS_MODIFY_PATH - If this is set to ON, then an extra page
# will appear in the installer that will allow the user to choose
# whether the program directory should be added to the system PATH
# variable.
+##end
#
+##variable
# CPACK_NSIS_DISPLAY_NAME - The display name string that appears in
# the Windows Add/Remove Program control panel
+##end
#
+##variable
# CPACK_NSIS_PACKAGE_NAME - The title displayed at the top of the
# installer.
+##end
#
+##variable
# CPACK_NSIS_INSTALLED_ICON_NAME - A path to the executable that
# contains the installer icon.
+##end
#
+##variable
# CPACK_NSIS_HELP_LINK - URL to a web site providing assistance in
# installing your application.
+##end
#
+##variable
# CPACK_NSIS_URL_INFO_ABOUT - URL to a web site providing more
# information about your application.
+##end
#
+##variable
# CPACK_NSIS_CONTACT - Contact information for questions and comments
# about the installation process.
+##end
#
+##variable
# CPACK_NSIS_CREATE_ICONS_EXTRA - Additional NSIS commands for
# creating start menu shortcuts.
+##end
#
+##variable
# CPACK_NSIS_DELETE_ICONS_EXTRA -Additional NSIS commands to
# uninstall start menu shortcuts.
+##end
#
+##variable
# CPACK_NSIS_EXECUTABLES_DIRECTORY - Creating NSIS start menu links
# assumes that they are in 'bin' unless this variable is set.
# For example, you would set this to 'exec' if your executables are
# in an exec directory.
+##end
#
+##variable
# CPACK_NSIS_MUI_FINISHPAGE_RUN - Specify an executable to add an option
# to run on the finish page of the NSIS installer.
+##end
#=
# Copyright 2006-2009 Kitware, Inc.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h
[Cmake-commits] CMake branch, next, updated. v2.8.7-2717-g629cca4
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 629cca4518cec1781bc9bbb3bd20ec0d74a62429 (commit) via dee0a38648195786bae0abce437ef4617ea0912e (commit) via b4abcfecbe281373fd3c28adccf4c3002b7909c4 (commit) via 9717727d5fa29a993b22b9437e67cc28d8eaf52c (commit) via 7a8f44a2d6d23ec0345a1413f3a79c21f9566456 (commit) from 48382d577d3bda377183c781096b595dc3f260ad (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=629cca4518cec1781bc9bbb3bd20ec0d74a62429 commit 629cca4518cec1781bc9bbb3bd20ec0d74a62429 Merge: 48382d5 dee0a38 Author: Eric Noulard eric.noul...@gmail.com AuthorDate: Sat Feb 18 16:35:34 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Sat Feb 18 16:35:34 2012 -0500 Merge topic 'CPack-dynamicDocSection' into next dee0a38 Put CPack DMG and PackageMaker doc in separate files b4abcfe Correct copy/paste section name mistake 9717727 Suppress unecessary (now empty) doc sections 7a8f44a Add structure documentation for CPack Bundle generator http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dee0a38648195786bae0abce437ef4617ea0912e commit dee0a38648195786bae0abce437ef4617ea0912e Author: Eric NOULARD eric.noul...@gmail.com AuthorDate: Sat Feb 18 22:33:10 2012 +0100 Commit: Eric NOULARD eric.noul...@gmail.com CommitDate: Sat Feb 18 22:33:10 2012 +0100 Put CPack DMG and PackageMaker doc in separate files diff --git a/Modules/CPack.cmake b/Modules/CPack.cmake index 8a44991..e0a5518 100644 --- a/Modules/CPack.cmake +++ b/Modules/CPack.cmake @@ -187,61 +187,6 @@ # list of patterns, e.g., /CVS/;/\\.svn/;\\.swp$;\\.#;/#;.*~;cscope.* ##end # -# The following variables are specific to the DragNDrop installers -# built on Mac OS X: -# -# CPACK_DMG_VOLUME_NAME - The volume name of the generated disk -# image. Defaults to CPACK_PACKAGE_FILE_NAME. -# -# CPACK_DMG_FORMAT - The disk image format. Common values are UDRO -# (UDIF read-only), UDZO (UDIF zlib-compressed) or UDBZ (UDIF -# bzip2-compressed). Refer to hdiutil(1) for more information on -# other available formats. -# -# CPACK_DMG_DS_STORE - Path to a custom .DS_Store file which e.g. -# can be used to specify the Finder window position/geometry and -# layout (such as hidden toolbars, placement of the icons etc.). -# This file has to be generated by the Finder (either manually or -# through OSA-script) using a normal folder from which the .DS_Store -# file can then be extracted. -# -# CPACK_DMG_BACKGROUND_IMAGE - Path to an image file which is to be -# used as the background for the Finder Window when the disk image -# is opened. By default no background image is set. The background -# image is applied after applying the custom .DS_Store file. -# -# CPACK_COMMAND_HDIUTIL - Path to the hdiutil(1) command used to -# operate on disk image files on Mac OS X. This variable can be used -# to override the automatically detected command (or specify its -# location if the auto-detection fails to find it.) -# -# CPACK_COMMAND_SETFILE - Path to the SetFile(1) command used to set -# extended attributes on files and directories on Mac OS X. This -# variable can be used to override the automatically detected -# command (or specify its location if the auto-detection fails to -# find it.) -# -# CPACK_COMMAND_REZ - Path to the Rez(1) command used to compile -# resources on Mac OS X. This variable can be used to override the -# automatically detected command (or specify its location if the -# auto-detection fails to find it.) -# -# The following variable is specific to installers build on Mac OS X -# using PackageMaker: -# -# CPACK_OSX_PACKAGE_VERSION - The version of Mac OS X that the -# resulting PackageMaker archive should be compatible -# with. Different versions of Mac OS X support different -# features. For example, CPack can only build component-based -# installers for Mac OS X 10.4 or newer, and can only build -# installers that download component son-the-fly for Mac OS X 10.5 -# or newer. If left blank, this value will be set to the minimum -# version of Mac OS X that supports the requested features. Set this -# variable to some value (e.g., 10.4) only if you want to guarantee -# that your installer will work on that version of Mac OS X, and -# don't mind missing extra features available in the installer -# shipping with later versions of Mac OS X. -# # The following variables are for advanced uses of CPack: # ##variable diff --git a/Modules/CPackDMG.cmake b/Modules/CPackDMG.cmake new
[Cmake-commits] CMake branch, next, updated. v2.8.7-2719-ge175af3
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 e175af3e74006e6f3a4fdaead20522b29034c45b (commit) via cfac874b7783a5c464334bfc13d969a667f1c397 (commit) from 629cca4518cec1781bc9bbb3bd20ec0d74a62429 (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=e175af3e74006e6f3a4fdaead20522b29034c45b commit e175af3e74006e6f3a4fdaead20522b29034c45b Merge: 629cca4 cfac874 Author: Eric Noulard eric.noul...@gmail.com AuthorDate: Sat Feb 18 17:12:41 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Sat Feb 18 17:12:41 2012 -0500 Merge topic 'CPack-dynamicDocSection' into next cfac874 More documentation concerning CPack Components http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cfac874b7783a5c464334bfc13d969a667f1c397 commit cfac874b7783a5c464334bfc13d969a667f1c397 Author: Eric NOULARD eric.noul...@gmail.com AuthorDate: Sat Feb 18 23:10:14 2012 +0100 Commit: Eric NOULARD eric.noul...@gmail.com CommitDate: Sat Feb 18 23:10:14 2012 +0100 More documentation concerning CPack Components diff --git a/Modules/CPackComponent.cmake b/Modules/CPackComponent.cmake index 016cb8c..1598703 100644 --- a/Modules/CPackComponent.cmake +++ b/Modules/CPackComponent.cmake @@ -1,4 +1,4 @@ -##section Variables common to all CPack generators +##section Variables concerning CPack Components ##end ##module # - Build binary and source package installers @@ -25,6 +25,51 @@ # CPack commands: ##end # +##variable +# CPACK_COMPONENTS_ALL - The list of component to install. +# +# The default value of this variable is computed by CPack +# and contains all components defined by the project. The +# user may set it to only include the specified components. +##end +# +##variable +# CPACK_GENNAME_COMPONENT_INSTALL - Enable/Disable component install for +# CPack generator GENNAME. +# +# Each CPack Generator (RPM, DEB, ARCHIVE, NSIS, DMG, etc...) has a legacy +# default behavior. e.g. RPM builds monolithic whereas NSIS builds component. +# One can change the default behavior by setting this variable to 0/1 or OFF/ON. +##end +##variable +# CPACK_COMPONENTS_GROUPING - Specify how components are grouped for multi-package +# component-aware CPack generators. +# +# Some generators like RPM or ARCHIVE family (TGZ, ZIP, ...) generates several +# packages files when asked for component packaging. They group the component +# differently depending on the value of this variable: +# - ONE_PER_GROUP (default): creates one package file per component group +# - ALL_COMPONENTS_IN_ONE : creates a single package with all (requested) component +# - IGNORE : creates one package per component, i.e. IGNORE component group +# One can specify different grouping for different CPack generator by using +# a CPACK_PROJECT_CONFIG_FILE. +##end +##variable +# CPACK_COMPONENT_compName_DISPLAY_NAME - The name to be displayed for a component. +##end +##variable +# CPACK_COMPONENT_compName_DESCRIPTION - The description of a component. +##end +##variable +# CPACK_COMPONENT_compName_GROUP - The group of a component. +##end +##variable +# CPACK_COMPONENT_compName_DEPENDS - The dependencies (list of components) +# on which this component depends. +##end +##variable +# CPACK_COMPONENT_compName_REQUIRED - True is this component is required. +##end ##macro # cpack_add_component - Describes a CPack installation component # named by the COMPONENT argument to a CMake INSTALL command. --- Summary of changes: Modules/CPackComponent.cmake | 47 +- 1 files changed, 46 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.7-2723-g263d9bd
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 263d9bdd64621370b1da991d7e3f0a3334643099 (commit)
via 9a8103e929de7569fd2e5459a6676dff64d88892 (commit)
from b6012df7ad7145d35769aad98910cdd28c640302 (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=263d9bdd64621370b1da991d7e3f0a3334643099
commit 263d9bdd64621370b1da991d7e3f0a3334643099
Merge: b6012df 9a8103e
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Sat Feb 18 18:04:07 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Feb 18 18:04:07 2012 -0500
Merge topic 'CPack-dynamicDocSection' into next
9a8103e Try to fix compile error on Win32-vs70
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9a8103e929de7569fd2e5459a6676dff64d88892
commit 9a8103e929de7569fd2e5459a6676dff64d88892
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Sun Feb 19 00:01:39 2012 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Sun Feb 19 00:01:39 2012 +0100
Try to fix compile error on Win32-vs70
diff --git a/Source/cmDocumentation.cxx b/Source/cmDocumentation.cxx
index 1fb8ab6..904a157 100644
--- a/Source/cmDocumentation.cxx
+++ b/Source/cmDocumentation.cxx
@@ -16,6 +16,7 @@
#include cmsys/Directory.hxx
#include cmsys/Glob.hxx
+#include algorithm
//
static const char *cmDocumentationStandardOptions[][3] =
@@ -746,9 +747,9 @@ void cmDocumentation::addCPackStandardDocSections()
void cmDocumentation::addAutomaticVariableSections(const std::string section)
{
std::vectorstd::string::iterator it;
- it = find(this-VariableSections.begin(),
-this-VariableSections.end(),
-section);
+ it = std::find(this-VariableSections.begin(),
+ this-VariableSections.end(),
+ section);
/* if the section does not exist then add it */
if (it==this-VariableSections.end())
{
---
Summary of changes:
Source/cmDocumentation.cxx |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
Re: [cmake-developers] Making Config.cmake files easier to write
2012/2/17 Alexander Neundorf neund...@kde.org:
On Thursday 16 February 2012, Brad King wrote:
On 2/16/2012 1:24 PM, Alexander Neundorf wrote:
Actually I expected I would prefer this over the fixed names, but now
that I've done it and look at what Config.cmake.in file I have to write,
I think I liked the previous version with the fixed names
(CONFIG_HELPER) better. I think it was easier to do, a simple scheme.
I think the fixed names are better/simpler too. I'm not fond of
CONFIG_HELPER specifically. The information stored in them is
about the *package* that the file is configuring, which is why
I originally proposed the prefix PACKAGE_. The INCLUDE_INSTALL_DIR
is where the *package* goes, not where the config helper is/goes.
I pushed a branch MakingConfigFilesEasier_ConfigureMacro to stage.
It has documentation and a test.
An example Config.cmake.in file is attached.
I can still change names etc. tomorrow.
The macro is in CMakePackageHelpers.cmake.
Nice piece of work. Should be helpful to many of us.
Some more tuning remarks.
Why not offering more bundled interface to this feature ?
currently you have to:
1) include(CMakePackageConfigHelpers)
2) configure_package_config_file(FooConfig.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
INSTALL_DESTINATION
${LIB_INSTALL_DIR}/Foo/cmake
PATH_VARS
INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR)
3)
write_basic_package_version_file(${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
VERSION 1.2.3
COMPATIBILITY
SameMajorVersion)
4) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake )
1) is mandatory of course
3) is optional
2) and 4) should be using the same INSTALL_DESTINATION and
DESTINATION in order to be consistent.
I cannot imagine doing 2) or 3) without 4).
So in the end, wouldn't it be simpler (for the user/developer) to have
something like:
include(CMakePackageConfigHelpers)
create_and_install_package_config_files(NAME Foo
CONFIG_TEMPLATE FooConfig.cmake.in
DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake
PATH_VARS
INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR
VERSION 1.2.3
VERSION_COMPATIBILITY SameMajorVersion)
This would do the same as 1) + 2) + 3) +4) but...
a) enforces that 2) INSTALL_DESTINATION and 4) DESTINATION are the same
and produce appropriate install rule.
b) enforces that whatever the name of the CONFIG_TEMPLATE you end up with
NAMEConfig.cmake
and
NAMEConfigVersion.cmake
I think this is a good point because you don't have the choice of
the name do you?
c) VERSION and VERSION_COMPATIBILITY should be optional parameters
that would trigger
the creation (and install rule) of NAMEConfigVersion.cmake
I can try to write (probably tomorrow) the proposed macro using those
provided by Alex
if you find the idea useful. The proposed macro is not meant replace
the Alex's one but
to offer higher-level [possibly] simpler API.
PS: I start to think in most simple cases CONFIG_TEMPLATE could be
made optional as well
if we add another TARGET_EXPORT_FILE option which indicates the name of
export(TARGETS ... FILE ...), using this a proper config
template could be created as well.
PS2: we may need to add an optional COMPONENT option as well if the
generated install rule should
be put in some install component.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making GUI applications by default
2012/2/17 Stephen Kelly steve...@gmail.com: Hi there, Also in this thread one of the discussion topics was making CMake default to creating Gui-ready executables. That is, setting the WIN32_EXECUTABLE or MACOSX_BUNDLE property on the executable target. http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6961/focus=7005 By default CMake does not set those properties, which is actually uncommon. Generally in KDE at least, only unit tests and some small utilities are non- gui executables. We'd like to be able to specify with a defaultProperty something like set(CMAKE_CREATE_GUI_EXECUTABLES ON) You probably mean: set_property(GLOBAL PROPERTY CMAKE_CREATE_GUI_EXECUTABLES ON) which would set those target properties to True on the Windows and Mac platforms by default. For unit tests, we could then disable it again. Thoughts/comments? I have [at least] one project which build on Windows where some applications (not test) are not GUI apps. In fact those applications are seldom launched by the user because they are forked by some GUI apps. If this was set by default would my apps still be working as expected? or shall I put NON-GUI properties on them? If this was to be introduced I bet the default value of the property should be OFF (or not SET) for backward compatibility reason. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files easier to write
2012/2/17 Alexander Neundorf neund...@kde.org:
On Friday 17 February 2012, Eric Noulard wrote:
2012/2/17 Alexander Neundorf neund...@kde.org:
On Thursday 16 February 2012, Brad King wrote:
On 2/16/2012 1:24 PM, Alexander Neundorf wrote:
Actually I expected I would prefer this over the fixed names, but now
that I've done it and look at what Config.cmake.in file I have to
write, I think I liked the previous version with the fixed names
(CONFIG_HELPER) better. I think it was easier to do, a simple scheme.
I think the fixed names are better/simpler too. I'm not fond of
CONFIG_HELPER specifically. The information stored in them is
about the *package* that the file is configuring, which is why
I originally proposed the prefix PACKAGE_. The INCLUDE_INSTALL_DIR
is where the *package* goes, not where the config helper is/goes.
I pushed a branch MakingConfigFilesEasier_ConfigureMacro to stage.
It has documentation and a test.
An example Config.cmake.in file is attached.
I can still change names etc. tomorrow.
The macro is in CMakePackageHelpers.cmake.
Nice piece of work. Should be helpful to many of us.
Some more tuning remarks.
Why not offering more bundled interface to this feature ?
currently you have to:
1) include(CMakePackageConfigHelpers)
2) configure_package_config_file(FooConfig.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
INSTALL_DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake
PATH_VARS INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR)
3) write_basic_package_version_file(
${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
VERSION 1.2.3 COMPATIBILITY
SameMajorVersion)
4) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake )
Yes, these are all simple orthogonal functions, which can be described with
one sentence without using and.
1) is mandatory of course
3) is optional
2) and 4) should be using the same INSTALL_DESTINATION and
DESTINATION in order to be consistent.
I cannot imagine doing 2) or 3) without 4).
You are right.
It is a somewhat problematic point that the destinations must match.
So in the end, wouldn't it be simpler (for the user/developer) to have
something like:
include(CMakePackageConfigHelpers)
create_and_install_package_config_files(NAME Foo
CONFIG_TEMPLATE FooConfig.cmake.in
DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake
PATH_VARS INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR
VERSION 1.2.3
VERSION_COMPATIBILITY SameMajorVersion)
This would do the same as 1) + 2) + 3) +4) but...
a) enforces that 2) INSTALL_DESTINATION and 4) DESTINATION are the
same and produce appropriate install rule.
This is good on one side, but on the other side I always try not to hide
simple cmake commands.
I mean, every cmake-using developer should know configure_file() and
install(FILES). IMO it is ok if they have to use those functions.
Now for the Config file the issue is that it is somewhat complicated to get
them relocatable, so we need a helper here.
Combining the install() command into this macro hides the install(), i.e. if I
would search the CMakeLists.txt for install command, to find out what is
installed, I might not notice that this
create_and_install_package_config_files() wraps an install() command.
That's why I kept the install() out of the macro, so that for installing
anything there is always an install() command visible.
(this is a not sure we should do this, not a I seriously object to this
idea)
I agree with all this, and like I said my proposal was not about replacing
your set macros but more like offering an extra high-level one.
b) enforces that whatever the name of the CONFIG_TEMPLATE you end up
with NAMEConfig.cmake
and
NAMEConfigVersion.cmake
I think this is a good point because you don't have the choice of
the name do you?
...and the macro should FATAL_ERROR if CONFIG_TEMPLATE doesn't match
*Config.cmake.in or *-config.cmake.in ?
Sounds ok.
c) VERSION and VERSION_COMPATIBILITY should be optional parameters
that would trigger the creation (and install rule) of
NAMEConfigVersion.cmake
Maybe. OTOH, is there any reason to install a package without version numbers
?
None I think but we could offer a way to the developer to craft his
own Version file
so if those are not specified this means that the developer is
handling this by himself.
PS: I start to think in most simple cases CONFIG_TEMPLATE could be
made optional as well if we add another TARGET_EXPORT_FILE option which
indicates the name of export(TARGETS ... FILE ...), using this a proper
config template could be created as well.
We discussed that too
Re: [cmake-developers] Modifying RPATH feature to run tests uninstalled
2012/2/17 Stephen Kelly steve...@gmail.com:
Marcel Loose wrote:
Hi Stephen,
On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote:
-- 8 8 8 8 8 8 8 8 8 --
diff --git a/templates/tests/CMakeLists.txt
b/templates/tests/CMakeLists.txt
index d2e37d2..ad471c7 100644
--- a/templates/tests/CMakeLists.txt
+++ b/templates/tests/CMakeLists.txt
@@ -83,6 +83,7 @@ macro(GRANTLEE_TEMPLATES_UNIT_TESTS)
${_testresource_rcc_src}
)
add_test(${_testname} ${_testname}_exec )
+ set_property(TEST ${testname} PROPERTY ENVIRONMENT
LD_LIBRARY_PATH=${CMAKE_BINARY_DIR}/templates/lib)
Do you see anything wrong there?
You should use ${_testname} in the set_property() command. Don't you get
an error message from CMake? Or do you happen to have a variable
testname as well.
D'Oh! You're right. I typo'd there. It works with my system Qt if I fix the
typo.
However, it doesn't solve the whole problem for me. Mostly I use a Qt in a
non-standard prefix and I set LD_LIBRARY_PATH to find it (I have many Qts
and a script to change my environment)
I tried changing it to
set_property(TEST ${_testname} PROPERTY ENVIRONMENT
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${CMAKE_BINARY_DIR}/templates/lib)
ie appending to the LD_LIBRARY_PATH, and it didn't find the correct Qt.
I'm not sure it'll append using this shell-like syntax, which suppose
shell-like evaluation for $LD_LIBRARY_PATH.
Could you try
LD_LIBRARY_PATH=$ENV{LD_LIBRARY_PATH}:${CMAKE_BINARY_DIR}/templates/lib
instead, which uses the CMake variable syntax to access environment.
Is that something relevant for others that we should care about? Or is my
setup unusual and irrelevant? Is it a bug that the LD_LIBRARY_PATH from my
environment is not carried over?
Does you initial environment export LD_LIBRARY_PATH or not (simple set) ?
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] message could not create named generator CodeBlocks -MinGW Makefiles
2012/2/16 paspa...@noos.fr: Hello, I am trying to use CMake with codeblocks on windows, I created a simple project in the folder pCMake when I use the CMake interface I got the message: You mean graphical interface where you select the generator from a list? CMake Error: CMake was unable to find a build program corresponding to MinGW Makefiles. CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. and following the tutorial from florian-goujeon (CMake,CodeBlock), it's advise to execute a cmake --help from a console in the project folder in order to get the generator list codeblocks -MinGW Makefiles is listed but when I execute cMake . -GCodeBlocks -MinGW Makefiles I get also the following message CMake Error:could not create names generator CodeBlocks -MinGW Makefiles There must be a typo in the generator name you used, something like a missing space after the dash '-' or something similar. I installed codeblocks with the windows installer with gcc compiler and cmake with the windows installer I don't know what to do, any suggestions will be very helpful From your first error message CMake was unable to find a build program corresponding to MinGW Makefiles. CMAKE_MAKE_PROGRAM is not set. I would say that CMake is not finding mingw make program because it is not in your PATH. Did you add mingw tools to your path after installing Code::Blocks? I don't remember whether if Code::Blocks does that by itself or not. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] message could not create named generator CodeBlocks -MinGW Makefiles
2012/2/17 paspa...@noos.fr: Hello Eric, thank you for your suggestions and support I am going to try to detail more what I did: - Install CMake on Program Files/CMake 2.8/bin - Install CodeBlocks with its windows installer at the same time he asks if we want the gcc compiler I said ok and he installed MinGW in Program Files/CodeBlocks/MinGW - as you suggested he didn't set the path variable so now the path variable are: C:\Program Files\CMake 2.8\bin;C:\Program Files\CodeBlocks\MinGW; - I created a codeblock printhello project named pCMake then at this step I didn't know what to do exactly: First Attempt: I put a CMakeLists.txt file in the codeblocks Others folders with the file containing: cmake_minimum_required(2.8) project(pCMake) add_executable(pCMake main.cpp) and in the Project Properties/Project Settings : I set : Makefile:CMakeLists and check This is a custom MakeFile OK I see, this is not the way it works. 1) You write a CMakeLists.txt and associated C/C++ files in a folder 2) You create another directory 3) You ask CMake to **generate** the Code Blocks project from the CMakeLists.txt May be you could read the beginning of thoses documents: http://www.cmake.org/cmake/help/cmake_tutorial.html https://github.com/TheErk/CMake-tutorial/raw/master/CMake-tutorial-8feb2012.pdf in order to have a better idea of the CMake workflow. Second Attempt: use CMake cmake-gui interface where is the source code:C:\pCMake where to buid the binaries:C:\pCMake It is better habit to have separate directories for sources and binaries. see: http://www.cmake.org/Wiki/CMake_FAQ#Out-of-source_build_trees I push the button: Generate specify the generator for this project: select in the combo :CodeBlocks-MinGW MakeFiles check Use Default native compilers result: CMake Error at CMakeLists.txt:1 (cmake_minimum_required): cmake_minimum_required called with unknown argument 2.8 you have a syntax error in your CMakeLists.txt you should write cmake_minimum_required(VERSION 2.8) read on the documentation: http://www.cmake.org/cmake/help/documentation.html CMake Error: CMake was unable to find a build program corresponding to MinGW Makefiles. CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. find make.exe program in your Code::Blocks install and add the path to it to your PATH. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem when globbing files and using that OUTPUT variable between ADD_CUSTOM_COMMAND commands
2012/2/17 NoRulez noru...@me.com:
Hi,
i have several ADD_CUSTOM_COMMAND commands with a specified target (let's
say TARGET1).
Between those commands I need to collect files and want to use those
collected files in the next ADD_CUSTOM_COMMAND.
How can i do that, because the following doesn't work as expected.
ADD_CUSTOM_COMMAND(TARGET TARGET1
COMMAND SAMPLE_COMMAND ARGS ARGUMENTS
WORKING_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
COMMENT Doing some stuff
VERBATIM)
may be you could do:
ADD_CUSTOM_COMMAND(TARGET TARGET1
COMMAND SAMPLE_COMMAND ARGS ARGUMENTS
COMMAND ${CMAKE_COMMAND} -DOutFile=fl.cmake -P
collectFiles.cmake
COMMAND ${CMAKE_COMMAND} -DInFile=fl.cmake -P
doPostProcessing.cmake
WORKING_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
COMMENT Doing some stuff
VERBATIM)
the collectFiles step will do whatever you want and create the fl.cmake
file
which will be loaded by the second doPostProcessing in order to get
access to list of file in a pre-defined CMake var.
You can split this in separate add_custom_command but I don't see the need
in your example.
# HERE I NEED A CUSTOM COMMAND where the CUSTOM_FILES variable can be used
in the next ADD_CUSTOM_COMMAND
ADD_CUSTOM_COMMAND(OUTPUT CUSTOM_FILES
COMMAND /usr/bin/find ARGS ${CUSTOM_PATH} -type f
COMMENT Find files
VERBATIM)
ADD_CUSTOM_COMMAND(TARGET TARGET1
COMMAND SAMPLE_COMMAND ARGS ${CUSTOM_FILES}
WORKING_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
COMMENT Doing some stuff
VERBATIM)
ADD_CUSTOM_COMMAND(TARGET TARGET1
COMMAND SAMPLE_COMMAND ARGS ARGUMENTS
WORKING_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
COMMENT Doing some stuff
VERBATIM)
Thanks in advance
Best Regards
NoRuleu
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem when globbing files and using that OUTPUT variable between ADD_CUSTOM_COMMAND commands
2012/2/17 noru...@me.com
Is there no way to depend on an other custom command without using extra
files?
I don't think there is beside the fact that you can specify dependency
to a target (including custom target) or files using OUTPUT and DEPENDS options.
It would be nice if i can pass OUTPUT and TARGET to ADD_CUSTOM_COMMAND.
You can (using OUTPUT and DEPENDS) your problem is you don't
know the output of your command **statically**.
So i here is my problem in a more detail:
I want to get a list of files from
${CMAKE_RUNTIME_OUTPUT_DIR}/${PROJECT_NAME}.app where all files beginning
with ${PROJECT_NAME} would be excluded.
The result of this command is only known at build-time.
At build time the build tool (make, Visual Studio, etc...) is
running not CMake,
The objective of add_custom_ is to execute some commands **at
build-time** on behalf
of the build tool how would the build tool handle a CMake variable
while CMake is not even running ???
After that I want to iterate over that list (foreach) and run
ADD_CUSTOM_COMMAND for each file.
I see here no need for any extra files.
I think you are missing a point.
the ADD_CUSTOM_COMMAND processed by CMake when reading
CMakeLists.txt at CMake time
are ***TRANSLATED*** into build tool rules.
I think there is a need of an extra file because it's the only way to
communicate
build-time informations between several build tool rules (i.e.
derived from custom command).
The only way around I see would be for you to know ahead of build (at
CMake time)
the list of files you'll be processing.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Generating CMake scripts from Visual Studio solutions projects?
2012/2/17 Robert Dailey rcdai...@gmail.com: Is there a tool to do this? All I'm looking for is something to generate a first, basic pass of the script. Doesn't have to be pretty, I just want the majority of the work to be automated. Preprocessor defines, compiler flags, include directories, dependencies, all of this should be generated in the CMake script for me, I can manage cleanup and reorganization from there. Did you try the tool listed in the Wiki http://www.cmake.org/Wiki/CMake#Visual_Studio I cannot recommend any since I'm not a Visual Studio user but you may start from there... -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] message could not create named generator CodeBlocks -MinGW Makefiles
2012/2/17 paspa...@noos.fr: thank you Eric, I try to do what you explained,I don't if I got it correctly I got the same message, may I miss something OK I see, this is not the way it works. 1) You write a CMakeLists.txt and associated C/C++ files in a folder 2) You create another directory 3) You ask CMake to **generate** the Code Blocks project from the CMakeLists.txt I did the following things: 1-create a folder pCMake1 and put CMakeLists.txt and main.cpp 2-create a bin foler in pCMake1 3-run cmake-gui and put source code c:/pCMake1 binaries c:/pCMakes1/Bin that part is ok. then push Generate it asks: specify generator : CodeBlocks -MinGW MakesFiles check use default native compiler I check that the path variable are there CMake2.8 and CodeBlocks/MinGW PATH should contains path to make.exe and gcc.exe Is make.exe in CodeBlocks/MinGW ? May be it is not there but in a subdirectory of CodeBlocks/MinGW? Please avoid complete top-posting this make the message less readable. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Making Config.cmake files easier to write
2012/2/16 Brad King brad.k...@kitware.com:
On 2/16/2012 3:29 PM, Eric Noulard wrote:
What are you targeting?
install-time i.e. make install usage?
package install time prodduced with cpack usage?
package install time NOT produced with cpack usage?
a subset of this?
The goal is a FooConfig.cmake file for make install time but
that contains no hard-coded paths referring to the install prefix.
It should be totally relocatable. I think we've resolved all
that in the other parts of this thread.
I'm not convinced, yet I'll have to try with the example provided by Alex
by adding proper CPack usage in it.
Currently I see in BarConfig.cmake
get_filename_component(BAR_HELPER_PREFIX_DIR
${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
computed by CONFIGURE_CONFIG_FILE with
if(NOT IS_ABSOLUTE ${CCF_INSTALL_DESTINATION})
set(absInstallDir ${CMAKE_INSTALL_PREFIX}/${CCF_INSTALL_DESTINATION})
endif()
file(RELATIVE_PATH CONFIG_RELATIVE_PATH ${absInstallDir}
${CMAKE_INSTALL_PREFIX} )
where you can see the usage of CMAKE_INSTALL_PREFIX.
since CPack is using DESTDIR in order to do its local install before
actual packaging
I cannot see how this could work with CPack but again I may be simply
missing the point
I'll try to follow the thread tomorrow and try by myself.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files easier to write
2012/2/16 Brad King brad.k...@kitware.com:
On 2/16/2012 4:13 PM, David Cole wrote:
On Thu, Feb 16, 2012 at 3:52 PM, Eric Noulard eric.noul...@gmail.com
mailto:eric.noul...@gmail.com wrote:
I'm not convinced, yet I'll have to try with the example provided by
Alex
by adding proper CPack usage in it.
Currently I see in BarConfig.cmake
get_filename_component(BAR_HELPER_PREFIX_DIR
${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
[snip]
It can't work with CPack, not in the sense of work as in the
software will run from its DESTDIR-based intermediate CPack
driven install location
It can. The main feature of what Alex wrote based on a combination
of his, Yury's, and my ideas is that the generated BarConfig.cmake has
no hard-coded paths containing the installation prefix in any form,
DESTDIR or not. The line
get_filename_component(BAR_HELPER_PREFIX_DIR
${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
is evaluated when BarConfig.cmake is *loaded* at which point the
${CMAKE_CURRENT_LIST_DIR} will be replaced with the *current* location
of the file as it exists when loaded.
Yes right I got that, my point was that the /../../../
which was computed at configure time was computed w.r.t. CMAKE_INSTALL_PREFIX
know at CMake-time.
It doesn't matter if it is in
the real install location, DESTDIR, or a tarball that was extracted
at an arbitrary location on another machine. The load-time prefix
is computed relative to the file's location. Under that prefix the
file refers to all the other pieces (include, etc.) which exist at
a fixed location relative to BarConfig.cmake.
Right I did not realize that relative position should still be valid.
In fact I'm pretty sure you can break this if you mess-up with
absolute install destination, but if ones to that there is no point in using
this so...
Ok thank you (and David) for enlighting me on this.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Finding versioned libraries
2012/2/15 Rolf Eike Beer e...@sf-mail.de: Hi, as I found out today this construct doesn't work: find_library(MYLIB libfoo.so.2) This is because find_library will only try to access the whole path if the given name matches PREFIX.*SUFFIX, which is obviously not the case here. My simple approach on fixing this would be to also allow PREFIX.*SUFFIX\..*: [...] @@ -358,9 +358,17 @@ bool cmFindLibraryHelper::HasValidSuffix(std::string const name) [...] Any objections? If the user does not trust find_library for checking proper extension then: 1) He could modify/append CMAKE_FIND_LIBRARY_SUFFIXES in this case: list(APPEND CMAKE_FIND_LIBRARY_SUFFIXES .so.2) should work. 2) He could use find_file Now if we consider this is a bug, then with your modification HasValidSuffix is ill-named since it is more like ContainsValidSuffix or MatchesValidSuffix. With this modification one could now find a not-properly-installed library (missing links) without noticing it. What is your purpose here, do you want to ensure that you find a particular version of a lib? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Finding versioned libraries
2012/2/15 Brad King brad.k...@kitware.com: On 2/15/2012 9:18 AM, Eric Noulard wrote: If the user does not trust find_library for checking proper extension then: 1) He could modify/append CMAKE_FIND_LIBRARY_SUFFIXES in this case: list(APPEND CMAKE_FIND_LIBRARY_SUFFIXES .so.2) should work. 2) He could use find_file Now if we consider this is a bug, then with your modification HasValidSuffix is ill-named since it is more like ContainsValidSuffix or MatchesValidSuffix. With this modification one could now find a not-properly-installed library (missing links) without noticing it. What is your purpose here, do you want to ensure that you find a particular version of a lib? IMO searching for an exact file name like find_library(MYLIB libfoo.so.2) is useful regardless of the expected library type. The only reason CMake requires the library prefix and suffix to appear in the name is to prevent things like find_library(MYLIB python) from locating the python executable which is called just python. We check for both the prefix and suffix to ensure the file name looks like a library before considering it raw. ok I see. Back before CMake 2.6 started using full paths to link it was not possible to link to library file that did not look exactly like a library (proper prefix and suffix). Now that we can pass the exact file name to the linker we can have a softer test for what looks like a lib. ok too, no more question then :-] -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] External project source
2012/2/13 Nicholas Yue yue.nicho...@gmail.com:
On 13/02/12 6:47 PM, Eric Noulard wrote:
2012/2/13 Nicholas Yueyue.nicho...@gmail.com:
Hi,
There is an existing project I have access to that already have CMake
configuration file but the way it is written requires alot of
preprocessing
steps (python, shell etc) before it is usable.
I wanted to investigate a cleaner (truer to CMake original design
purpose) usage of CMake,
So, I have an original-project directory which contains both the
source
and the CMakeLists.txt in a nested directory structure.
I want to create my own CMake hierarchy (structure the same way) but
reference the source code in the original-project directory location.
How do I tell CMake to refer to source code at some other top level
directory as a starting point.
Is there such a concept in CMake ?
I am not sure to fully understand you request but in a CMakeLists.txt
you can perfectly
refer to source located outside the directory the CMakeLists.txt is in,
you can use either relative or absolute path and do something like:
add_executable(NiceTarget ../../relpath/to/source.c
${CMAKE_SOURCE_DIR}/abspath/to/another.c)
Yes, I know I can do that. I am hoping to avoid maintaining a hierarchy of
such modification.
There are 42 CMakeLists.txt files each with multiple libraries, test and
such.
I see...
I was hoping there is a way to (assuming I maintain the same hierarchy) tell
CMake to start looking for source from some other top level directory 'once'
and it will be able to find the source in the 'other' location that is
different to my 'cleaned-up' version of CMakeLists.txt
I'm afraid there isn't such a feature with CMake.
If I'm wrong I'm sure somebody will step in and explain the nasty
possibly undocumented feature you can use but I doubt it.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack ZIP generator: is there a way to avoid a root directory named ${CPACK_PACKAGE_FILE_NAME} in the zip?
2012/2/13 Massaro Alessio alessio.mass...@mediobanca.co.uk:
Hi there
The CPack ZIP generator seems to always put all “installed” files in a
directory called ${CPACK_PACKAGE_FILE_NAME}
So, if ${CPACK_PACKAGE_FILE_NAME}==”xyz”, the zip file will have one single
“xyz” directory at the root, with all “installed” files placed therein.
Does anyone know if there’s a way to switch off this behavior and have
everything zipped at the root of the zip file? (so no “xyz” directory
containing everything)
try
set(CPACK_INCLUDE_TOPLEVEL_DIRECTORY 0)
it should do what you want.
PS: you can try on the command line as well
cpack -D CPACK_INCLUDE_TOPLEVEL_DIRECTORY=0 -G ZIP
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] External project source
2012/2/13 Nicholas Yue yue.nicho...@gmail.com:
Hi,
There is an existing project I have access to that already have CMake
configuration file but the way it is written requires alot of preprocessing
steps (python, shell etc) before it is usable.
I wanted to investigate a cleaner (truer to CMake original design
purpose) usage of CMake,
So, I have an original-project directory which contains both the source
and the CMakeLists.txt in a nested directory structure.
I want to create my own CMake hierarchy (structure the same way) but
reference the source code in the original-project directory location.
How do I tell CMake to refer to source code at some other top level
directory as a starting point.
Is there such a concept in CMake ?
I am not sure to fully understand you request but in a CMakeLists.txt
you can perfectly
refer to source located outside the directory the CMakeLists.txt is in,
you can use either relative or absolute path and do something like:
add_executable(NiceTarget ../../relpath/to/source.c
${CMAKE_SOURCE_DIR}/abspath/to/another.c)
this is usually a bad idea but this should work.
Now that said if you do that for compatibility purpose in order to
maintain the legacy build
before doing the switch to genuine CMake build then may be using a
VCS like git would
be a better way to go.
Using git (or other easy branching VCS) you can work on your
genuine-CMake branch whithout
trouble while merging from the origin as it evolves. Using this,
people wanting to try your branch
could either pull it or you can create patches against origin.
At the risks of confusing matter, my closest example would be something
vaguely resembling VPATH
There is no such thing in CMake, as far as I know,
source files specified with relative path are searched
1) in the build tree,
2) in the source tree.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying Files into build-dir under Visual Studio vs. Codeblocks/Win32 vs. Codeblocks/Linux
2012/2/10 Stefan Fendt ste...@sfendt.de:
Hi,
I'm (still) quite unsure if this isn't an FAQ (or if not maybe should be
one), but I have read through everything I could google-up regarding
this topic and found nothing usable...
I'm writing an x-platform-project which will be compiled using different
compilers and or under different systems... for this project I am
required to move some files from some location (source/data) into the
build-directory. Whileas this works under Linux/Codeblocks/GCC as well
as Windows/Codeblocks/MinGW it doesn't for Visual Studio... Under Visual
Studio the files always are copied to some directory-location directly
above the actual binary-directory.
I've tried using ${CMAKE_CURRENT_BINARY} and it copies the files to the
marked position:
build/ --- copies into this directory
build/Debug
build/Release
build/source
After that I tried to do it with GET_TARGET_PROPERTY(... PROPERTY
LOCATION). I then get something like this...
'build/$(Configuration)'
...which of course doesn't solve the problem, too... because the
configuration under Visual Studio is only known after CMake-Generation
of the solution and running the compiler...
So, what is the suggested method of (if you can't avoid it) copying
files from anywhere into the build-directory, which is as compiler
agnostic as possible..?
You may use CMAKE_CFG_INTDIR.
Try:
cmake --help-variable CMAKE_CFG_INTDIR
You'll get some example with custom command/target.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake presentation/tutorial in Toulouse/France (8thFebruary)
2012/2/10 aaron.mead...@thomsonreuters.com: I went through the slides; pretty good introduction-intermediate presentation. Thank you, and yes that was pretty much the target. We did dive into some more advanced feature on-demand during the presentation. I'm forwarding it to all the teams I work with here! If someone has remarks may be the more suitable way would be to file an issue on github: https://github.com/TheErk/CMake-tutorial/issues -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake presentation/tutorial in Toulouse/France (8thFebruary)
2012/2/10 Yuri Timenkov y...@timenkov.ru: I did the same. And besides being a good CMake tutorial this is also awesome example how to make presentations with Latex :) Thanks for that too. Non mentionning that I did not have enough time to add the extra eye-candy animation using an impressive info file, see: http://impressive.sourceforge.net/. You would be surprised by the possibilities offered by the latex beamer+ impressive. Stopping here because I'm really going off-topic. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake presentation/tutorial in Toulouse/France (8th February)
2012/1/29 Eric Noulard eric.noul...@gmail.com: Hi All, Just a small advertisement. I will be giving a CMake presentation tutorial in Toulouse/France on February 8th, 2012: http://www.toulibre.org/evenements_a_venir À 20h00 Éric Noulard présentera CMake, outil de compilation et de test multi-plateforme. Presentation will be given in French. This is done and it was nice (at least from my side) The slides (in english) are here: http://noulard.name/CMake/CMake-tutorial-8feb2012.pdf The material I used for making the presentation is available here: http://noulard.name/CMake/CMake-tutorial-8feb2012.tar.bz2 and may be cloned/forked from github as well: https://github.com/TheErk/CMake-tutorial feel free to re-use/improve it. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Topic branches in limbo on the stage?
2012/2/8 David Cole david.c...@kitware.com: The stage is intended only for topics that are imminently going to be merged to 'next'... The following CMake topic branches have been on the stage for quite some time without being merged to 'next': CPackNSIS-fixIgnore-INCLUDE_TOPLEVEL | master=0 next=0 If it's ready to be tested on the dashboard machines, then please merge it to 'next'. Just done for this one which is mine. It fixes bug #12935. Now for have been on the stage for quite some time You guys will be reaching light speed soon enough; You mail: 2012/2/8 David Cole david.c...@kitware.com: My unmerged commit: commit 6a74eb1d36b079fe6b566244a636ac1e43303aa6 Author: Eric NOULARD eric.noul...@gmail.com Date: Sun Feb 5 13:13:48 2012 +0100 3 days!! Just kidding but... Thanks -- that will make our weekly merge sessions easier to do when we don't have to deal with this handful of noise that's not ready yet. OK. Please consider using github or some other free online git hosting facility for sharing branches with others when they are not yet ready for next. Noted too. Eventually, we'll get a gerrit instance to host CMake for us so that we can review changes in gerrit and avoid this sort of thing by default. Would be nice. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Default Generator to use
2012/2/7 Sarnath K - ERS, HCLTech k_sarn...@hcl.com: Hello Friends, How do I specify the default generator that CMAKE should use when invoked without the “-G” option? I am on Windows. I saw an old thread on this. But I am not sure if any support was added later on. Is there a REGISTRY entry in Windows that we can set to make so that CMAKE can check it? When starting with an empty build tree (or more precisely with empty cache) the logic of the default generator is implement in: Source/cmake.cxx::int cmake::ActualConfigure() There is some system dependent macro logic and in the Windows case the code comment says (if not in Borland or Cygwin or Mingw case): // Try to find the newest VS installed on the computer and // use that as a default if -G is not specified So no, as far as I understand the code, there is no registry entry that could possibly be set to force a particular default. I guess it shouldn't be that hard to implement but it is not there. (I'm not willing to try myself because I'm not a Windows user/developer) Nevertheless, may be you can explain us why you would like to setup a default? Is it too painful to add the extra -G argument? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to submit patches?
2012/2/7 Rolf Eike Beer e...@sf-mail.de: Am Montag, 6. Februar 2012, 19:12:27 schrieb Michael Pechner: Is this the correct forum? cmake-develop...@cmake.org would be the right place. Or open a bug report at http://cmake.org/Bug and attach it there. May be browse/search the bug tracker before filing a new bug just in case there is a similar/identical bug already reported. What format do you want the patch in? git format-patch How to get CMake git tree is explained here: http://www.cmake.org/Wiki/CMake/Git/Download More infos on using git for CMake here: http://www.cmake.org/Wiki/CMake/Git -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Default Generator to use
2012/2/7 Sarnath K - ERS, HCLTech k_sarn...@hcl.com: Hello Eric, We have a case where 2 teams are working on a common source tree. One team is using Visual Studio 9 2008 and the other Visual Studio 10 Our platform is Windows7 64-bit. We have a tool in our project that gets added as an External Project to the main CMAKE project. This tool needs to be compiled _only_ as a 32-bit windows executable. I use a configure.bat to configure this external project and build. You should have a look to ExternalProject cmake module and its ExternalProject_Add macro. This batch-file has to invoke CMAKE with either Visual Studio 9 2008 or Visual Studio 10. But I would like this batch file to use the latest Visual Studio installed in the system in 32-bit mode. I am on Win64 Command Prompt. The main project is generated using NMake Makefiles. How do I do this? My guess is that you should write some script or executable which does just that get the name of the latest Visual Studio installed in the system If you go for a script, may be a CMake script can do that. May be you could parse the output of cmake --help in order to get the list of supported generators and/or inspect registry yourself in order to build the appropriate name. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Default Generator to use
2012/2/7 Sarnath K - ERS, HCLTech k_sarn...@hcl.com: http://stackoverflow.com/questions/6430251/what-is-the-default-generator-for-cmake-in-windows In the stack overflow list, one guy mentions about [HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\ Is this the same thing as the AutoConfigure thing that you were mentioning? Yes it is. What should I set here? Pardon my ignorance. You shouldn't set anything here because it is set by the Visual Studio installer. CMake is only **reading** it in order to guess the latest VS installed. The comment on Stack Overflow is right: For posterity: there is an entry in the CMake mailing list that addresses this issue. To change the default generator, it seems you need to either modify the CMake source and recompile or write a small batch file that adds the -G option to substitute the generator when none is specified. – André Caron the refered ML message is: http://www.mail-archive.com/cmake@cmake.org/msg18033.html -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Default Generator to use
2012/2/7 Sarnath K - ERS, HCLTech k_sarn...@hcl.com: I just looked at ActualConfigure() function. This is the same as the one mentioned in Stackoverflow URL. I think I will just create the correct entries in the registry and allow CMAKE to take the decision. I won't pass any -G at all. That's the most portable way as I look at it. Not my opinion but that's your choice. [HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\9.0;InstallDir] -- seems to be the place. But I really don't understand what is the ; doing there. Should I first create a 9.0 entry and then create an InstallDir inside it pointing to the directory where Visual Studio is installed? You should read more about what is the registry, before trying to modify it: http://en.wikipedia.org/wiki/Windows_Registry http://support.microsoft.com/kb/136393 -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPACK generated DEB package can not create directories
2012/2/8 Ralf Lange ralf.la...@longsoft.de: I test it and it works. CMake 2.8.7 fix the problem. Great. Ok fine, thanks. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] Improving CPack Documentation (and may be others as well)
2012/2/6 David Cole david.c...@kitware.com: On Sun, Feb 5, 2012 at 6:50 PM, Eric Noulard eric.noul...@gmail.com wrote: 2012/2/1 David Cole david.c...@kitware.com: There's no rush here. We won't be reviewing your changes again until next Tuesday at this point... Hi all, I did push the work and the branch a little further yesterday. I didn't get any big red on the dashboard this time and I think it was worth going a little further. There is this issue on the dashboard: http://cdash.org/CDash/viewBuildError.php?buildid=1981062 Use empty string assignment: std::string s; s = ; ...instead of clear to avoid this problem on our (yes, I know, ancient, but annoyingly still there) VS6 dashboards. OK noted. Just fixed and pushed to next as well. I'm subscribed to CMake dashboard and I don't think I received that alert? Any reason for that? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] CPACK generated DEB package can not create directories
2012/2/6 Ralf Lange ralf.la...@longsoft.de: Hi, I use CPACK to generate RPM and DEB packages for my software. The RPM package wirks fine but the DEB package can not create the neccessary directories in the usr/lib directory. When I create the direcories by hand, it works. Who can help to fix this problem? May be I can, but you'll have to give more details: 1) Which version of CMake/CPack are you using? 2) What do you mean by can not create the neccessary directories in the usr/lib directory? a) you cannot create the .deb -- what kind of error do you get from cpack? a) you can create the .deb but cannot install it -- what kind of error do you get from dpkg? 3) Would you be able to create a small project which reproduce the problem? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPACK generated DEB package can not create directories
2012/2/6 Ralf Lange ralf.la...@longsoft.de: The CMake version is 2.8.2. The system is Debian 6.0.4 (squeez). The kernel is 2.6.32-5-amd64. The Desktop is Gnome 2.30.2. Could you try, cmake 2.8.7 (may be this fix http://www.cmake.org/Bug/view.php?id=10325 could solve your problem) and/or run cpack in fakeroot like: $ cd /home/ralf/Animation-Dev/qStopMotion/qstopmotion-buil-makefile $ fakeroot cpack -G DEB Then retry the installation. CPack generates the deb package. Than I open the package using GDebi Packet Installer. The installer ask for the superuser password and ends without installation. The error message is: dpkg: Error processing of /home/ralf/Animation-Dev/qStopMotion/qstopmotion-buil-makefile/qstopmotion-0.9.10-Linux.deb (--install): /usr/share/qstopmotion/graphics/qstopmotion_logo_transparent_75.png.dpkg-new can not be created (...): File or Directory not found. is the qstopmotion this project: http://www.qstopmotion.org/english/download_sources.html If yes did you made some change or could I theoretically try to reproduce the issue using the source I can find on this site? When I create all the directories on the command line bevor I start the installer, than it works. could you put the result of: dpkg-deb --contents yourdebfile.deb in a text file and send it to me? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.7-2478-g8236bb9
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 8236bb990d1b08cd7933fd13d2e3c08519750742 (commit) via 5a948cd22b448bf03ec939d46ef289eba9b9407c (commit) from 1036a1f6c298baeb29018a5838de813a9b2c7392 (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=8236bb990d1b08cd7933fd13d2e3c08519750742 commit 8236bb990d1b08cd7933fd13d2e3c08519750742 Merge: 1036a1f 5a948cd Author: Eric Noulard eric.noul...@gmail.com AuthorDate: Mon Feb 6 11:23:10 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Feb 6 11:23:10 2012 -0500 Merge topic 'ImproveCPackDoc-reloaded' into next 5a948cd Fix non existent std::string::clear on VS6 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5a948cd22b448bf03ec939d46ef289eba9b9407c commit 5a948cd22b448bf03ec939d46ef289eba9b9407c Author: Eric NOULARD eric.noul...@gmail.com AuthorDate: Mon Feb 6 17:20:54 2012 +0100 Commit: Eric NOULARD eric.noul...@gmail.com CommitDate: Mon Feb 6 17:20:54 2012 +0100 Fix non existent std::string::clear on VS6 diff --git a/Source/cmDocumentation.cxx b/Source/cmDocumentation.cxx index dde4953..02f69f1 100644 --- a/Source/cmDocumentation.cxx +++ b/Source/cmDocumentation.cxx @@ -786,7 +786,7 @@ int cmDocumentation::getDocumentedModulesListInDir( // No else if no section is found (undocumented module) } // No else cannot read first line (ignore this kind of error) - line.clear(); + line = ; } } if (nbDocumentedModules0) @@ -887,7 +887,7 @@ int cmDocumentation::GetStructuredDocFromFile( docCtxIdx++; docContextStack[docCtxIdx]=SDOC_SECTION; /* drop the rest of the line */ - line.clear(); + line = ; newCtx = true; } else if (mkword.substr(0,3)==end) --- Summary of changes: Source/cmDocumentation.cxx |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
Re: [cmake-developers] Improving CPack Documentation (and may be others as well)
2012/2/1 David Cole david.c...@kitware.com: There's no rush here. We won't be reviewing your changes again until next Tuesday at this point... Hi all, I did push the work and the branch a little further yesterday. I didn't get any big red on the dashboard this time and I think it was worth going a little further. It is not finished but it is already working relatively well so I think it's worth merging. Waiting for your feedback before going further, The next steps for this work may be: 0) Understand how to remove CMake leftovers from cpack --help-full (CMake properties and some CMake variables sections) May be some of you may be faster than for understanding that since CTest does not suffer from the same issue... At the same time it would be nice if we could create doc sections from ##section markup and not burry [All] section names in the C++ code. 1) Complete CPack variable doc * for variables common to all generators * for variable specific to each generator 2) Set up something for cmake --help- which makes it possible to parse doc in user scripts and/or cmake provided modules and get variables and command from it. 4) Do something with the ##module part of the doc. 5) Apply same principle in order to document CTest variables. Happy review :-] -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] static cmake, ctest executables
2012/2/5 Ilias Miroslav miroslav.il...@umb.sk: Dear Eric, yes, I would like to have static cmake execs for usage in (sometimes unequipped) grid environment; I tried your buildup prescription, but got dynamic execs, ilias@194.160.135.47:~/bin/cmake_static/.cmake -DBUILD_SHARED_LIBS=OFF -DCMAKE_EXE_LINKER_FLAGS_DEBUG=-static /home/ilias/bin/cmake_static/cmake-2.8.7 -- Configuring done -- Generating done CMake Warning: Manually-specified variables were not used by the project: CMAKE_EXE_LINKER_FLAGS_DEBUG Yes my example was meant for a DEBUD build so you should add -DCMAKE_BUILD_TYPE=Debug or -DCMAKE_BUILD_TYPE=Release and use: -DCMAKE_EXE_LINKER_FLAGS_RELEASE=-static -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] static cmake, ctest executables
2012/2/4 Ilias Miroslav miroslav.il...@umb.sk: Greetings, Sirs, I would like to have cmake and ctest executables static (for usage in grid enviroment). I tried to compile the newest cmake-2.8.7.tar.gz version with ./configure --prefix=/home/ilias/bin/cmake_static LDFLAGS=--static --disable-shared --enable-static but still got dynamic versions (see below), not static... Fully static may be achieved with cmake -DBUILD_SHARED_LIBS=OFF -DCMAKE_EXE_LINKER_FLAGS_DEBUG=-static /path/to/source I assume you compile CMake using cmake and not bootstrapping it. CMAKE_EXE_LINKER_FLAGS_BUILDTYPE specifies an extra linker flags when building executable. Doing this spit warning like: .../Utilities/cmcurl/hostip4.c:183: warning: Using 'gethostbyname_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking If you dig into the CMake ML, I think you should find some discussion about the issue you may have to get fully static executable on Linux or more precisely with glibc. Stackoverflow has some entry on the subject as well: http://stackoverflow.com/questions/3430400/linux-static-linking-is-dead You may try to get rid of libgcc and libstdc++ using -static-libgcc and -static-libstdc++ see http://www.trilithium.com/johan/2005/06/static-libstdc/ Are you sure you really need fully static executable? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.7-2464-gc277957
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 c277957813c26ec1ee300b2d39062d39f4a7ecd8 (commit)
via dce3f99c031507ef43a744838161d5992beba0a0 (commit)
via 0e1ddd4dd8c2a20f5a097c58155898eef0329e3b (commit)
via deb22f23bf5b184982fbc6c31cae0bcbfa1f9cc7 (commit)
via 1d5f7ee9049c20a9181610992e7057ebe580b989 (commit)
from 0f6f49786297b0ed2ac64bc353751e8239d7181e (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=c277957813c26ec1ee300b2d39062d39f4a7ecd8
commit c277957813c26ec1ee300b2d39062d39f4a7ecd8
Merge: 0f6f497 dce3f99
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Sat Feb 4 06:19:21 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Feb 4 06:19:21 2012 -0500
Merge topic 'ImproveCPackDoc-reloaded' into next
dce3f99 Create getDocumentedModulesListInDir which may be used in other
context.
0e1ddd4 Add missing section markup for CPackComponent
deb22f2 Example of builtin variable documentation (i.e. only used in C++
source code).
1d5f7ee Make the load of script documentation more efficient and dynamic.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dce3f99c031507ef43a744838161d5992beba0a0
commit dce3f99c031507ef43a744838161d5992beba0a0
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Sat Feb 4 12:15:57 2012 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Sat Feb 4 12:15:57 2012 +0100
Create getDocumentedModulesListInDir which may be used in other context.
This should makes it easier to use the same documented module
techniques for CTest, CMake or user module.
diff --git a/Source/CPack/cpack.cxx b/Source/CPack/cpack.cxx
index 25a72fa..3182915 100644
--- a/Source/CPack/cpack.cxx
+++ b/Source/CPack/cpack.cxx
@@ -26,7 +26,6 @@
#include cmCPackLog.h
#include cmsys/CommandLineArguments.hxx
-#include cmsys/Glob.hxx
#include cmsys/SystemTools.hxx
#include memory // auto_ptr
@@ -527,68 +526,26 @@ int main (int argc, char *argv[])
std::vectorcmDocumentationEntry commands;
-typedef std::pairstd::string,std::string docModuleSectionPair_t;
-typedef std::listdocModuleSectionPair_t docedModulesList_t;
-docedModulesList_t docedModList;
-docModuleSectionPair_t docPair;
-std::stringdocedFile;
+std::string docedFile;
+std::string docPath;
+cmDocumentation::documentedModulesList_t docedModList;
-cmsys::Glob gl;
-std::string findExpr;
-std::vectorstd::string files;
-std::string line;
docedFile = globalMF-GetModulesFile(CPack.cmake);
if (docedFile.length()!=0)
{
- findExpr += cmSystemTools::GetFilenamePath(docedFile.c_str());
- findExpr += /CPack*.cmake;
- if (gl.FindFiles(findExpr))
-{
-files = gl.GetFiles();
-for (std::vectorstd::string::iterator itf=files.begin();
- itf!=files.end();++itf)
- {
- std::ifstream fin((*itf).c_str());
- if (!fin) continue;
- if (cmSystemTools::GetLineFromStream(fin, line))
-{
-if (line.find(##section)!=std::string::npos)
- {
- docPair.first = cmSystemTools::GetFilenameName(*itf);
- // 10 is the size of '##section' + 1
- docPair.second = line.substr(10,std::string::npos);
- docedModList.push_back(docPair);
- }
-}
- else
-{
-line.clear();
-}
- }
-}
- else
-{
-// build the list of files to be parsed for documentation
-// extraction
-docPair.first = CPack.cmake;
-docPair.second = Variables common to all CPack generators;
-docedModList.push_back(docPair);
-docPair.first = CPackComponent.cmake;
-docedModList.push_back(docPair);
-}
+ docPath = cmSystemTools::GetFilenamePath(docedFile.c_str());
+ doc.getDocumentedModulesListInDir(docPath,CPack*.cmake,docedModList);
}
// parse the files for documentation.
-for (docedModulesList_t::iterator it = docedModList.begin();
- it!= docedModList.end(); ++it)
+cmDocumentation::documentedModulesList_t::iterator docedIt;
+for (docedIt = docedModList.begin();
+ docedIt!= docedModList.end(); ++docedIt)
{
- docedFile = globalMF-GetModulesFile((it-first).c_str());
- if (docedFile.length()!=0)
-{
- doc.GetStructuredDocFromFile(docedFile.c_str
Re: [CMake] CPack / Debian install location
2012/2/3 Oliver kfsone Smith osm...@playnet.com:
osmith@luciddev:~/pn/WW2/src$ cmake --version
cmake version 2.8.2
I can't see to get make package to generate Debian packages that install
any place but /usr/bin. (I actually want them in /playnet/ra/bin,
/playnet/ra/lib and so on)
SET(CPACK_GENERATOR DEB)
SET(CPACK_INSTALL_PREFIX /playnet/ra)
-- this one is only used when
CPACK_SET_DESTDIR is set to on.
SET(CPACK_PACKAGE_INSTALL_PREFIX /playnet/ra)
-- this one is not used anywhere in the CPack code.
The right one is:
set(CPACK_PACKAGING_INSTALL_PREFIX /playnet/ra)
SET(CPACK_DEBIAN_INSTALL_PREFIX /playnet/ra)
This one does not exist (i.e. is not used anywhere).
SET(CPACK_PACKAGE_VERSION
${REPO_WC_REVISION}.${CMAKE_BUILD_TYPE}-${WW2_TARGET_ENV})
SET(CPACK_PACKAGE_NAME servers)
SET(CPACK_PACKAGE_VENDOR Cornered Rat Software)
SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY Game servers)
SET(CPACK_PACKAGE_DESCRIPTION 'Game servers and tools.)
SET(CPACK_DEBIAN_PACKAGE_MAINTAINER Oliver Smith)
SET(CPACK_DEBIAN_PACKAGE_INSTALL_PREFIX /playnet/ra)
This one does not exist as well (i.e. is not used anywhere).
I've played with a half dozen other variable name combinations, but it still
all goes into /usr.
Remove all INSTALL_PREFIX you have used and set
set(CPACK_PACKAGING_INSTALL_PREFIX /playnet/ra)
You can specify this on the command line too:
cpack -D CPACK_PACKAGING_INSTALL_PREFIX=/playnet/ra -G DEB
More extensive doc of CPack variables should be coming soon:
http://public.kitware.com/Bug/view.php?id=10067
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
