Re: [CMake] Better handling of library dependencies for CPack
2011/4/22 Rosen Diankov rosen.dian...@gmail.com: Hi all, We've recently started generating (debian) packages with CPack and discovered that handling library dependencies for particular distributions was not as smooth as it can be. The *_DEPENDS string just gets copied over to the final package so it puts all the burden on the user side to manage what distribution's dependencies get enabled. For Deb package did you try the CPACK_DEBIAN_PACKAGE_SHLIBDEPS ? set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON) will make CPackDeb use dpkg-shlibdeps in order to find lib dependencies. Instead, can we have something similar to how build-type-dependent libraries work out? For example, a library string can be set according to: set(LIBRARY debug mylibraryd optimized mylibrary) And joining multiple library strings will take care of organizing the dependencies. In the same way, it would be cool if we can specify distribution dependencies that way: set(*DEPENDS ubuntu mylib3-dev debian mylib-devel) Then depending on the distribution type the user sets, the correct dependencies can be selected. You can already do Generator specific dependencies using a CPack project config file see: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29 This file is evaluated at cpack time, if you do match the distro name then you can already select the specific dependency yourself. An example on how to match distro name with lsb_release command or /etc/issue file is given in the attached script. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org SystemSpecificInformations.cmake Description: Binary data ___ 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] Better handling of library dependencies for CPack
2011/4/22 Rolf Eike Beer e...@sf-mail.de: We've recently started generating (debian) packages with CPack and discovered that handling library dependencies for particular distributions was not as smooth as it can be. The *_DEPENDS string just gets copied over to the final package so it puts all the burden on the user side to manage what distribution's dependencies get enabled. Instead, can we have something similar to how build-type-dependent libraries work out? For example, a library string can be set according to: set(LIBRARY debug mylibraryd optimized mylibrary) And joining multiple library strings will take care of organizing the dependencies. In the same way, it would be cool if we can specify distribution dependencies that way: set(*DEPENDS ubuntu mylib3-dev debian mylib-devel) Then depending on the distribution type the user sets, the correct dependencies can be selected. There are not that many binary package formats out there. Since we already know the absolute path of the libraries we depend on (since the find_package() things found them) we could feed them through rpm -qf or whatever meets that on Debian based systems. Then you automatically have the correct package names no matter how the distros decide to call them. That should be what dpkg-shlibdeps does for Debian. The usage of rpm -qf is not used by CPackRPM but it would be a nice contribution :-] -- 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] Better handling of library dependencies for CPack
2011/4/22 Rosen Diankov rosen.dian...@gmail.com:
Hi Guys,
You are right about shlibdeps, but this is not the whole story.
Debian source packages required build dependencies to be
preinstalled before cmake even runs. This tells each distribution what
it needs so that cmake can find it with find_package.
Yes off course build dependencies may be distribution specific and
may not be found with executable/lib dep.
Afterwards, it isn't necessary to specify all the dependencies since
they can be extracted from the symbols of the shared objects
(dpkg-shlibdeps). However, there are cases where the symbols are not
used, but it is still required.
For example, I have a program that generates c++ files once it is
called. This program requires g++ to be present, or otherwise it will
not work. Therefore g++ is a runtime dependency, but there are no g++
symbols in the program.
yes ok too.
For this the better we can do is to offer the user with a way to
manually specify thoses dependencies for each distribution he wants
to support.
About Eric's suggestion with Generator specific dependencies, this
is not necessary for our application at the moment. What we want is
for a specific generator, to have distribution specific
dependencies.
Yes I understood that but in the CPackConfig file you may setup distro
specific deps from within generator specific case.
save the attached CPackConfig.cmake file in your project directory
then add
set(CPACK_PROJECT_CONFIG_FILE ${CMAKE_CURRENT_SOURCE_DIR}/CPackConfig.cmake)
in your main CMakeLists.txt then
rerun CMake
run CPack and see what happen.
I think that you'll see that it should suits your needs
since you may already customize the dependencies
in a distribution specific way for any CPack generator.
May seems weird but it should work.
This scheme supposes you are not cross-packaging like packaging
a Fedora RPM on a debian host.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
CPackConfig.cmake
Description: Binary data
___
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] Better handling of library dependencies for CPack
2011/4/22 Rosen Diankov rosen.dian...@gmail.com: Hi Eric, Before I start running things, basically the script sets CPACK_DEBIAN_PACKAGE_DEPENDS right? What does this effect have on cpack? On CPack generic part none but the CPack Debian generator use it when building the binary debian package and adds the packages mentionned in CPACK_DEBIAN_PACKAGE_DEPENDS as dependencies. But I thougt you were already doing this, am I wrong? Also, If we're generating debian source packages, i'm not sure if it is a good idea to set DISTRO_CODENAME, DISTRO_RELEASE, AND DISTRO_ID inside the cmake environment. Ideally it should be possible to generate the source packages for all distributions on the same OS. Yes it should source packages tends to have less distro-specific dependencies. The example of definition of DISTRO_CODENAME, DISTRO_RELEASE etc... is just an example you could just define the var which is useful for your do distro specific things at CPack time. Currently I do source distribution using compressed tarball and use give some instruction on how to build RPM, Deb etc.. out of that so that I don't need source deb or source rpm. I guess this is where the philosophical arguments would start: is it really necessary for cmake/cpack to generate source debs for a different distribution than the one it is currently running on ;0) Cross-packaging is even more tedious than cross-compiling. If I had to that I think I will go with virtual machine hosting the target system, but as you said it's a philosophical point of view. i would say yes. Even if it is possible to set up chroot environments for N OSes, the sourcecode files would have to be sent N times, whereas they only need to be sent once... Also, you can do lsb_release -is lsb_release -rs lsb_release -cs to get the names directly without regex. Yes thanks I'll update my script. -- 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.4-1453-g890d2b2
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 890d2b2fd8d4222927e5858622ee8a81adaf98a0 (commit)
via d3fd945900f1fc09816cb59745c2fb241fa9b36c (commit)
via 046b615bc87eb339d185627a82bab99d27c071e6 (commit)
via 7b9d679b76c7c124f3a8621b6348c452c201dd71 (commit)
from 0fdfd6529d6600f3cf7415ef28e0d2156a3b67d6 (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=890d2b2fd8d4222927e5858622ee8a81adaf98a0
commit 890d2b2fd8d4222927e5858622ee8a81adaf98a0
Merge: 0fdfd65 d3fd945
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Sun Apr 17 11:13:45 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sun Apr 17 11:13:45 2011 -0400
Merge topic 'CPackRPM-fix12096' into next
d3fd945 CPackRPM Fix #12096: handle absolute install path with component
install
046b615 KWSys Nightly Date Stamp
7b9d679 KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d3fd945900f1fc09816cb59745c2fb241fa9b36c
commit d3fd945900f1fc09816cb59745c2fb241fa9b36c
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Sun Apr 17 17:12:38 2011 +0200
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Sun Apr 17 17:12:38 2011 +0200
CPackRPM Fix #12096: handle absolute install path with component install
diff --git a/Modules/CPackRPM.cmake b/Modules/CPackRPM.cmake
index 26209a7..d9d074c 100644
--- a/Modules/CPackRPM.cmake
+++ b/Modules/CPackRPM.cmake
@@ -495,6 +495,20 @@ EXECUTE_PROCESS(COMMAND find -type f -o -type l
WORKING_DIRECTORY ${WDIR}
OUTPUT_VARIABLE CPACK_RPM_INSTALL_FILES)
+# In component case, replace CPACK_ABSOLUTE_DESTINATION_FILES
+#with the content of CPACK_ABSOLUTE_DESTINATION_FILES_COMPONENT
+# This must be done BEFORE the CPACK_ABSOLUTE_DESTINATION_FILES handling
+if(CPACK_RPM_PACKAGE_COMPONENT)
+ if(CPACK_ABSOLUTE_DESTINATION_FILES)
+ set(COMPONENT_FILES_TAG
CPACK_ABSOLUTE_DESTINATION_FILES_${CPACK_RPM_PACKAGE_COMPONENT})
+ set(CPACK_ABSOLUTE_DESTINATION_FILES ${${COMPONENT_FILES_TAG}})
+ if(CPACK_RPM_PACKAGE_DEBUG)
+ message(CPackRPM:Debug: Handling Absolute Destination Files
${CPACK_ABSOLUTE_DESTINATION_FILES})
+ message(CPackRPM:Debug: in component = ${CPACK_RPM_PACKAGE_COMPONENT})
+ endif(CPACK_RPM_PACKAGE_DEBUG)
+ endif()
+endif()
+
if (CPACK_ABSOLUTE_DESTINATION_FILES)
IF(CPACK_RPM_PACKAGE_DEBUG)
message(CPackRPM:Debug: Handling Absolute Destination Files:
${CPACK_ABSOLUTE_DESTINATION_FILES})
diff --git a/Source/CPack/cmCPackGenerator.cxx
b/Source/CPack/cmCPackGenerator.cxx
index c8a77d1..7e5b26d 100644
--- a/Source/CPack/cmCPackGenerator.cxx
+++ b/Source/CPack/cmCPackGenerator.cxx
@@ -867,6 +867,28 @@ int
cmCPackGenerator::InstallProjectViaInstallCMakeProjects(
cmCPackLogger(cmCPackLog::LOG_DEBUG,
Got some ABSOLUTE DESTINATION FILES:
absoluteDestFiles std::endl);
+ // define component specific var
+ if (componentInstall)
+{
+std::string absoluteDestFileComponent =
+std::string(CPACK_ABSOLUTE_DESTINATION_FILES)
++ _ + GetComponentInstallDirNameSuffix(installComponent);
+if (NULL != this-GetOption(absoluteDestFileComponent.c_str()))
+ {
+std::string absoluteDestFilesListComponent =
+this-GetOption(absoluteDestFileComponent.c_str());
+absoluteDestFilesListComponent +=;;
+absoluteDestFilesListComponent +=
+mf-GetDefinition(CPACK_ABSOLUTE_DESTINATION_FILES);
+this-SetOption(absoluteDestFileComponent.c_str(),
+absoluteDestFilesListComponent.c_str());
+ }
+else
+ {
+ this-SetOption(absoluteDestFileComponent.c_str(),
+ mf-GetDefinition(CPACK_ABSOLUTE_DESTINATION_FILES));
+ }
+}
}
if ( cmSystemTools::GetErrorOccuredFlag() || !res )
{
---
Summary of changes:
Modules/CPackRPM.cmake| 14 ++
Source/CPack/cmCPackGenerator.cxx | 22 ++
Source/kwsys/kwsysDateStamp.cmake |2 +-
3 files changed, 37 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo
Re: [CMake] Searchable mail archive
2011/4/13 Michael Wild them...@gmail.com: On 04/13/2011 09:45 AM, J.S. van Bethlehem wrote: Dear CMake users, This week I started to investigate possibilities to move my build-system over to CMake after hearing a lot of good stories about it. To be honest, so far I'm still not quite convinced. The learning (I find at least) is rather steep and the documentation rather sparse (afaics) Then I noticed this mailing list, which would obviously be a got source to look for help, if it were searchable - so that's my question: is there some mirror of the mail-archive where I can search through passed mails to the list? Yours sincerely, Jakob van Bethlehem Hi Jakob Welcome to CMake! There's a Wiki with a FAQ, also covering your question: http://www.cmake.org/Wiki/CMake_FAQ#Where_can_I_find_searchable_CMake_Mailing_Archives.3F And then there's the book: http://www.kitware.com/products/books/CMakeBook.html And always, always, remember the mantra: man cmake seconded by the various: cmake --help-X X = command, module, policy, property, variable, X-list works as well. If you are Unix/Linux+bash user the cmake-completion script may help you too: http://cmake.org/gitweb?p=cmake.git;a=blob_plain;f=Docs/cmake-completion;hb=HEAD May be you can tell us what are your targeted platform(s) and main development host such that we can give you better insight on why CMake may (or may not) fullfil your needs. Which build system are you using now? Autotools, SCons, custom makefiles, some IDE project files? Are you cross-compiling or not? Have you some packaging needs where CPack can help? Do you use some continuous testing technics where CTest can help too? -- 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] embedded path in shared library linked into another shared library
2011/4/11 David Aiken david.ai...@cis-vancouver.com: Hi all.. I’m using cmake 2.8.4 on Centos 5.2. I build a libUtility.so and a libSecurity.so which depends on it. The utility library is located in “../../lib/libUtility.so” during the build. If I do an ldd on libSecurity.so I can see this relative path for libUtility.so in both the build and install versions of the libSecurity.so library. I would like to remove it, but have had no luck. From the docs it seems that the rpath would be removed if I add “SET(CMAKE_SKIP_RPATH TRUE)” to the CMakeLists.txt, but there is no change. As far as I understand this http://www.cmake.org/Wiki/CMake_RPATH_handling it should work with CMAKE_SKIP_RPATH set to TRUE did you try using a fresh build tree? You could try with: SET(CMAKE_SKIP_BUILD_RPATH TRUE) SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) SET(CMAKE_INSTALL_RPATH ) -- 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] could not find cmake module
2011/4/9 Christian Vander Jagt chrisvanderj...@yahoo.com: I am trying to use cmake to compile a program from source code, i am getting this error: CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_CXX_COMPILER_ENV_VAR CMake Error: Could not find cmake module file:C:/MinGW/msys/1.0/home/Kristy/CMak eFiles/CMakeCXXCompiler.cmake -- Configuring incomplete, errors occurred! Could you provide us more informations: Which version of CMake are you using? Did compile it yourself and if not where did you get it? You seems to be on a Windows platform, are using cygwin or plain windows ? Which version of Windows are you using (XP, Vista, 7 etc...) Which CMake generator are you trying to use ? Mingw+Makefile or ?? Could you show us your main CMakeLists.txt ? -- 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] could not find cmake module
2011/4/10 Christian Vander Jagt chrisvanderj...@yahoo.com: I'm using CMake 2.8, You should something like 2.8.x, what is the x ? I did not compile it, I got it from http://cmake.org/cmake/resources/software.html, Ok good, I bet you took the Windows Installer. I guess plain windows vista, the compiler I'm using is MinGW, not sure if that's the same as the generator, The generator is the name you chose after you've launched CMake from a pristine build tree. If you do not remember which one you chose the first time try with a new build tree: http://www.cmake.org/Wiki/CMake_FAQ#Out-of-source_build_trees i have probably about 20 CMakeLists.txt, which one do you want? The upper level one or the first one which makes CMake fail. By the way did you wrote those CMakeLists.txt or are you trying to compile someone else sources? Did you succeed to compile those sources before with 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] could not find cmake module
2011/4/10 Christian Vander Jagt chrisvanderj...@yahoo.com: I am trying to compile VTK, i have never used CMake before, 2.8.4, MinGW makefiles is the generator, Then you should ask your question on the VTK mailing list in the first place. http://www.vtk.org/VTK/help/mailing.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
[Cmake-commits] CMake branch, next, updated. v2.8.4-1402-g8983cb1
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 8983cb1d0b9a083ef08b0e338e18d048a741668c (commit)
via b22fcfb0c55ec145a4cf7405120c708fa136d928 (commit)
via 4e9506ac31705f5099f226128b98ae12a4ba9772 (commit)
from c97d814e780fd79a600934092d185cc73ffa9b24 (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=8983cb1d0b9a083ef08b0e338e18d048a741668c
commit 8983cb1d0b9a083ef08b0e338e18d048a741668c
Merge: c97d814 b22fcfb
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Sat Apr 9 03:32:06 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Apr 9 03:32:06 2011 -0400
Merge topic 'CPackDeb-fix12061' into next
b22fcfb CPackDeb: Handle dirs for CONTROL_EXTRA correctly when packaging
components
4e9506a KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b22fcfb0c55ec145a4cf7405120c708fa136d928
commit b22fcfb0c55ec145a4cf7405120c708fa136d928
Author: Martin Konrad kon...@ikp.tu-darmstadt.de
AuthorDate: Sat Apr 9 09:30:19 2011 +0200
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Sat Apr 9 09:30:19 2011 +0200
CPackDeb: Handle dirs for CONTROL_EXTRA correctly when packaging components
Copy the files specified in CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA to the right
directory when packaging components. This fixes #12061.
Signed-off-by: Eric NOULARD eric.noul...@gmail.com
diff --git a/Source/CPack/cmCPackDebGenerator.cxx
b/Source/CPack/cmCPackDebGenerator.cxx
index 5665404..8c19bbd 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -491,7 +491,7 @@ int cmCPackDebGenerator::createDeb()
{
std::string filenamename =
cmsys::SystemTools::GetFilenameName(i-c_str());
- std::string localcopy = toplevel;
+ std::string localcopy = this-GetOption(WDIR);
localcopy += /;
localcopy += filenamename;
// if we can copy the file, it means it does exist, let's add it:
---
Summary of changes:
Source/CPack/cmCPackDebGenerator.cxx |2 +-
Source/kwsys/kwsysDateStamp.cmake|2 +-
2 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] CMake 2.8.4 RPMs available (finally)
2011/4/5 Andrea Galeazzi galea...@korg.it: Fedora isn't listed there but is it possible to have it? For what is worth, you can build a CMake RPM using a previously installed CMake on almost any Linux distro if rpmbuild is installed (and compiler etc...). Run the attach script on your Fedora box using: $ mkdir tmp $ cd tmp $ cmake -P CMake-autobuild.cmake and you should get a cmake-2.8.4 RPM. the script has 2 possible parameter: $ cmake -DCMAKESRC_VERSION=2.8.2 -DWITH_QT_DIALOG=1 -P CMake-autobuild.cmake will build cmake 2.8.2 (and not the default 2.8.4) with QT dialog. QT dialog is not activated by default because you need to have qt-devel installed. The currently built RPM is monolithic but this may be improved if needed. This is an example for RPM but it may be done for DEB as well. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org CMake-autobuild.cmake Description: Binary data ___ 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.4-1336-g3ed8adf
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 3ed8adfbb32ce4e8390183d9a469a1ac53348743 (commit)
via 4bb79402e8f4e5c9c01637f70ca9e4d7b682473b (commit)
from c7a5235d3bb1c99e746359ad2fca7ee045ad30c1 (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=3ed8adfbb32ce4e8390183d9a469a1ac53348743
commit 3ed8adfbb32ce4e8390183d9a469a1ac53348743
Merge: c7a5235 4bb7940
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Mon Apr 4 14:21:13 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Apr 4 14:21:13 2011 -0400
Merge topic 'ModularizeCPack-dot-CMake' into next
4bb7940 Split CPack.cmake in more manageable parts
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4bb79402e8f4e5c9c01637f70ca9e4d7b682473b
commit 4bb79402e8f4e5c9c01637f70ca9e4d7b682473b
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Sun Apr 3 21:57:53 2011 +0200
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Mon Apr 4 20:18:27 2011 +0200
Split CPack.cmake in more manageable parts
Put NSIS, Bundle and Component related MACROs in separate files.
This does not implies functional changes, concerning the way
CPack is used.
diff --git a/Modules/CPack.cmake b/Modules/CPack.cmake
index 797ee57..bf52b25 100644
--- a/Modules/CPack.cmake
+++ b/Modules/CPack.cmake
@@ -11,13 +11,7 @@
# For certain kinds of binary installers (including the graphical
# installers on Mac OS X and Windows), CPack generates installers that
# allow users to select individual application components to
-# install. The contents of each of the components are identified by
-# the COMPONENT argument of CMake's INSTALL command. These components
-# can be annotated with user-friendly names and descriptions,
-# inter-component dependencies, etc., and grouped in various ways to
-# customize the resulting installer. See the cpack_add_* commands,
-# described below, for more information about component-specific
-# installations.
+# install. See CPackComponent module for that.
#
# The CPACK_GENERATOR variable has different meanings in different
# contexts. In your CMakeLists.txt file, CPACK_GENERATOR is a
@@ -183,93 +177,6 @@
# automatically detected command (or specify its location if the
# auto-detection fails to find it.)
#
-# Installers built on Mac OS X using the Bundle generator use the
-# aforementioned DragNDrop variables, plus the following Bundle-specific
-# parameters:
-#
-# CPACK_BUNDLE_NAME - The name of the generated bundle. This
-# appears in the OSX finder as the bundle name. Required.
-#
-# CPACK_BUNDLE_PLIST - Path to an OSX plist file that will be used
-# as the Info.plist for the generated bundle. This assumes that
-# the caller has generated or specified their own Info.plist file.
-# Required.
-#
-# CPACK_BUNDLE_ICON - Path to an OSX icns file that will be used as
-# the icon for the generated bundle. This is the icon that appears
-# in the OSX finder for the bundle, and in the OSX dock when the
-# bundle is opened. Required.
-#
-# CPACK_BUNDLE_STARTUP_SCRIPT - Path to an executable or script that
-# will be run whenever an end-user double-clicks the generated bundle
-# in the OSX Finder. Optional.
-#
-# The following variables are specific to the graphical installers built
-# on Windows using the Nullsoft Installation System.
-#
-# CPACK_PACKAGE_INSTALL_REGISTRY_KEY - Registry key used when
-# installing this project.
-#
-# 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}
-#
-# CPACK_NSIS_MUI_ICON - The icon file (.ico) for the generated
-# install program.
-#
-# CPACK_NSIS_MUI_UNIICON - The icon file (.ico) for the generated
-# uninstall program.
-#
-# CPACK_PACKAGE_ICON - A branding image that will be displayed inside
-# the installer.
-#
-# CPACK_NSIS_EXTRA_INSTALL_COMMANDS - Extra NSIS commands that will
-# be added to the install Section.
-#
-# CPACK_NSIS_EXTRA_UNINSTALL_COMMANDS - Extra NSIS commands that will
-# be added to the uninstall Section.
-#
-# CPACK_NSIS_COMPRESSOR - The arguments that will be passed to the
-# NSIS SetCompressor command.
-#
-# 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
Re: [CMake] CPack and building installers for sub-projects
2011/4/1 Crni Gorac cgo...@gmail.com: Am working with seemingly not too complicated CMake setup: Have two projects, say Foo and Bar, both dependent from the library libBaz; actually at the beginning there was only Foo project, and now there is Bar project, and common code is refactored into libBaz library. All three of these are into own subdirectories, and I have top-level CMakeLists.txt, that practically contains only references to each of these subdirectories. The libBaz library is built statically and linked this way into both Foo and Bar projects, so it all works in rather simple manner. However, now I'm faced with creating CPack installers for both Foo and Baz - more precisely, there already exists CPack based installer for Foo that also works great, and now I'm looking into building same kind of installer for Bar. I've looked through the list and such, but it seems that it is not possible to have two installers generated from single CMake source tree. So - what would be recommended approach to handle this sort of setup then? Which version of CMake are you using? Which set of CPack generator do you want to work with? Multiple installer on the same tree is not really handled yet unless you use multi-file component-aware installers (ZIP, TGZ and other archive generators, RPM and DEB). You can find more information about that here http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack Now you scheme is more like the feature request described here: http://public.kitware.com/Bug/view.php?id=11808 Have a look at that this thread too: http://www.cmake.org/pipermail/cmake/2011-February/043075.html So basically CPack does not currently support multi-package besides the component things. If you want to join the effort to make it happen please do so by throwing idea (on the mailing list or tracker) and/or patch on the bug tracker. -- 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 and building installers for sub-projects
2011/4/1 Clinton Stimpson clin...@elemtech.com: On Friday, April 01, 2011 12:38:25 pm Eric Noulard wrote: 2011/4/1 Crni Gorac cgo...@gmail.com: Am working with seemingly not too complicated CMake setup: Have two projects, say Foo and Bar, both dependent from the library libBaz; actually at the beginning there was only Foo project, and now there is Bar project, and common code is refactored into libBaz library. All three of these are into own subdirectories, and I have top-level CMakeLists.txt, that practically contains only references to each of these subdirectories. The libBaz library is built statically and linked this way into both Foo and Bar projects, so it all works in rather simple manner. However, now I'm faced with creating CPack installers for both Foo and Baz - more precisely, there already exists CPack based installer for Foo that also works great, and now I'm looking into building same kind of installer for Bar. I've looked through the list and such, but it seems that it is not possible to have two installers generated from single CMake source tree. So - what would be recommended approach to handle this sort of setup then? Which version of CMake are you using? Which set of CPack generator do you want to work with? Multiple installer on the same tree is not really handled yet unless you use multi-file component-aware installers (ZIP, TGZ and other archive generators, RPM and DEB). You can find more information about that here http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack Now you scheme is more like the feature request described here: http://public.kitware.com/Bug/view.php?id=11808 Have a look at that this thread too: http://www.cmake.org/pipermail/cmake/2011-February/043075.html So basically CPack does not currently support multi-package besides the component things. If you want to join the effort to make it happen please do so by throwing idea (on the mailing list or tracker) and/or patch on the bug tracker. I've been doing this with multiple CPack config files. You can either make them by hand or use CPack.cmake multiple times to make those config files for you. Then when you run cpack, you give it the config file to use when making a package. Clinton is right, the hand-crafted multiple CPack config files works. However, keep in mind that CPack.cmake wasn't initially meant to be included several times so it sometimes leads to strange behavior: http://public.kitware.com/Bug/view.php?id=10751 -- 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 and building installers for sub-projects
2011/4/1 Crni Gorac cgo...@gmail.com: Thanks for replies. I'm using CMake 2.8.4, and for this particular project - it's mostly about PackageMaker and NSIS installers (for Mac and Windows, respectively). Also, CPack components stuff is really not usable here, these are two projects with completely separate target audience, but sharing lots of the underlying implementation through this library of common code. Ok I understand. @Clinton: Care to explain the setup you mentioned (with multiple CPack config files) in more details? Also: if CPack not supporting the setup I've described, and if I just split the whole thing into three different projects, what would be the best approach with CMake to assure that common library get built when building any of projects depending on it? Or developer just have to remember to build the library manually first, and then these two projects? May using ExternalProject_Add in each project would do the job. (see cmake --help-module ExternalProject) The main drawback would be the fact that each project will have its own copy of the common lib, or may be they could share it I don't know. Have a look at the mailing list archive about ExternalProject_Add usage I think there have been discussion about that lately and I'm not currently using ExternalProject_Add so I may be mistaken. -- 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.4-1317-ge084018
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 e084018c37ac01458204a1823d303c19a6dd1d52 (commit)
via dd04608132f6580df6fd857d5bfc4f67ad2b0ec3 (commit)
from c9480681012fc7101b34f76c9ff03b14b0ee7137 (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=e084018c37ac01458204a1823d303c19a6dd1d52
commit e084018c37ac01458204a1823d303c19a6dd1d52
Merge: c948068 dd04608
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Fri Apr 1 13:28:11 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Apr 1 13:28:11 2011 -0400
Merge topic 'drag-n-drop-components' into next
dd04608 Fix KWStyle warnings
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dd04608132f6580df6fd857d5bfc4f67ad2b0ec3
commit dd04608132f6580df6fd857d5bfc4f67ad2b0ec3
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Fri Apr 1 19:27:34 2011 +0200
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Fri Apr 1 19:27:34 2011 +0200
Fix KWStyle warnings
diff --git a/Source/CPack/cmCPackDragNDropGenerator.cxx
b/Source/CPack/cmCPackDragNDropGenerator.cxx
index f0763be..83b6b64 100644
--- a/Source/CPack/cmCPackDragNDropGenerator.cxx
+++ b/Source/CPack/cmCPackDragNDropGenerator.cxx
@@ -128,7 +128,9 @@ int cmCPackDragNDropGenerator::PackageFiles()
package_files.push_back(name);
}
std::sort(package_files.begin(), package_files.end());
- package_files.erase(std::unique(package_files.begin(), package_files.end()),
package_files.end());
+ package_files.erase(std::unique(package_files.begin(),
+ package_files.end()),
+ package_files.end());
// loop to create dmg files
@@ -208,10 +210,11 @@ bool
cmCPackDragNDropGenerator::RunCommand(cmOStringStream command,
}
//--
-int cmCPackDragNDropGenerator::CreateDMG(const std::string src_dir, const
std::string output_file)
+int cmCPackDragNDropGenerator::CreateDMG(const std::string src_dir,
+ const std::string output_file)
{
// Get optional arguments ...
- const std::string cpack_package_icon = this-GetOption(CPACK_PACKAGE_ICON)
+ const std::string cpack_package_icon = this-GetOption(CPACK_PACKAGE_ICON)
? this-GetOption(CPACK_PACKAGE_ICON) : ;
const std::string cpack_dmg_volume_name =
@@ -540,15 +543,19 @@ bool
cmCPackDragNDropGenerator::SupportsComponentInstallation() const
return true;
}
-std::string cmCPackDragNDropGenerator::GetComponentInstallDirNameSuffix(const
std::string componentName)
+std::string
+cmCPackDragNDropGenerator::GetComponentInstallDirNameSuffix(
+ const std::string componentName)
{
// we want to group components together that go in the same dmg package
std::string package_file_name = this-GetOption(CPACK_PACKAGE_FILE_NAME);
// we have 3 mutually exclusive modes to work in
// 1. all components in one package
- // 2. each group goes in its own package with left over components in their
own package
- // 3. ignore groups - if grouping is defined, it is ignored and each
component goes in its own package
+ // 2. each group goes in its own package with left over
+ //components in their own package
+ // 3. ignore groups - if grouping is defined, it is ignored
+ //and each component goes in its own package
if(this-componentPackageMethod == ONE_PACKAGE)
{
@@ -559,13 +566,15 @@ std::string
cmCPackDragNDropGenerator::GetComponentInstallDirNameSuffix(const st
{
// We have to find the name of the COMPONENT GROUP
// the current COMPONENT belongs to.
-std::string groupVar = CPACK_COMPONENT_ +
cmSystemTools::UpperCase(componentName) + _GROUP;
+std::string groupVar = CPACK_COMPONENT_ +
+ cmSystemTools::UpperCase(componentName) + _GROUP;
const char* _groupName = GetOption(groupVar.c_str());
if (_groupName)
{
std::string groupName = _groupName;
- groupName = GetComponentPackageFileName(package_file_name, groupName,
true);
+ groupName = GetComponentPackageFileName(package_file_name,
+ groupName, true);
return groupName;
}
}
diff --git a/Source/CPack/cmCPackDragNDropGenerator.h
b/Source/CPack/cmCPackDragNDropGenerator.h
index 3d05f99..808c618 100644
--- a/Source/CPack/cmCPackDragNDropGenerator.h
+++ b/Source/CPack/cmCPackDragNDropGenerator.h
@@ -36,7 +36,8 @@ protected:
bool CopyFile(cmOStringStream source, cmOStringStream target
[Cmake-commits] CMake branch, next, updated. v2.8.4-1322-gba026f8
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 ba026f8e6c14b57dcecddc2108cfa5762e82f1d8 (commit)
via bebefa7d363148191789d6eac63b4164915abdbb (commit)
via 62c279e8805a666534cadad1851acdd603942564 (commit)
via 792341fbad168b38d05fdd534ab414dbae88d5e6 (commit)
via b52eac0ab26309d38d1e0d2ba55406db86980991 (commit)
from e084018c37ac01458204a1823d303c19a6dd1d52 (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=ba026f8e6c14b57dcecddc2108cfa5762e82f1d8
commit ba026f8e6c14b57dcecddc2108cfa5762e82f1d8
Merge: e084018 bebefa7
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Fri Apr 1 13:28:34 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Apr 1 13:28:34 2011 -0400
Merge topic 'cpack-grouping-enum' into next
bebefa7 Fix KWStyle warnings
62c279e Merge branch 'cpack-grouping-enum' of git://cmake.org/stage/cmake
into cpack-grouping-enum
792341f Combine component packaging methods into an enum.
b52eac0 Merge remote branch 'stage/CPack-fix11930-LeftOverComponents' into
cpack-grouping-enum
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bebefa7d363148191789d6eac63b4164915abdbb
commit bebefa7d363148191789d6eac63b4164915abdbb
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Fri Apr 1 19:21:51 2011 +0200
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Fri Apr 1 19:21:51 2011 +0200
Fix KWStyle warnings
diff --git a/Source/CPack/cmCPackArchiveGenerator.cxx
b/Source/CPack/cmCPackArchiveGenerator.cxx
index 5b4625b..0ce5b01 100644
--- a/Source/CPack/cmCPackArchiveGenerator.cxx
+++ b/Source/CPack/cmCPackArchiveGenerator.cxx
@@ -254,7 +254,8 @@ int cmCPackArchiveGenerator::PackageFiles()
// in this case you'll get 1 package for each component.
else
{
- return PackageComponents(componentPackageMethod ==
ONE_PACKAGE_PER_COMPONENT);
+ return PackageComponents(componentPackageMethod ==
+ ONE_PACKAGE_PER_COMPONENT);
}
}
diff --git a/Source/CPack/cmCPackDebGenerator.cxx
b/Source/CPack/cmCPackDebGenerator.cxx
index 582f3e6..5665404 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -250,7 +250,8 @@ int cmCPackDebGenerator::PackageFiles()
// in this case you'll get 1 package for each component.
else
{
- return PackageComponents(componentPackageMethod ==
ONE_PACKAGE_PER_COMPONENT);
+ return PackageComponents(componentPackageMethod ==
+ ONE_PACKAGE_PER_COMPONENT);
}
}
// CASE 3 : NON COMPONENT package.
diff --git a/Source/CPack/cmCPackGenerator.cxx
b/Source/CPack/cmCPackGenerator.cxx
index 6d71ad2..c8a77d1 100644
--- a/Source/CPack/cmCPackGenerator.cxx
+++ b/Source/CPack/cmCPackGenerator.cxx
@@ -1307,10 +1307,10 @@ int cmCPackGenerator::PrepareGroupingKind()
else
{
cmCPackLogger(cmCPackLog::LOG_WARNING, [
- this-Name ]
-requested component grouping type groupingType
-UNKNOWN not in
(ALL_COMPONENTS_IN_ONE,IGNORE,ONE_PER_GROUP)
- std::endl);
+ this-Name ]
+requested component grouping type groupingType
+UNKNOWN not in (ALL_COMPONENTS_IN_ONE,IGNORE,ONE_PER_GROUP)
+ std::endl);
}
}
@@ -1328,10 +1328,10 @@ int cmCPackGenerator::PrepareGroupingKind()
method = ONE_PACKAGE_PER_COMPONENT;
}
cmCPackLogger(cmCPackLog::LOG_WARNING, [
- this-Name ]
-One package per component group requested, but NO component
groups exist:
-Ignoring component group.
- std::endl);
+ this-Name ]
+ One package per component group requested,
+ but NO component groups exist: Ignoring component group.
+ std::endl);
}
// if user specified packaging method, override the default packaging method
@@ -1349,7 +1349,8 @@ int cmCPackGenerator::PrepareGroupingKind()
cmCPackLogger(cmCPackLog::LOG_VERBOSE, [
this-Name ]
- requested component grouping =
method_names[componentPackageMethod]
+ requested component grouping =
+ method_names[componentPackageMethod]
std::endl);
return 1;
diff --git a/Source/CPack/cmCPackGenerator.h b/Source/CPack/cmCPackGenerator.h
index f09c2a7..05d95b8 100644
--- a/Source/CPack/cmCPackGenerator.h
+++ b/Source/CPack/cmCPackGenerator.h
@@ -248,14 +248,16 @@ protected:
ONE_PACKAGE,
/* one package for each
Re: [CMake] Does set_target_properties compile_flags option override include_directories?
2011/3/30 Laura Auton Garcia darklulu+cm...@gmail.com:
Hello all,
The project I am working on uses pkg-config --cflags option to get the
include directories of an external project, and I am trying to add the
output to the compile_flags option used in set_target_properties. As
well as the pkg-config directory, some other flags are specified and
well recognized by the IDE we are building the project for (Visual
Studio).
The code stands as specified here (run_pkgconfig is a macro):
RUN_PKGCONFIG(--cflags ACE result LINKER_FLAGS)
SET(LINKER_FLAGS ${LINKER_FLAGS} -D_CRT_SECURE_NO_WARNINGS
-DACE_AS_STATIC_LIBS)
SET_TARGET_PROPERTIES(
myproject PROPERTIES
COMPILE_FLAGS ${LINKER_FLAGS} )
Did you know that there is a FindPkgConfig.cmake module shipped with CMake?
It may helps you to use PkgConfig.
pkg-config output: -Ic:/ace/ace_wrappers/include
The LINKER_FLAGS variable is well set to with this content:
-Ic:/ace/ace_wrappers/include -D_CRT_SECURE_NO_WARNINGS
-DACE_AS_STATIC_LIBS
Prior to this, some include directories from our own project are added
using include_directories statement.
INCLUDE_DIRECTORIES(
${MYPROJECT_DIR_PATH}
${MYPROJECT_DIR_PATH}/component
${MYPROJECT_DIR_PATH}/error
${MYPROJECT_DIR_PATH}/libraries)
The project is then built successfully
You mean CMake successfully generate the project files right?
You did not manage to build your project outside Visual Studio?
until we open the visual studio
solution generated. After exploring the C/C++ command line properties
of the project, it seems that all the include directories but the one
generated by pkg-config are missing:
/Ic:/ace/ace_wrappers/include /D _CRT_SECURE_NO_WARNINGS /D
ACE_AS_STATIC_LIBS
If I don't add the pkg-config output, then all the directories
included with include-directories appear to be ok:
/IC:/git-projects/myproject /IC:/git-projects/myproject/component
/IC:/git-projects/myproject/error
/IC:/git-projects/myproject/libraries /D _CRT_SECURE_NO_WARNINGS
/D ACE_AS_STATIC_LIBS
So the question is, does compile-flags option override all the
directories included with include_directories? If that's the case,
then how do I add external include directories through pkg-config? I
am pretty new at cmake so any help will be appreciated.
Not it shouldn't.
Which version of CMake are you using?
Is the myproject use in this:
SET_TARGET_PROPERTIES(
myproject PROPERTIES
COMPILE_FLAGS ${LINKER_FLAGS} )
a target from add_executable() or add_library() or is it
the name of the project used in project() statement?
May be you can give us more information about your CMakeLists.txt.
--
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-developers] Bug fix requests for the *next* release of CMake...
2011/3/29 David Cole david.c...@kitware.com: Please discuss issues here as needed, and add notes to existing issues in the bug tracker that you are interested in seeing fixed for 2.8.5 -- we will be looking at the mailing list and activity in the bug tracker to help prioritize the bug fixes that will occur over the next 4 weeks. http://public.kitware.com/Bug/view.php?id=8438 http://public.kitware.com/Bug/view.php?id=10067 http://public.kitware.com/Bug/view.php?id=11656 http://public.kitware.com/Bug/view.php?id=11944 I'll try to work on the last 3 but any help for those will be appreciated. -- 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] memory leaks in cpack
2011/3/20 Bill Hoffman bill.hoff...@kitware.com: On 3/19/2011 6:18 AM, Eric Noulard wrote: I did just pushed the fix to stage. I did change the cmCPackGenerator::ReadListFile return status in order to return false if the list file read ends-up with an ERROR or FATAL_ERROR. I think this is more what you would expect from this method. Currently it was used by CPack RPM, Deb and NSIS generators, RPM and Deb did check the return value whereas NSIS just ignore it :-]. So the change should be safe. Merge topic 'CPackDeb-fixTestCrash' into next 21007f8 CPack fix CPackDeb crash when CPackDeb.cmake ends with a FATAL_ERROR Pushing upstream next To g...@cmake.org:cmake.git Simple install seems to be failing after your changes: http://www.cdash.org/CDash/testDetails.php?test=88344080build=911504 I don't think this is this commit that breaks the test. It may be the merge of the lib64 handling for linux: see branch linux-lib64-handling I'm looking into it now. I do not understand why I do not get e-mail notification of this failure... or may be I'm misreading my mail. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Failure of SimpleInstall
http://www.cdash.org/CDash/testDetails.php?test=88344080build=911504 My [too] naïve patch for automatic lib64 handling on Linux x86_64 has broken [at least] SimpleInstall test. I did push forward the branch in order to avoid automatic handling of lib64 the feature is still there but not automatically set on. Merge topic 'linux-lib64-handling' into next 86e272e Disable automatic lib64 handling (this breaks [at least] SimpleInstall) This should please the tests. May be it wouldn't be wise to merge this as-is to master. I'll work again on it, any help is welcome. The description of the problem is in bug: http://public.kitware.com/Bug/view.php?id=11964 -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] memory leaks in cpack
2011/3/18 Eric Noulard eric.noul...@gmail.com: 2011/3/18 Eric Noulard eric.noul...@gmail.com: 2011/3/18 Bill Hoffman bill.hoff...@kitware.com: On 3/18/2011 3:52 PM, Eric Noulard wrote: Yes but this could be a real symptom a memory corruption. What is the simplest way for me to run the same valgrind test locally? Which ctest one line command, may use for that? That said... The problem seems to be here: dbfilename += this-GetOption(WDIR); My guess is WDIR is returning null from GetOption in this test which causes the crash. Yes you are right about the symptom. The fact is we should never get to this point, because the reading of CPackDeb.cmake have failed. -- stderr='CMake Error at /home/eric/workspace/CMake-gitted/Modules/CPackDeb.cmake:274 (MESSAGE): CPackDeb: Debian package requires a maintainer for a package, set CPACK_PACKAGE_CONTACT or CPACK_DEBIAN_PACKAGE_MAINTAINER Is it the expected behavior to have bool cmCPackGenerator::ReadListFile(const char* moduleName) return true when the processed list file exited because of a: MESSAGE(FATAL_ERROR Whatever) how can I know whether if the processing of a list file encountered a message(ERROR message(FATAL_ERROR or return ? I can add some VAR RUN_OK to the concerned list file (CPackDeb.cmake) in order to know if it was processed without error but I find it awkward. I did just pushed the fix to stage. I did change the cmCPackGenerator::ReadListFile return status in order to return false if the list file read ends-up with an ERROR or FATAL_ERROR. I think this is more what you would expect from this method. Currently it was used by CPack RPM, Deb and NSIS generators, RPM and Deb did check the return value whereas NSIS just ignore it :-]. So the change should be safe. Merge topic 'CPackDeb-fixTestCrash' into next 21007f8 CPack fix CPackDeb crash when CPackDeb.cmake ends with a FATAL_ERROR Pushing upstream next To g...@cmake.org:cmake.git -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, next, updated. v2.8.4-1224-g52682a9
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 52682a93ab3b7b3678968504432258149cea0f67 (commit)
via 21007f898952d74a4db38a9259d946c7d9a06eb3 (commit)
from 6c78fb12aa6b361002131d4590bec7a68992972c (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=52682a93ab3b7b3678968504432258149cea0f67
commit 52682a93ab3b7b3678968504432258149cea0f67
Merge: 6c78fb1 21007f8
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Sat Mar 19 06:14:23 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Mar 19 06:14:23 2011 -0400
Merge topic 'CPackDeb-fixTestCrash' into next
21007f8 CPack fix CPackDeb crash when CPackDeb.cmake ends with a FATAL_ERROR
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=21007f898952d74a4db38a9259d946c7d9a06eb3
commit 21007f898952d74a4db38a9259d946c7d9a06eb3
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Sat Mar 19 11:12:31 2011 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Sat Mar 19 11:12:31 2011 +0100
CPack fix CPackDeb crash when CPackDeb.cmake ends with a FATAL_ERROR
diff --git a/Source/CPack/cmCPackDebGenerator.cxx
b/Source/CPack/cmCPackDebGenerator.cxx
index d3320c0..ca2185c 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -96,6 +96,7 @@ int cmCPackDebGenerator::PackageComponents(bool ignoreGroup)
cmCPackLogger(cmCPackLog::LOG_ERROR,
Error while execution CPackDeb.cmake std::endl);
retval = 0;
+return retval;
}
cmsys::Glob gl;
@@ -105,7 +106,7 @@ int cmCPackDebGenerator::PackageComponents(bool ignoreGroup)
if ( !gl.FindFiles(findExpr) )
{
cmCPackLogger(cmCPackLog::LOG_ERROR,
- Cannot find any files in the installed directory std::endl);
+Cannot find any files in the installed directory std::endl);
return 0;
}
packageFiles = gl.GetFiles();
@@ -152,8 +153,8 @@ int cmCPackDebGenerator::PackageComponents(bool ignoreGroup)
cmCPackLogger(cmCPackLog::LOG_ERROR,
Error while execution CPackDeb.cmake std::endl);
retval = 0;
+return retval;
}
-
cmsys::Glob gl;
std::string findExpr(this-GetOption(WDIR));
findExpr += /*;
@@ -230,6 +231,7 @@ int cmCPackDebGenerator::PackageComponentsAllInOne(bool
allComponent)
cmCPackLogger(cmCPackLog::LOG_ERROR,
Error while execution CPackDeb.cmake std::endl);
retval = 0;
+return retval;
}
cmsys::Glob gl;
@@ -288,8 +290,11 @@ int cmCPackDebGenerator::PackageFiles()
Error while execution CPackDeb.cmake std::endl);
retval = 0;
}
-packageFiles = files;
-return createDeb();
+else
+ {
+ packageFiles = files;
+ return createDeb();
+ }
}
return retval;
}
diff --git a/Source/CPack/cmCPackGenerator.cxx
b/Source/CPack/cmCPackGenerator.cxx
index 5f314c6..c343acf 100644
--- a/Source/CPack/cmCPackGenerator.cxx
+++ b/Source/CPack/cmCPackGenerator.cxx
@@ -885,8 +885,12 @@ int
cmCPackGenerator::InstallProjectViaInstallCMakeProjects(
//--
bool cmCPackGenerator::ReadListFile(const char* moduleName)
{
+ bool retval;
std::string fullPath = this-MakefileMap-GetModulesFile(moduleName);
- return this-MakefileMap-ReadListFile(0, fullPath.c_str());
+ retval = this-MakefileMap-ReadListFile(0, fullPath.c_str());
+ // include FATAL_ERROR and ERROR in the return status
+ retval = retval (! cmSystemTools::GetErrorOccuredFlag());
+ return retval;
}
//--
---
Summary of changes:
Source/CPack/cmCPackDebGenerator.cxx | 13 +
Source/CPack/cmCPackGenerator.cxx|6 +-
2 files changed, 14 insertions(+), 5 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] memory leaks in cpack
2011/3/18 Bill Hoffman bill.hoff...@kitware.com: The commits that went in this day: http://www.cdash.org/CDash/viewChanges.php?project=CMakedate=2011-03-12 Caused memory leaks to show up here: http://www.cdash.org/CDash/viewDynamicAnalysisFile.php?id=1142597 May be for me. I'll have a look tonight. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] memory leaks in cpack
2011/3/18 Bill Hoffman bill.hoff...@kitware.com: On 3/18/2011 11:00 AM, Eric Noulard wrote: 2011/3/18 Bill Hoffmanbill.hoff...@kitware.com: The commits that went in this day: http://www.cdash.org/CDash/viewChanges.php?project=CMakedate=2011-03-12 Caused memory leaks to show up here: http://www.cdash.org/CDash/viewDynamicAnalysisFile.php?id=1142597 May be for me. I'll have a look tonight. With a closer look, it seems that it is actually crashing under valgrind: Yes but this could be a real symptom a memory corruption. What is the simplest way for me to run the same valgrind test locally? Which ctest one line command, may use for that? ==21354== ==21354== Invalid read of size 1 ==21354== at 0x4C270C2: strlen (mc_replace_strmem.c:242) ==21354== by 0x530886B: std::string::operator+=(char const*) (in /usr/lib/libstdc++.so.6.0.10) ==21354== by 0x613511: cmCPackDebGenerator::createDeb() (cmCPackDebGenerator.cxx:303) ==21354== by 0x617227: cmCPackDebGenerator::PackageFiles() (cmCPackDebGenerator.cxx:292) ==21354== by 0x5FC1EC: cmCPackGenerator::DoPackage() (cmCPackGenerator.cxx:1012) ==21354== by 0x5EA0CE: main (cpack.cxx:430) ==21354== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==21354== ==21354== Process terminating with default action of signal 11 (SIGSEGV) ==21354== Access not within mapped region at address 0x0 ==21354== at 0x4C270C2: strlen (mc_replace_strmem.c:242) ==21354== by 0x530886B: std::string::operator+=(char const*) (in /usr/lib/libstdc++.so.6.0.10) ==21354== by 0x613511: cmCPackDebGenerator::createDeb() (cmCPackDebGenerator.cxx:303) ==21354== by 0x617227: cmCPackDebGenerator::PackageFiles() (cmCPackDebGenerator.cxx:292) ==21354== by 0x5FC1EC: cmCPackGenerator::DoPackage() (cmCPackGenerator.cxx:1012) ==21354== by 0x5EA0CE: main (cpack.cxx:430) ==21354== If you believe this happened as a result of a stack overflow in your ==21354== program's main thread (unlikely but possible), you can try to increase ==21354== the size of the main thread stack using the --main-stacksize= flag. ==21354== The main thread stack size used in this run was 8388608. ==21354== -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] memory leaks in cpack
2011/3/18 Bill Hoffman bill.hoff...@kitware.com: On 3/18/2011 3:52 PM, Eric Noulard wrote: Yes but this could be a real symptom a memory corruption. What is the simplest way for me to run the same valgrind test locally? Which ctest one line command, may use for that? That said... The problem seems to be here: dbfilename += this-GetOption(WDIR); My guess is WDIR is returning null from GetOption in this test which causes the crash. Yes you are right about the symptom. The fact is we should never get to this point, because the reading of CPackDeb.cmake have failed. -- stderr='CMake Error at /home/eric/workspace/CMake-gitted/Modules/CPackDeb.cmake:274 (MESSAGE): CPackDeb: Debian package requires a maintainer for a package, set CPACK_PACKAGE_CONTACT or CPACK_DEBIAN_PACKAGE_MAINTAINER The CPackTestAllGenerators was probably failing to run CPackDeb since the beginning (of the existence of CPackDeb) but without crash :-] I'll fix it, not sure I have time to do it tonight but tomorrow for sure. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] memory leaks in cpack
2011/3/18 Eric Noulard eric.noul...@gmail.com: 2011/3/18 Bill Hoffman bill.hoff...@kitware.com: On 3/18/2011 3:52 PM, Eric Noulard wrote: Yes but this could be a real symptom a memory corruption. What is the simplest way for me to run the same valgrind test locally? Which ctest one line command, may use for that? That said... The problem seems to be here: dbfilename += this-GetOption(WDIR); My guess is WDIR is returning null from GetOption in this test which causes the crash. Yes you are right about the symptom. The fact is we should never get to this point, because the reading of CPackDeb.cmake have failed. -- stderr='CMake Error at /home/eric/workspace/CMake-gitted/Modules/CPackDeb.cmake:274 (MESSAGE): CPackDeb: Debian package requires a maintainer for a package, set CPACK_PACKAGE_CONTACT or CPACK_DEBIAN_PACKAGE_MAINTAINER Is it the expected behavior to have bool cmCPackGenerator::ReadListFile(const char* moduleName) return true when the processed list file exited because of a: MESSAGE(FATAL_ERROR Whatever) how can I know whether if the processing of a list file encountered a message(ERROR message(FATAL_ERROR or return ? I can add some VAR RUN_OK to the concerned list file (CPackDeb.cmake) in order to know if it was processed without error but I find it awkward. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] set_target_properties to target openmp flag on an executable
2011/3/18 Caner Candan ca...@candan.fr: Hi all, Since I have several targets to compile, I was looking for a way to set some specific flags to one target among all others. In my example I would like to set the openmp flag to the target test and I got an error with the code below: -- PROJECT(test CXX) ADD_EXECUTABLE(test test.cpp) SET_TARGET_PROPERTIES(test PROPERTIES COMPILE_FLAGS -fopenmp) -- Error: -- [100%] Building CXX object CMakeFiles/test.dir/test.cpp.o Linking CXX executable test CMakeFiles/test.dir/test.cpp.o: In function `main': test.cpp:(.text+0x29): undefined reference to `GOMP_parallel_start' test.cpp:(.text+0x3a): undefined reference to `GOMP_parallel_end' collect2: ld returned 1 exit status make[2]: *** [test] Error 1 make[1]: *** [CMakeFiles/test.dir/all] Error 2 Don't you need the same flags for linking? see the LINK_FLAGS property. -- 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] Deb Package messages only if deb is available
2011/3/17 Dixon, Shane shane.di...@atmel.com:
I want to add some messages at the end of cmake that display all the
DEB-related variables and what they’re set to. I’d prefer to now shows
these when building on windows where DEB isn’t available. Is there
something like
If(DEBIAN_FOUND)
This is not currently possible because
[un]fortunately CMake is not aware of CPack generator existence :-]
that I can use to determine if the deb package builder will be used? Should
I scan CPACK_GENERATORS for ‘DEB”?
You cannot scan that either, because this var is set to a default value by CMake
and it may be overwritten by the user.
What’s the best way to do this?
You can try the attached cmake script which launch cpack --help and collect
available generators from CPack itself, if it is found then
CPACK_GEN_FOUND is set to true.
try
include(AvailableCPackGenerators.cmake)
then
if (CPACK_DEB_FOUND)
or
if (CPACK_TGZ_FOUND)
etc...
should.
If you find the feature is worth to be included in CMake mainstream
file a feature request and attach the file (or a modified version if
you can do it in a better way).
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
find_program(CPACK_PROGRAM NAMES cpack)
if (CPACK_PROGRAM)
# Analyze 'cpack --help' output for list of available generators:
#
execute_process(COMMAND ${CPACK_PROGRAM} --help
RESULT_VARIABLE result
OUTPUT_VARIABLE stdout
ERROR_VARIABLE stderr)
string(REPLACE ; \\; stdout ${stdout})
string(REPLACE \n E; stdout ${stdout})
set(collecting 0)
set(generators)
foreach(eline ${stdout})
string(REGEX REPLACE ^(.*)E$ \\1 line ${eline})
if(collecting AND NOT line STREQUAL )
string(REGEX REPLACE ^ ([^ ]+) += (.*)$ \\1 gen ${line})
string(REGEX REPLACE ^ ([^ ]+) += (.*)$ \\2 doc ${line})
list(APPEND generators ${gen})
endif()
if(line STREQUAL Generators)
set(collecting 1)
endif()
endforeach()
set(possiblegen DEB;NSIS;RPM;STGZ;TBZ2;TGZ;TZ;ZIP;DMG;CygwinBinary;CygwinSource;DragNDrop;Bundle;PackageMaker;OSXX11)
foreach(gen ${possiblegen})
list(FIND generators ${gen} IDX)
if(IDX EQUAL -1)
set(CPACK_${gen}_FOUND FALSE)
else()
set(CPACK_${gen}_FOUND TRUE)
endif()
endforeach()
endif(CPACK_PROGRAM)___
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] Asm support
2011/3/15 Robert Bielik robert.bie...@xponaut.se: Robert Bielik skrev 2011-03-15 08:59: Using 2.8.4, I'm trying to add an assembler file with cmake (64 bit VS2008 build), but I'm at a loss, I tried: There has been a lot of work done (Alex and Brad I think) in topic ReworkedAsmSupport it has been merged to master last week. May be you can try a nightly build http://www.cmake.org/files/vCVS/cmake-2.8.4.20110314-gf52ca-win32-x86.exe in order to see if this makes your case work. -- 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] Configuring external projects with cmake for a nonexistent install directory which is not configure-time writable
2011/3/14 The Wanderer wande...@fastmail.fm: (I apologize for setting the Reply-To header, but I know of no other way to prevent my being sent an additional off-list copy of any reply even when there is no specific need to draw my attention to that reply.) I am running cmake 2.8.2, installed via Debian testing. No more recent version appears to be available via Debian. Yes there is 2.84 in SID: http://packages.debian.org/sid/cmake I am attempting to compile a project which has recently switched to cmake after a long time spent on autotools. The project uses, and includes the source to, at least two other projects, which it treats as external projects. The project explicitly requires (and enforces) an out-of-tree build. I habitually install each new version of this particular project under its own brand-new prefix, to more easily retain previous versions for fallback if necessary. As a consequence, the target install prefix does not exist at the beginning of the build process. I configure and compile as an ordinary user, which does not have write access to the install location. It has long been my understanding that this is ordinarily considered good practice. I am attempting to configure with the command line cmake /path/to/source -DDEBUG=1 -DPREFIX=/path/to/nonexistent/install/dir With this command, the configure process fails. The error message is: We do not have enough information about your CMakeLists.txt. ExternalProject_Add do have some options like: PREFIX TMP_DIR DOWNLOAD_DIR etc... which may be different from the install prefix of your project. So I'm not using ExternalProject_Add myself but I suspect you are making assumption on when action take place which may be different from the module designers. I let ExternalProject_Add users comment that part. -- 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] Compiling multiple files, only takes the first one
2011/3/14 Enrique Izaguirre enrique.izagui...@gmail.com: Hello friends, I have a problem when I try to compile several files, for some reason it takes only the first of the list to build it. It displays a few warnings and at the end the following error: make[2]: *** [CMakeFiles/omap.dir/host/fastboot.c.o] Error 1 make[2]: Leaving directory `/home/x0148488/omapflash/cmake_build' make[1]: *** [CMakeFiles/omap.dir/all] Error 2 make[1]: Leaving directory `/home/x0148488/omapflash/cmake_build' make: *** [all] Error 2 Even before doing the add_executable ( ), I display first the variable that contains the list of files to build, and it indeed has all the files to compile; somehow it only compiles the first one and then leave. Running make with the VERVOSE=1 I can see the command, and it has only the first file of the list; so CMake is generating the command wrong. Can you explain why only one file is compiled and not the entire list? Looks like some sort of typo. Could you give us the CMakeLists.txt extract with the offending commands? At least the source file list definition and the add_executable statement. and some more info: - platform/host/compiler - cmake version - native or cross-compiling -- 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.4-1165-gf3487ce
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 f3487ceddc2e009f28ad7e8a51a9e2f160250b4e (commit)
via ade04de7ecc04e2b3e336e32789c8198b38ca986 (commit)
from c05ee313b130d3574ddf1277fa43bb694237c234 (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=f3487ceddc2e009f28ad7e8a51a9e2f160250b4e
commit f3487ceddc2e009f28ad7e8a51a9e2f160250b4e
Merge: c05ee31 ade04de
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Mon Mar 14 16:13:02 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Mar 14 16:13:02 2011 -0400
Merge topic 'CPackRPM-TestWithMoreTraces' into next
ade04de Remove debbuging typo
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ade04de7ecc04e2b3e336e32789c8198b38ca986
commit ade04de7ecc04e2b3e336e32789c8198b38ca986
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Mon Mar 14 21:12:26 2011 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Mon Mar 14 21:12:26 2011 +0100
Remove debbuging typo
diff --git a/Tests/CPackComponentsForAll/SystemSpecificInformations.cmake
b/Tests/CPackComponentsForAll/SystemSpecificInformations.cmake
index 942cb2b..8d11400 100644
--- a/Tests/CPackComponentsForAll/SystemSpecificInformations.cmake
+++ b/Tests/CPackComponentsForAll/SystemSpecificInformations.cmake
@@ -88,7 +88,7 @@ if(UNIX)
set(SPECIFIC_SYSTEM_VERSION_NAME ${CMAKE_SYSTEM_NAME})
set(SPECIFIC_SYSTEM_PREFERED_CPACK_GENERATOR TGZ)
find_program(LSB_RELEASE_EXECUTABLE lsb_release)
-if(LSB_RELEASE_EXECUTABLEF)
+if(LSB_RELEASE_EXECUTABLE)
execute_process(COMMAND ${LSB_RELEASE_EXECUTABLE} -i
OUTPUT_VARIABLE _TMP_LSB_RELEASE_OUTPUT
ERROR_QUIET
@@ -145,7 +145,7 @@ if(UNIX)
endif(LINUX_ISSUE MATCHES SUSE)
# Mandriva case
# TODO
-endif(LSB_RELEASE_EXECUTABLEF)
+endif(LSB_RELEASE_EXECUTABLE)
# Now mangle some names
set(LINUX_NAME ${DISTRO_ID}_${DISTRO_RELEASE})
if(DISTRO_ID MATCHES Fedora|Mandriva|SUSE|OpenSUSE)
@@ -161,4 +161,4 @@ if(UNIX)
set(SPECIFIC_SYSTEM_VERSION_NAME
${SPECIFIC_SYSTEM_VERSION_NAME}-${CMAKE_SYSTEM_PROCESSOR})
set(SPECIFIC_COMPILER_NAME )
-endif(UNIX)
\ No newline at end of file
+endif(UNIX)
---
Summary of changes:
.../SystemSpecificInformations.cmake |6 +++---
1 files changed, 3 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] Help requested for running CPackRPM tests on SLES 10 machine
2011/3/13 Eric Noulard eric.noul...@gmail.com: I'll try to [blindly] fix this with a SUSE specific test *in the test itself* and not in CPack RPM. I did push forward the stage CPackRPM-TestWithMoreTraces and merge it to next. This last commit should make the CPackRPM test work on SUSE 64bits. Would you be able to re-try for me using next? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Help requested for running CPackRPM tests on SLES 10 machine
2011/3/13 Rolf Eike Beer e...@sf-mail.de:
Am Sonntag 13 März 2011, 21:19:41 schrieb Eric Noulard:
2011/3/13 Eric Noulard eric.noul...@gmail.com:
I'll try to [blindly] fix this with a SUSE specific test *in the test
itself* and not in CPack RPM.
I did push forward the stage CPackRPM-TestWithMoreTraces and merge it to
next. This last commit should make the CPackRPM test work on SUSE 64bits.
Would you be able to re-try for me using next?
http://www.cdash.org/CDash/buildSummary.php?buildid=902959
Ok this is re-assuring.
I hope that there will be a way to detect and honor this lib/lib64 policy
thing on a general base and to handle that properly in normal installs and
RPMs.
The thing is, I'll have to check how the different distributions
handle this case,
for example on my Debian 64 bits box I have:
$ ls -ld /usr/lib*
drwxr-xr-x 311 root root 151552 12 mars 23:30 /usr/lib
drwxr-xr-x 33 root root 45056 29 janv. 10:18 /usr/lib32
lrwxrwxrwx 1 root root 3 31 déc. 2008 /usr/lib64 - lib
drwxr-xr-x 3 root root 4096 1 janv. 2009 /usr/libexec
As you can see /usr/lib is the 'native' lib dir, with lib64 being a
link to this.
Then lib32 is the 32bits 'non-native' one.
This layout seems reasonable, I'll check on Fedora 64 or other RPM based
distros during this week.
Now I may teach CPackRPM to detect if it is running on Fedora or SUSE
or Mandriva etc..
and do some nasty things like renaming lib destination into lib64
if we are packaging a 64 bit package but I currently find it weird.
The rpm installer (the rpm command) or packager (rpmbuild) perfectly knows
that we are building a natively 64 bits RPM package it's even written in the RPM
using Architecture field so if he wants to enforce to put 64 bits
libs into lib64
he may do it by itself and not asking the packager to do it.
Currently I would say that rpm build policy on SUSE 64 bits
is the culprit not CPackRPM (which is simply calling RPM build).
However, I'll investage further because up to now I did never face
such 32/64 bits issue
even if I use natively 64 bits linux systems since at least 5 years...
Slackware seems to be using lib${LIBDIRSUFFIX}
http://www.mail-archive.com/slackbuilds-users@slackbuilds.org/msg01569.html
Others (like at least Fedora, RedHat, Mandriva)
seems to be using builtin RPM %_libdir macros.
The thing is currently with cpack the user chose the library/runtime
destination
so if he chose 'lib' shall we go with lib64 should be safe but
if the installation prefix is not '/usr' but '/opt/' or '/anywhere/you/want'
shall we do the lib--lib64 automatic renaming.
Any insight or reference about this 32/64 bits lib mixup is welcomed.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] How to set different install scripts into different component RPMs
2011/3/13 徐亮 lxu4...@gmail.com: I have a big project that include lib1, lib2, app1, app2. Before CPack 2.8.4, app1 and app2 have standalone CMakeLists.txt and pack RPM independently. So I can set different pre/post install scripts to these RPMs. In CPack 2.8.4, I can generate two component RPM for app1 and app2. But how to set different pre/post install scripts to components. I'm afraid currently you can't. Currently every RPM specific options CPACK_RPM_xxx are applied globally i.e. to each componentized RPM. I'm not sure I want to do that but may we can either make each CPACK_RPM_xxx a list of couple in order to be able to select component-specific values, the other option would be to define CPACK_RPM_COMPNAME_xxx var for each COMPONENT. Would you be kind enough to file a feature request: http://public.kitware.com/Bug/bug_report_page.php describing the need. If you can provided a small test case it would be even better. In any case currently you cannot do that so I'm afraid you'll have to use monolithic packaging as you did before 2.8.4, unless you can make your pre/post install scripts generic. -- 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.4-1157-gce41ad3
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 ce41ad395bf19d0568079be2cf60b24713001399 (commit)
via a20102862629db49980b52f5088eae79d961237a (commit)
from d1c5b349a4120546a3be089a8d5a93914abb66c9 (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=ce41ad395bf19d0568079be2cf60b24713001399
commit ce41ad395bf19d0568079be2cf60b24713001399
Merge: d1c5b34 a201028
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Sun Mar 13 16:17:02 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sun Mar 13 16:17:02 2011 -0400
Merge topic 'CPackRPM-TestWithMoreTraces' into next
a201028 CPack try to please SUSE 64 bits and install lib in lib64 and not
lib.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a20102862629db49980b52f5088eae79d961237a
commit a20102862629db49980b52f5088eae79d961237a
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Sun Mar 13 21:15:49 2011 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Sun Mar 13 21:15:49 2011 +0100
CPack try to please SUSE 64 bits and install lib in lib64 and not lib.
diff --git a/Tests/CPackComponentsForAll/CMakeLists.txt
b/Tests/CPackComponentsForAll/CMakeLists.txt
index bcec509..ce12b3b 100644
--- a/Tests/CPackComponentsForAll/CMakeLists.txt
+++ b/Tests/CPackComponentsForAll/CMakeLists.txt
@@ -10,6 +10,14 @@
cmake_minimum_required(VERSION 2.8.3.20101130 FATAL_ERROR)
project(CPackComponentsForAll)
+set(LIBDEST lib)
+include(${CMAKE_SOURCE_DIR}/SystemSpecificInformations.cmake)
+if(DISTRO_ID MATCHES SUSE)
+ if(${CMAKE_SIZEOF_VOID_P} EQUAL 8)
+ set(LIBDEST lib64)
+ endif(${CMAKE_SIZEOF_VOID_P} EQUAL 8)
+endif(DISTRO_ID MATCHES SUSE)
+
# Create the mylib library
add_library(mylib mylib.cpp)
@@ -27,7 +35,7 @@ target_link_libraries(mylibapp2 mylib)
# be used to create the installation components.
install(TARGETS mylib
ARCHIVE
- DESTINATION lib
+ DESTINATION ${LIBDEST}
COMPONENT libraries)
install(TARGETS mylibapp
RUNTIME
diff --git a/Tests/CPackComponentsForAll/SystemSpecificInformations.cmake
b/Tests/CPackComponentsForAll/SystemSpecificInformations.cmake
new file mode 100644
index 000..942cb2b
--- /dev/null
+++ b/Tests/CPackComponentsForAll/SystemSpecificInformations.cmake
@@ -0,0 +1,164 @@
+
+# define a set of string with may-be useful readable name
+# this file is meant to be included in a CMakeLists.txt
+# not as a standalone CMake script
+set(SPECIFIC_COMPILER_NAME )
+set(SPECIFIC_SYSTEM_VERSION_NAME )
+set(SPECIFIC_SYSTEM_PREFERED_CPACK_GENERATOR )
+
+# In the WIN32 case try to guess a readable system name
+if(WIN32)
+ set(SPECIFIC_SYSTEM_PREFERED_PACKAGE NSIS)
+ # information taken from
+ # http://www.codeguru.com/cpp/w-p/system/systeminformation/article.php/c8973/
+ # Win9x series
+ if(CMAKE_SYSTEM_VERSION MATCHES 4.0)
+set(SPECIFIC_SYSTEM_VERSION_NAME Win95)
+ endif(CMAKE_SYSTEM_VERSION MATCHES 4.0)
+ if(CMAKE_SYSTEM_VERSION MATCHES 4.10)
+set(SPECIFIC_SYSTEM_VERSION_NAME Win98)
+ endif(CMAKE_SYSTEM_VERSION MATCHES 4.10)
+ if(CMAKE_SYSTEM_VERSION MATCHES 4.90)
+set(SPECIFIC_SYSTEM_VERSION_NAME WinME)
+ endif(CMAKE_SYSTEM_VERSION MATCHES 4.90)
+
+ # WinNTyyy series
+ if(CMAKE_SYSTEM_VERSION MATCHES 3.0)
+set(SPECIFIC_SYSTEM_VERSION_NAME WinNT351)
+ endif(CMAKE_SYSTEM_VERSION MATCHES 3.0)
+ if(CMAKE_SYSTEM_VERSION MATCHES 4.1)
+set(SPECIFIC_SYSTEM_VERSION_NAME WinNT4)
+ endif(CMAKE_SYSTEM_VERSION MATCHES 4.1)
+
+ # Win2000/XP series
+ if(CMAKE_SYSTEM_VERSION MATCHES 5.0)
+set(SPECIFIC_SYSTEM_VERSION_NAME Win2000)
+ endif(CMAKE_SYSTEM_VERSION MATCHES 5.0)
+ if(CMAKE_SYSTEM_VERSION MATCHES 5.1)
+set(SPECIFIC_SYSTEM_VERSION_NAME WinXP)
+ endif(CMAKE_SYSTEM_VERSION MATCHES 5.1)
+ if(CMAKE_SYSTEM_VERSION MATCHES 5.2)
+set(SPECIFIC_SYSTEM_VERSION_NAME Win2003)
+ endif(CMAKE_SYSTEM_VERSION MATCHES 5.2)
+
+ # WinVista/7 series
+ if(CMAKE_SYSTEM_VERSION MATCHES 6.0)
+set(SPECIFIC_SYSTEM_VERSION_NAME WinVISTA)
+ endif(CMAKE_SYSTEM_VERSION MATCHES 6.0)
+ if(CMAKE_SYSTEM_VERSION MATCHES 6.1)
+set(SPECIFIC_SYSTEM_VERSION_NAME Win7)
+ endif(CMAKE_SYSTEM_VERSION MATCHES 6.1)
+
+ # Compilers
+ # taken from http://predef.sourceforge.net/precomp.html#sec34
+ if(MSVC)
+set(SPECIFIC_COMPILER_NAME MSVC-Unknown-${MSVC_VERSION})
+if(MSVC_VERSION EQUAL 1200)
+ set(SPECIFIC_COMPILER_NAME MSVC-6.0)
+endif(MSVC_VERSION EQUAL 1200)
+if(MSVC_VERSION EQUAL 1300)
+ set(SPECIFIC_COMPILER_NAME MSVC-7.0)
+endif(MSVC_VERSION EQUAL 1300)
+if(MSVC_VERSION EQUAL 1310)
+ set
Re: [cmake-developers] Help requested for running CPackRPM tests on SLES 10 machine
2011/3/11 Eric Noulard eric.noul...@gmail.com: 2011/3/11 Rolf Eike Beer e...@sf-mail.de: I can check on an openSUSE 11.0 tomorrow. http://www.cdash.org/CDash/viewTest.php?onlyfailedbuildid=900169 If you want some quick changes come to #cmake on Freenode where I usually hang around (Dakon). Thank you Eike, I'll may try that later today. From the Dashboard it seems that you did run the test on master branch I would rather be interested in seeing the result on next branch. That said, since the bug seems to be there on OpenSUSE 11.0 I'll try to setup a VM myself. I did try with OpenSUSE 11.2 and it's working well. I tried 11.2 because didn't find any OpenSUSE 11.0 image/DVD on opensuse.org... Seems that the issue really needs 11.0 or earlier. I'll try to seek for an Open SUSE 11.0 iso image somewhere... In the meantime if you can re-run the test on next instead of master it would be helpfull. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Help requested for running CPackRPM tests on SLES 10 machine
2011/3/12 Rolf Eike Beer e...@sf-mail.de: Am Samstag 12 März 2011, 14:21:33 schrieb Eric Noulard: 2011/3/11 Eric Noulard eric.noul...@gmail.com: 2011/3/11 Rolf Eike Beer e...@sf-mail.de: I can check on an openSUSE 11.0 tomorrow. http://www.cdash.org/CDash/viewTest.php?onlyfailedbuildid=900169 If you want some quick changes come to #cmake on Freenode where I usually hang around (Dakon). Thank you Eike, I'll may try that later today. From the Dashboard it seems that you did run the test on master branch I would rather be interested in seeing the result on next branch. That said, since the bug seems to be there on OpenSUSE 11.0 I'll try to setup a VM myself. I did try with OpenSUSE 11.2 and it's working well. I tried 11.2 because didn't find any OpenSUSE 11.0 image/DVD on opensuse.org... Seems that the issue really needs 11.0 or earlier. I'll try to seek for an Open SUSE 11.0 iso image somewhere... ftp://ftp5.gwdg.de/pub/opensuse/discontinued/distribution Thank you, I did have a hard time to find a mirror with oldish open SUSE images... In the meantime if you can re-run the test on next instead of master it would be helpfull. Will try. Ok thanks but don't waste too much of your time for that. Now that I have an iso image url, I'll try myself to reproduce the error in a VM as soon as I have the image on my disk. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Help requested for running CPackRPM tests on SLES 10 machine
2011/3/11 Rolf Eike Beer e...@sf-mail.de: NCISome recently activayed CPackRPM tests are failing on a SLES 10 x86_64 machine: http://www.cdash.org/CDash/viewTest.php?onlyfailedbuildid=898471 would anybody here be able to run this test on a similar host using 'next' branch for me? I do not currently have access to such system and I'm unable to reproduce the problem... SLES 10 is a relatively old release (2006) of SUSE Linux Enterprise Server. May be a SUSE 10.x or OpenSUSE 10.2 system could be OK too. I can check on an openSUSE 11.0 tomorrow. http://www.cdash.org/CDash/viewTest.php?onlyfailedbuildid=900169 If you want some quick changes come to #cmake on Freenode where I usually hang around (Dakon). Thank you Eike, I'll may try that later today. From the Dashboard it seems that you did run the test on master branch I would rather be interested in seeing the result on next branch. That said, since the bug seems to be there on OpenSUSE 11.0 I'll try to setup a VM myself. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] CMake.CheckSourceTree Failed?
My Last commit seems to have broken the CMake.CheckSourceTree test. However I do not understand the issue shown here: http://www.cdash.org/CDash/testDetails.php?test=87068196build=898608 What's wrong with my commit? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Help requested for running CPackRPM tests on SLES 10 machine
Hi All, NCISome recently activayed CPackRPM tests are failing on a SLES 10 x86_64 machine: http://www.cdash.org/CDash/viewTest.php?onlyfailedbuildid=898471 would anybody here be able to run this test on a similar host using 'next' branch for me? I do not currently have access to such system and I'm unable to reproduce the problem... SLES 10 is a relatively old release (2006) of SUSE Linux Enterprise Server. May be a SUSE 10.x or OpenSUSE 10.2 system could be OK too. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] newbie q - where do I put what in which CMakeLists file? out of source build
2011/3/10 David Cole david.c...@kitware.com:
Well if the build directory is *in* the source directory, then make
package_source *should* include it.
This is not a problem, but the expected behavior.
If you don't want the build tree in the source tree, then don't put it
there.
Or do include ${CMAKE_BINARY_DIR}/* in CPACK_SOURCE_IGNORE_FILES
Note that there is a special case where excluding CMAKE_BINARY_DIR is annoying,
this is when you do in-source build, i.e.
if CMAKE_BINARY_DIR == CMAKE_SOURCE_DIR.
What I usually do is:
IF (${CMAKE_BINARY_DIR} STREQUAL ${CMAKE_SOURCE_DIR})
SET(CPACK_SOURCE_IGNORE_FILES usual list)
ELSE(${CMAKE_BINARY_DIR} STREQUAL ${CMAKE_SOURCE_DIR})
SET(CPACK_SOURCE_IGNORE_FILES usuallist;${CMAKE_BINARY_DIR}/*)
ENDIF (${CMAKE_BINARY_DIR} STREQUAL ${CMAKE_SOURCE_DIR})
--
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] infinite loop when using function overriding
2011/3/9 David Cole david.c...@kitware.com:
This is a question for folks at Stack Overflow. Literally. :-)
I'm assuming you mean _add_library(${name} ${ARGN})?
The override and call original with a leading _ is probably not well
documented anywhere. While it's useful on occasion, we do not recommend
using it if there's an alternate technique that you can use.
Besides from the list, where is documented the fact that
you can override builtin CMake macro ? (like add_executable)
Would be worth adding this fact to the doc of function and/or macro.
I may propose a patch myself but I'm not sure to fully know how
it is supposed to work (by design).
--
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 and RPM packages
2011/3/8 Laszlo Papp djsz...@archlinux.us:
I could not still build cmake.. But I did this modification
locally you suggested and that is the output:
CPack: Create package using RPM
CPack: Install projects
CPack: - Run preinstall target for: Gluon
CPack: - Install project: Gluon
CPack: Create package
CPackRPM: Will use GENERATED spec file:
/home/meego/gluon/build/_CPack_Packages/Linux/RPM/SPECS/gluon.spec
CPack: - package: /home/meego/gluon/build/Gluon-0.71.0.rpm.rpm generated.
the double .rpm.rpm extension seems awkward but may be this is a
copy/paste typo?
You can check the content of the generated rpm file using:
$ rpm -qpl /home/meego/gluon/build/Gluon-0.71.0.rpm
and get the meta-info with:
$ rpm -qpi /home/meego/gluon/build/Gluon-0.71.0.rpm
It was a quite slow process after the spec file generation, but it
seems to work. I do really hope someone can fix the arm - qemu - cmake
thread hanging issues otherwise no idea how to get this functionality
working officially...
I'm glad it's working now.
Ok now that you can build an rpm,
I think you should really look at the way you install files.
in
https://projects.kde.org/projects/playground/games/gluon/repository/revisions/master/entry/core/CMakeLists.txt
you define:
set(INCLUDE_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/include
CACHE PATH The subdirectory relative to the install prefix where
header files will be installed.)
set(LIB_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/lib${LIB_SUFFIX}
CACHE PATH The subdirectory relative to the install prefix where
libraries will be installed.)
set(SHARE_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/share
CACHE PATH The subdiractory relative to the install prefix where
data and other files will be installed.)
and then
install(TARGETS GluonCore RUNTIME DESTINATION bin LIBRARY DESTINATION
${LIB_INSTALL_DIR} ARCHIVE DESTINATION ${LIB_INSTALL_DIR} FRAMEWORK
DESTINATION ${LIB_INSTALL_DIR})
so you use absolute destination install path.
If you do so, CPackRPM will automatically set those files as %config
files, i.e. files that shouldn't be replaced blindly during an update
or suppressed
when the rpm is removed. (%config are files typically installed in /etc/)
You may end-up with an rpm which does not behave as usual.
What you [should|could] do to avoid this behavior is:
set(INCLUDE_INSTALL_DIR include CACHE PATH The
subdirectory relative to the install prefix where header files will be
installed.)
set(LIB_INSTALL_DIR lib${LIB_SUFFIX}CACHE PATH The
subdirectory relative to the install prefix where libraries will be
installed.)
set(SHARE_INSTALL_DIR share CACHE PATH The
subdiractory relative to the install prefix where data and other files
will be installed.)
that what _INSTALL_DIR will become relative and CPackRPM should
behave more the way you expect it should.
In order to be consistent with your DEB packaging you may tell
CPackRPM the dependencies you know:
set(CPACK_RPM_PACKAGE_REQUIRES libqt4-gui = 4.6, libqt4-opengl =
4.6, libopenal1, libsndfile1, libvorbis0a, libgles2)
in the hand-crafted sepc file there is a post-install script.
This can be added with CPackRPM too:
set(CPACK_RPM_POST_INSTALL_SCRIPT_FILE your-post-script.sh)
the file your-post-script.sh should be available (may be in the build
tree or source tree) when the RPM
is built by CPackRPM.
--
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] Sub components with CPack and NSIS
2011/3/8 NoRulez noru...@me.com: Hello everyone, is there a way to generate sub and sub sub components with CPack and Nsis? Yes theoretically there is. But I never tried. I would like to have the following structure, but I couldn’t figure out how to do this: Component | + Sub Component 1 + Sub Component 2 | + Sub Sub Component 1 | + Sub Component 3 | Component 2 There is no such thing as sub-component with CPack you define components and then you group them inside Component Groups. Have a look at the rule for component packaging http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#Principles_of_CPack_Component_Packaging you'll see that a group may have a PARENT_GROUP. However this has been written from what is written in CPack.cmake documentation header and I'm not sure that the PARENT_GROUP has been implemented or used. -- 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] Sub components with CPack and NSIS
2011/3/8 NoRulez noru...@me.com: Ok, I mean a parent group instead of sub component. But i doesn't find any documentations about this too. look in CPack.cmake or cmake --help-module CPack If it isn't implemented in CPack, can i mix cpack and nsis scripts, and if so how? CPack is using a NSIS template file: /usr/share/cmake-2.8/Modules/NSIS.template.in (and there is /usr/share/cmake-2.8/Modules/NSIS.InstallOptions.ini.in too) may be you can do some more NSIS scripting in a custom NSIS.template.in file. search the ML archive. You'll find explanation on how to use a custom NSIS template with 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack and RPM packages
2011/3/7 Laszlo Papp djsz...@archlinux.us:
Any progress on it ?
Nope.
I won't be very responsive this week.
One more information, this n900-devel image uses
internally qemu and I am not sure that can cause any issue for the
build system.
I don't like I said I'm not that experienced with cross-compiling env.
That is also interesting why the debian packaging worked just fine in
the scratchbox using also qemu internally.
Does the pb you are facing for RPM occur in the same scractchbox env?
If this repo corresponds to the same gluon:
http://gitorious.org/gluon/gluon/blobs/master/core/CMakeLists.txt
then those:
set(INCLUDE_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/include
CACHE PATH The subdirectory relative to the install prefix where
header files will be installed.)
set(LIB_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/lib${LIB_SUFFIX}
CACHE PATH The subdirectory relative to the install prefix where
libraries will be installed.)
set(SHARE_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/share
CACHE PATH The subdiractory relative to the install prefix where
data and other files will be installed.)
are not a good idea because after that you use _INSTALL_DIR as
DESTINATIOn of your
INSTALL(...) command which makes it use an ABSOLUTE_INSTALL PATH.
you shouldn't use ${CMAKE_INSTALL_PREFIX}/share but share which
would make it a relative path.
Is there any reason you use absolute destination path.
(this is probably not the culprit but this doesn't help either).
I'll try to examine the problem more in detail tomorrow.
--
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 and RPM packages
2011/3/7 Laszlo Papp djsz...@archlinux.us: As said, the working OBS spec files can be found here: http://repo.pub.meego.com/home:/sandst1/standard/armv7l/ http://repo.pub.meego.com/home:/sandst1/standard/i586/ Not really, since binary RPMs do not contains the spec file, but I did find the spec file in src: http://repo.pub.meego.com/home:/sandst1/standard/src/ (within the src.rpm) http://djszapi.homelinux.net/gluon.spec - this is the cpack/cmake generated one. I have seen that one, and as I said many files seems to be installed with ABSOLUTE DESTINATION and end-up with a %config attribute. If they were installed with relative PATH this wouldn't be the case. Well, the cpack one doesn't really do anything, it only moves files around (and apparently requires some external calling code to move them into place). CPackRPM supposed CMake+build has already been run so CPackRPM generated spec file is a shortcutted one. I don't know anything about cpack, just that the spec file you have there doesn't do anything except moving files around (and maybe package them if they happen to end up in the right place), but certianly not build anything. Yes that's the expected behavior. You cannot (in your case) call CPack without calling CMake first. CMake + make will do the build before CPack get a chance to run. -- 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 and RPM packages
2011/3/8 Laszlo Papp djsz...@archlinux.us: Well: http://public.kitware.com/Bug/view.php?id=11595 That is fixed in cmake 2.8.4. Changelog: http://www.cmake.org/pipermail/cmake/2011-February/042839.html CPackRPM fix bug 0011595 : Can't generate RPMs (on FC11...) I am trying to build this version now on MeeGo since the available binary one is 2.8.3. But if it is fixed in 2.8.4, I wonder why you did not know it ? I do know this bug, I fixed it. I'm just a mere human being and I did not recognize your symptom as being the same as the refered bug. I am really sorry for the wasted time, yours and mine :-/. -- 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 and RPM packages
2011/3/8 Laszlo Papp djsz...@archlinux.us: On Tue, Mar 8, 2011 at 12:45 AM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/8 Laszlo Papp djsz...@archlinux.us: Well: http://public.kitware.com/Bug/view.php?id=11595 That is fixed in cmake 2.8.4. Changelog: http://www.cmake.org/pipermail/cmake/2011-February/042839.html CPackRPM fix bug 0011595 : Can't generate RPMs (on FC11...) I am trying to build this version now on MeeGo since the available binary one is 2.8.3. But if it is fixed in 2.8.4, I wonder why you did not know it ? I do know this bug, I fixed it. I'm just a mere human being and I did not recognize your symptom as being the same as the refered bug. I am really sorry for the wasted time, yours and mine :-/. No idea whether or not that will be the solution, but It is hilarious, I cannot run the cmake ../ properly on the version 2.8.4... I mean it always enters an endless loop at random point, but all the time. I heard qemu+cmake is scary, but still I did never use such combination, I let other comment on that one. How can I build the newest version of the cmake ? Cmake freezes all the time from the shadow build directory It is more than quite /pesky/. Concerning CPackRPM main issue, would try to 1) backup the CMake 2.8.3 , CPackRPM.cmake file 2) Edit CPackRPM.cmake file and change: %install if [ -e $RPM_BUILD_ROOT ]; then mv \\@CPACK_TOPLEVEL_DIRECTORY\@/tmpBBroot/*\ $RPM_BUILD_ROOT else mv \\@CPACK_TOPLEVEL_DIRECTORY\@/tmpBBroot\ $RPM_BUILD_ROOT fi to %install if [ -e $RPM_BUILD_ROOT ]; then rm -rf $RPM_BUILD_ROOT fi mv \\@CPACK_TOPLEVEL_DIRECTORY\@/tmpBBroot\ $RPM_BUILD_ROOT then rerun 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://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake hanging when run inside QEmu
Hi, I am starting a separate thread on this hanging issue. -- Forwarded message -- From: Laszlo Papp xx Date: 2011/3/8 Subject: Re: [CMake] CPack and RPM packages To: Eric Noulard eric.noul...@gmail.com Cc : CMake ML cmake@cmake.org 1st run: ca -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream -- Check for sstream - found -- Looking for unsetenv -- Looking for unsetenv - found -- Looking for environ -- Looking for environ - not found. -- Checking whether header cstdio is available -- Checking whether header cstdio is available - yes -- Checking for Large File Support -- Checking for Large File Support - yes -- Checking whether STL classes are in std namespace -- Checking whether STL classes are in std namespace - yes -- Checking whether ANSI stream headers are available -- Checking whether ANSI stream headers are available - yes -- Checking whether ANSI streams are in std namespace -- Checking whether ANSI streams are in std namespace - yes -- Checking whether ANSI string stream is available -- Checking whether ANSI string stream is available - yes -- Checking whether header cstddef is available -- Checking whether header cstddef is available - yes -- Checking whether stl string has operator!= for char* -- Checking whether stl string has operator!= for char* - yes -- Checking whether stl has iterator_traits Deadlock-like feeling on the user side except that I can kill the process - 2nd run: -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream Endless loop feeling again here. - 3rd run: cmake -DCMAKE_INSTALL_PREFIX=/usr .. -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream -- Check for sstream - found -- Looking for unsetenv -- Looking for unsetenv - found -- Looking for environ -- Looking for environ - not found. -- Checking whether header cstdio is available -- Checking whether header cstdio is available - yes -- Checking for Large File Support -- Checking for Large File Support - yes -- Checking whether STL classes are in std namespace -- Checking whether STL classes are in std namespace - yes -- Checking whether ANSI stream headers are available -- Checking whether ANSI stream headers are available - yes -- Checking whether ANSI streams are in std namespace -- Checking whether ANSI streams are in std namespace - yes -- Checking whether ANSI string stream is available -- Checking whether ANSI string stream is available - yes -- Checking whether header cstddef is available -- Checking whether header cstddef is available - yes -- Checking whether stl string has operator!= for char* -- Checking whether stl string has operator!= for char* - yes -- Checking whether stl has iterator_traits -- Checking whether stl has iterator_traits - yes -- Checking whether stl has standard template allocator -- Checking whether stl has standard template allocator - yes -- Checking for rebind member of stl allocator -- Checking for rebind member of stl allocator - yes -- Checking for non-standard argument to stl allocator::max_size -- Checking for non-standard argument to stl allocator::max_size - no -- Checking whether stl containers support allocator objects. -- Checking whether stl
Re: [CMake] Cmake with Cray Fortran
2011/3/5 Tim Gallagher tim.gallag...@gatech.edu: It's not an option to do a global install. These are US government owned clusters. I asked them if they could install it and they won't for awhile -- they tend to remain a few versions back on everything until they run extensive tests on new versions. Conservative versioning is usually a safe approach but I thought that thanks to the cray module system one could have several versions installed. At the time I was using Cray machines (10+ year ago :-]) the default active software were lagging 1 or 2 versions behind just with the same reason as yours, however a user could module switch don't remember the syntax in order to change default version to something more bleeding edge at his own risk. The bleeding edge software were globally installed but they were not the default active version. The risk for the average user was minimal because he had to explicitely switch version. At that time the sys. admin. team was simply refusing to answer support request for bleeding edge version, however one could use it. I thought this small history may be inspiring for your case. That said if you have no choice then each user should use a locally install CMake, it's easy to do. -- 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 and RPM packages
2011/3/5 Laszlo Papp djsz...@archlinux.us: On Sat, Mar 5, 2011 at 5:32 PM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/5 Laszlo Papp djsz...@archlinux.us: Well, first I cannot build :) I thought you were already using CPack for Deb package? If you never used a cross-compiling setup with CMake then read this first: http://www.cmake.org/Wiki/CMake_Cross_Compiling Meanwhile it can solves the problem, I think there should a developer awareless solution. Can you solve it in a smarter way in the future, please ? Unfortunately I won't have time to work on tis now. Moreover I don't have very much experience in cross-compiling env. so it would take me some to it reasonable. I let other CMake developers comment on that but I think proper cross-compiling setup with CMake goes far further than giving the compiler some -march argument. It may work for very simple CMakeLists.txt but would probably break as soon as you use some CMake features (find modules, try_compile etc...) That said may be providing the proper CMake toolchain file(s) may be more the work of Meego environment provider than CMake itself. I am not refusing to help but I do not have time to handle that now. If you want you can file a bug report http://public.kitware.com/Bug/bug_report_page.php explaining that you want to do cross-packaging with cpack, I'll put the report in the backlog and come back to the issue when more spare time re-appear. -- 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 with Cray Fortran
2011/3/5 Tim Gallagher tim.gallag...@gatech.edu: Hi, I'm trying to use cmake with the Cray Fortran compiler. The compiler is wrapped through a script called ftn. When I have the PrgEnv-pgi (pgi compiler) or the PrgEnv-gnu modules loaded, it works with no issue. But, when I have it set to PrgEnv-cray, it doesn't work. Hi Tim, You should try with CMake 2.8.4. It should include support for Cray compiler: http://www.cmake.org/files/v2.8/CMakeChangeLog-2.8.4 -- 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 with Cray Fortran
2011/3/5 Tim Gallagher tim.gallag...@gatech.edu: Eric, Excellent! Thanks! I don't know a whole lot about CMake (yet) -- would it be possible to make older versions aware of the compiler if I were to package only the updated files rather than install my own version of CMake? In other words, was it something simple like changing the CMakeFortranCompilerId.F file and if so, could I tell another version of CMake to use my own copy of that file? I don't know I am not the author of the fix, I think Brad King was the one who did this, may be he will answer that. It would be a lot easier if I only had to make our users put a few extra files somewhere than have them all install their own version of CMake in their home directories on all these Cray machines. May be deploying CMake 2.8.4 globally on each machine and set up appropriate module would even be easier for the users? Or may be this is not an option because you don'thave administrative privilege on those machines? -- 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 and RPM packages
2011/3/5 Laszlo Papp djsz...@archlinux.us: Well, first I cannot build :) I thought you were already using CPack for Deb package? If you never used a cross-compiling setup with CMake then read this first: http://www.cmake.org/Wiki/CMake_Cross_Compiling [...] -- 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] New CPackRPM failing on build dir with space in it
2011/3/4 Rolf Eike Beer e...@sf-mail.de: Hi All, I know that some new CPackRPM tests are failing http://www.cdash.org/CDash/testDetails.php?test=86188713build=889597 the reason is the build path used contains space which cannot be handled by rpmbuild... I'll fix that tonight and avoid running those tests if build dir contains space. If rpmbuild can't do this it is probably a good idea to throw a good error message in CPack when this happens so the user does not start complaining in the bug tracker or on the list. This sounds also as if that could be easily covered by just another testcase ;) CPackRPM does that already: $ cpack -G RPM [...] CPack: Create package CMake Error at /usr/share/cmake-2.8/Modules/CPackRPM.cmake:202 (MESSAGE): /usr/bin/rpmbuild can't handle paths with spaces, use a build directory without spaces for building RPMs CPack Error: Problem compressing the directory CPack Error: Error when generating package: SchedMCore $ -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] CPack component and packaging ways
Hi All, As of CPack 2.8.4 the component support has been added to ArchiveGenerator and RPM (and NSIS and PackageMaker continue to support component packaging) As explained here; http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#CPack_Generator_specific_behavior Currently NSIS and PackageMaker always generate a single package file which may contain nice component if the project did define appropriate vars. ArchiveGenerators and RPM (and soon Deb) may produce a single package file or several package files depending on user choice. The current rules of CPack Component: http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#Rules makes it clear that: A COMPONENT may only belong to either 0 or a single GROUP. In CPack 2.8.3, you have 4/5 ways to package COMPONENT: 1) the default way : no COMPONENT or MONOLITHIC in order to maintain backward compatibility 1bis) default way if COMPONENT INSTALL is enabled: 1 package file per COMPONENT GROUP 2) ALL_GROUPS_IN_ONE which means that all COMPONENT GROUPS are put in a single package file 3) ALL_COMPONENTS_IN_ONE which means that all COMPONENTS are put in a single package file 4) IGNORE GROUPS which means that you get 1 package file per COMPONENT in 1) ALL INSTALL( xxx) rules found in CMakeLists.txt are processed. in 2,3,4) Only the rules with COMPONENT belongings to CPACK_COMPONENTS_ALL are processed. i.e. with 1bis, 2,3,4) you will only install the COMPONENT specified in CPACK_COMPONENTS_ALL which may only be a portion of all the INSTALL rules. In CPack 2.8.4, rule 1bis) and 2) do not include COMPONENT that did not belong to a GROUP http://public.kitware.com/Bug/view.php?id=11930 this is now fixed (in next) for ArchiveGenerator for 1bis). I did not fixed it in 2) case because if I do ALL_GROUPS_IN_ONE would be strictly equal to ALL_COMPONENTS_IN_ONE. What do you all think about that? Shall I just merge ALL_GROUPS_IN_ONE and ALL_COMPONENTS_IN_ONE to ALL_COMPONENTS_IN_ONE, or shall I keep the awkward behavior of ALL_GROUPS_IN_ONE which can left over some components? I would be tempted to simplify the packaging ways and get rid of ALL_GROUPS_IN_ONE. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] CPack and RPM packages
2011/3/4 Laszlo Papp djsz...@archlinux.us:
Hi,
Can I create an rpm package with cpack in order to not deal with spec files ?
Yes you can CPackRPM is meant to do that:
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#RPM_.28Unix_Only.29
The fastest path is to try:
$ cd /path/to/builddir
$ cpack -G RPM
We did not need to put any debian/{changelog,rules,control} files
related implementation into the project so that to build a debian
package for arm with cpack.
However are you cross-compiling to arm or do you package natively on arm-linux ?
https://projects.kde.org/projects/playground/games/gluon/repository/revisions/master/entry/CMakeLists.txt#L162
Can it be done in a similar way to avoid the rpm spec file writing ?
Yes see the doc:
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#RPM_.28Unix_Only.29
and/or
cmake --help-module CPackRPM
PS: I am not on the list, so please drop me into the 'CC' field.
This is usually a bad habitI am even surprised that you can post
without being on list.
You could subscribe to the list for the duration of your discussion
and then un-subscribe afterwards.
--
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] Multiple library configurations with the same output name
2011/3/4 Alexey Livshits livch...@web.de: I am not a Visual Studio user so I may be missing your point here but why having foo_1 and foo_2 ending up in the same workspace is a problem? As long as the lib/dll end up in separate dirs (using *_OUTPUT_DIRECTORY). Workspaces become too large, so I would like make'em smaller. Should work too. Any other possibility? I don't know I let experienced Visual Studio user answer that one :-] -- 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 and RPM packages
2011/3/4 Laszlo Papp djsz...@archlinux.us:
On Fri, Mar 4, 2011 at 3:05 PM, Eric Noulard eric.noul...@gmail.com wrote:
2011/3/4 Laszlo Papp djsz...@archlinux.us:
Hi,
Can I create an rpm package with cpack in order to not deal with spec files
?
Yes you can CPackRPM is meant to do that:
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#RPM_.28Unix_Only.29
The fastest path is to try:
$ cd /path/to/builddir
$ cpack -G RPM
Right, so you are saying it will create the rpm package with no spec
file reuqested.
Yes.
CPackRPM required some CPACK_RPM_ var def,
however most of them have default values.
The following command will give you the list:
$ cmake --help-module CPackRPM | grep -B 1 -A 1 Mandatory : YES
We did not need to put any debian/{changelog,rules,control} files
related implementation into the project so that to build a debian
package for arm with cpack.
However are you cross-compiling to arm or do you package natively on
arm-linux ?
Well not. I am developing on x86_64 in a cross-compilation way for
arm, N900, MeeGo.
http://wiki.meego.com/Developing_in_a_MeeGo_Environment
I do not know that setup and AFAIK CPackRPM has never been used
in a cross-compiling env. so like I said before give it a try and
tell me what happen.
CPack seems an easier way than OBS if one does not know how to write
spec files. That is why I started this whole thread whether or not
cpack is an easy way to generate rpm package for the N900 mobile -
like previously debian packages with cpack for the same mobile, but
Maemo5/Fremantle platform - or I need to make some other further
hackery.
Again CPackRPM has been tested in native environnement,
I don't know how it will behave in a chroot ARM Meego image.
Try it, and tell me what happen.
PS: I am not on the list, so please drop me into the 'CC' field.
This is usually a bad habitI am even surprised that you can post
without being on list.
You could subscribe to the list for the duration of your discussion
and then un-subscribe afterwards.
I subscribed only for the posting and unsubscribe then immediately
since I am not interested in other mails.
Seems awkward to me but OK, that's your choice :-]
--
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.4-1097-g44c437e
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 44c437ea65b58ed05f9e2ba80c2471dc0f852dbf (commit)
via 77333a92c215bb796c8df8a889118b32f64e38e4 (commit)
from 375d9eac7333c3a8f442f24223a8e5e5bca50846 (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=44c437ea65b58ed05f9e2ba80c2471dc0f852dbf
commit 44c437ea65b58ed05f9e2ba80c2471dc0f852dbf
Merge: 375d9ea 77333a9
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Fri Mar 4 16:18:26 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Mar 4 16:18:26 2011 -0500
Merge topic 'CPack-MoreRobustComponentFileList' into next
77333a9 CPack more robust way to collect files belonging to a component
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=77333a92c215bb796c8df8a889118b32f64e38e4
commit 77333a92c215bb796c8df8a889118b32f64e38e4
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Thu Mar 3 22:43:31 2011 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Thu Mar 3 22:43:31 2011 +0100
CPack more robust way to collect files belonging to a component
diff --git a/Source/CPack/cmCPackGenerator.cxx
b/Source/CPack/cmCPackGenerator.cxx
index 86200c1..2cc2f34 100644
--- a/Source/CPack/cmCPackGenerator.cxx
+++ b/Source/CPack/cmCPackGenerator.cxx
@@ -810,7 +810,52 @@ int
cmCPackGenerator::InstallProjectViaInstallCMakeProjects(
{
mf-AddDefinition(CMAKE_INSTALL_DO_STRIP, 1);
}
+// Remember the list of files before installation
+// of the current component (if we are in component install)
+const char* InstallPrefix = tempInstallDirectory.c_str();
+std::vectorstd::string filesBefore;
+std::string findExpr(InstallPrefix);
+if (componentInstall)
+ {
+ cmsys::Glob glB;
+ findExpr += /*;
+ glB.RecurseOn();
+ glB.FindFiles(findExpr);
+ filesBefore = glB.GetFiles();
+ sort(filesBefore.begin(),filesBefore.end());
+ }
+// do installation
int res = mf-ReadListFile(0, installFile.c_str());
+// Now rebuild the list of files after installation
+// of the current component (if we are in component install)
+if (componentInstall)
+ {
+ cmsys::Glob glA;
+ glA.RecurseOn();
+ glA.FindFiles(findExpr);
+ std::vectorstd::string filesAfter = glA.GetFiles();
+ sort(filesAfter.begin(),filesAfter.end());
+ std::vectorstd::string::iterator diff;
+ std::vectorstd::string result(filesAfter.size());
+ diff = set_difference (
+ filesAfter.begin(),filesAfter.end(),
+ filesBefore.begin(),filesBefore.end(),
+ result.begin());
+
+ std::vectorstd::string::iterator fit;
+ std::string localFileName;
+ // Populate the File field of each component
+ for (fit=result.begin();fit!=diff;++fit)
+{
+localFileName = cmSystemTools::RelativePath(InstallPrefix,
fit-c_str());
+localFileName =
localFileName.substr(localFileName.find('/')+1,std::string::npos);
+Components[installComponent].Files.push_back(localFileName);
+cmCPackLogger(cmCPackLog::LOG_DEBUG, Adding file
+localFileName to component
+installComponentstd::endl);
+}
+ }
+
if (NULL !=mf-GetDefinition(CPACK_ABSOLUTE_DESTINATION_FILES)) {
if (absoluteDestFiles.length()0) {
absoluteDestFiles +=;;
@@ -952,35 +997,6 @@ int cmCPackGenerator::DoPackage()
// The files to be installed
files = gl.GetFiles();
- // For component installations, determine which files go into which
- // components.
- if (!this-Components.empty())
-{
-std::vectorstd::string::const_iterator it;
-for ( it = files.begin(); it != files.end(); ++ it )
- {
- // beware we cannot just use tempDirectory as before
- // because some generator will CPACK_INCLUDE_TOPLEVEL_DIRECTORY
- // we really want CPACK_TEMPORARY_DIRECTORY
- std::string fileN =
-cmSystemTools::RelativePath(
- this-GetOption(CPACK_TEMPORARY_DIRECTORY), it-c_str());
-
- // Determine which component we are in.
- std::string componentName = fileN.substr(0, fileN.find('/'));
-
- // Strip off the component part of the path.
- fileN = fileN.substr(fileN.find('/')+1, std::string::npos);
-
- // Add this file to the list of files
[Cmake-commits] CMake branch, next, updated. v2.8.4-1099-geb92381
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 eb92381eb6cb509b5f64f295a2ed85ff16b17e43 (commit)
via b813f863e6ba9fca7ba216810564c268099db16c (commit)
from 44c437ea65b58ed05f9e2ba80c2471dc0f852dbf (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=eb92381eb6cb509b5f64f295a2ed85ff16b17e43
commit eb92381eb6cb509b5f64f295a2ed85ff16b17e43
Merge: 44c437e b813f86
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Fri Mar 4 16:58:31 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Mar 4 16:58:31 2011 -0500
Merge topic 'CPack-MoreRobustComponentFileList' into next
b813f86 CPack fix compile error on VS70 and avoid KWStyle warnings
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b813f863e6ba9fca7ba216810564c268099db16c
commit b813f863e6ba9fca7ba216810564c268099db16c
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Fri Mar 4 22:57:37 2011 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Fri Mar 4 22:57:37 2011 +0100
CPack fix compile error on VS70 and avoid KWStyle warnings
diff --git a/Source/CPack/cmCPackGenerator.cxx
b/Source/CPack/cmCPackGenerator.cxx
index 2cc2f34..5f314c6 100644
--- a/Source/CPack/cmCPackGenerator.cxx
+++ b/Source/CPack/cmCPackGenerator.cxx
@@ -24,6 +24,7 @@
#include cmsys/SystemTools.hxx
#include cmsys/Glob.hxx
#include memory // auto_ptr
+#include algorithm
#if defined(__HAIKU__)
#include StorageKit.h
@@ -822,7 +823,7 @@ int cmCPackGenerator::InstallProjectViaInstallCMakeProjects(
glB.RecurseOn();
glB.FindFiles(findExpr);
filesBefore = glB.GetFiles();
- sort(filesBefore.begin(),filesBefore.end());
+ std::sort(filesBefore.begin(),filesBefore.end());
}
// do installation
int res = mf-ReadListFile(0, installFile.c_str());
@@ -834,10 +835,10 @@ int
cmCPackGenerator::InstallProjectViaInstallCMakeProjects(
glA.RecurseOn();
glA.FindFiles(findExpr);
std::vectorstd::string filesAfter = glA.GetFiles();
- sort(filesAfter.begin(),filesAfter.end());
+ std::sort(filesAfter.begin(),filesAfter.end());
std::vectorstd::string::iterator diff;
std::vectorstd::string result(filesAfter.size());
- diff = set_difference (
+ diff = std::set_difference (
filesAfter.begin(),filesAfter.end(),
filesBefore.begin(),filesBefore.end(),
result.begin());
@@ -847,8 +848,11 @@ int
cmCPackGenerator::InstallProjectViaInstallCMakeProjects(
// Populate the File field of each component
for (fit=result.begin();fit!=diff;++fit)
{
-localFileName = cmSystemTools::RelativePath(InstallPrefix,
fit-c_str());
-localFileName =
localFileName.substr(localFileName.find('/')+1,std::string::npos);
+localFileName =
+cmSystemTools::RelativePath(InstallPrefix, fit-c_str());
+localFileName =
+localFileName.substr(localFileName.find('/')+1,
+ std::string::npos);
Components[installComponent].Files.push_back(localFileName);
cmCPackLogger(cmCPackLog::LOG_DEBUG, Adding file
localFileName to component
---
Summary of changes:
Source/CPack/cmCPackGenerator.cxx | 14 +-
1 files changed, 9 insertions(+), 5 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] Multiple library configurations with the same output name
2011/3/3 Alexey Livshits livch...@web.de:
Hello CMakers,
suppose I've got a library foo with tow configurations: foo_1 and
foo_2. Both versions should have the same output name: foo. The
problem is, the output directory for both ist the same, so the second
will overwrite the first.
You can definition two different library target
and use OUTPUT_NAME property to adjust the name
add_library(foo1 ${foo_source})
set_target_properties(foo1 PROPERTIES
OUTPUT_NAME foo)
add_library(foo2 ${foo_source})
set_target_properties(foo2 PROPERTIES
OUTPUT_NAME foo)
You probably want to adjust COMPILE_FLAGS and/or LINK_FLAGS
for each target as well.
What's the best way to organize it?
If you intend to build those librarie during the same build then
you'll have to define those targets in separate directories
(with shared source are shared).
--
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] BUG: Special chars in user name. Configure error.
2011/2/27 and...@sibmail.com: Hello i got some bug. I use W7 and username CC. So when i run Configure in gui under this user, Cmake throws an error: cant build simple programm... and more unknown chars... (full error log attached) and this not error of compiler. But when i run it on other user name of that have not special chars like '' all is ok. Please fix it. Hi Andrey, Would you kind enough to file a bug report in the bug tracker http://public.kitware.com/Bug/bug_report_page.php then whether if it could be fixed before next release. I'd like to give one more advice, you may say Please fix it. but this is usually little too much mandatory tone on a public mailing list with volunteer. You may try that with someone you hire for doing the job you want, but surely not with volunteer. I may be wrong about your intention so forgive me if I'm mistaken concerning the way you ask. Thank you for your bug report. -- 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] Multiple Package Generators and add_package command
2011/2/26 Orcun Gokbulut mador...@gmail.com: I'm trying to find out a way to generate multiple packages from a big project. There are some patches and hack available but I'm not experienced cmake user and I can not figure out how to use them. IMHO, an add_package command can be usefull instead of configuring cpack variables and including cpack module. Did you have a look at: http://www.vtk.org/Wiki/CMake:Component_Install_With_CPack In fact the features you want are almost already there but somehow not so well known (and documented). There exists 3 macros (+1 another let's about those 3): cpack_add_component Describes a CPack installation component named by the COMPONENT argument to a CMake INSTALL command. cpack_add_component_group Describes a group of related CPack installation components. cpack_add_install_type Add a new installation type containing a set of predefined component selections to the graphical installer. # # cpack_add_component(compname # [DISPLAY_NAME name] # [DESCRIPTION description] # [HIDDEN | REQUIRED | DISABLED ] # [GROUP group] # [DEPENDS comp1 comp2 ... ] # [INSTALL_TYPES type1 type2 ... ] # [DOWNLOADED] # [ARCHIVE_FILE filename]) # # cpack_add_component_group(groupname # [DISPLAY_NAME name] # [DESCRIPTION description] # [PARENT_GROUP parent] # [EXPANDED] # [BOLD_TITLE]) # # cpack_add_install_type(typename #[DISPLAY_NAME name]) For example; I have created a library and I want to distribute it. But there is two type of distribution that I have to create. In the first distributions I include libraries, sample programs, runtime executives and documentation. In the other distribution, in addition to the components in the first distribution, I also want to include source files. The procedure for doing what you want is to: 1) Use COMPONENT argument in you install statement 2) include(CPack) *** THIS ONE MUST COME THE NEXT :-] *** 3) Define your component setup using cpack_add_component cpack_add_component_group cpack_add_install_type The order of usage shouldn't matter even if cpack_add_component uses group and install_type the cpack_add_component_group and cpack_add_install_type do not define them but just describe what has already been defined by cpack_add_component. Currently this is awkward because CPack users are used to 1) define a lot of CPACK_xxx vars 2) include(CPack) use cpack -G or make package. But the fact is the cpack_add_* macros do APPEND the file generated by CPack when using include(CPack), so you can use them afterwards so neat [and clumsy] :-) [...] I think this can be very easy to use and maintain. This is just an sample there can be other types of commands something like add_target_to_package, add_component_to_package or add_component_group_to_package and etc with many different options. Your idea is different from the current CPack component handling because with CPack you currently do not specify what you want in A package file but what you want in THE package file. Basically CPack was designed to generate a SINGLE package. Now with COMPONENTized install, some generators (ZIP, TGZ, etc... and RPM) now (since 2.8.4) do generate several package files. But I think that's not exactly what you asked Multiple package generation can same time and effort when maintaining and deploying multiple configurations of a big project. However, the need of being able to produce several package is coming up again and again. Last ones: http://public.kitware.com/Bug/view.php?id=11808 http://public.kitware.com/Bug/view.php?id=10751 My opinion is the following: We shall build on top of current COMPONENT installation. A COMPONENT is the basic grouping kind. Component Group has been designed for grouping component. (But a component CANNOT belong to several groups). Install Types may be used to do what YOU want: listing a set of components. And in this case the same components may belongs to different install types. So using Install Types we may teach CPack generators to build one package per install type (with some CPACK_xxx options). What do you think? Interested people may monitor/contribute the CPack-ModularizeCPack branch on stage I'll try to get a more modular CPack there with hopefully multi-package support. -- 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
Re: [CMake] CMake Error: Error processing file
2011/2/28 Stephen Thomas sthomas...@gmail.com: Hello, I'm very new to cmake and I'm attempting to build the webcamtools package. While I've been able to get CMake to work properly on the host I'm working on I really need it to configure for cross-compiling to a embedded ARM TS-7800 board. In reading through various documentation I've created my Toolchain.cmake file but the error I'm up against is CMake Error: Error Processing file:. [...] ---begin typescript of cmake run--- Script started on Sun 27 Feb 2011 01:19:09 PM CST [1]debian cmake --version cmake version 2.8.4 [2]debian cmake -CMAKE_TOOLCHAIN_FILE=/home/swt/work/Toolchain-ts7800-arm.cmake -DUVCVIDEO_INCLUDE_PATH=~/work/linux-2.6.34/drivers/media/video/uvc/ .. loading initial cache file You have a typo on your command line: -CMAKE_TOOLCHAIN_FILE=/home/swt/work/Toolchain-ts7800-arm.cmake should be -DCMAKE_TOOLCHAIN_FILE=/home/swt/work/Toolchain-ts7800-arm.cmake Thus the error: MAKE_TOOLCHAIN_FILE=/home/swt/work/Toolchain-ts7800-arm.cmake CMake Error: Error processing -C option is for preloading cache -D for defining some var value. -- 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.4-1023-g7a8a14e
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 7a8a14e70c4e7b449a558dfd7f7291101528512c (commit)
via 5b4cbdb45e1f0efb2c55b29a4ca2521f38e88f96 (commit)
from 8dc98c3955255df16a5728a2dedc63907c8a6a26 (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=7a8a14e70c4e7b449a558dfd7f7291101528512c
commit 7a8a14e70c4e7b449a558dfd7f7291101528512c
Merge: 8dc98c3 5b4cbdb
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Fri Feb 25 10:49:17 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Feb 25 10:49:17 2011 -0500
Merge topic 'CPackRPM-AvoidSpaceInName-Fixbug9932' into next
5b4cbdb CPackRPM Replace space in some CPACK_ vars (Fix bug 9932)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5b4cbdb45e1f0efb2c55b29a4ca2521f38e88f96
commit 5b4cbdb45e1f0efb2c55b29a4ca2521f38e88f96
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Fri Feb 25 16:47:11 2011 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Fri Feb 25 16:47:11 2011 +0100
CPackRPM Replace space in some CPACK_ vars (Fix bug 9932)
diff --git a/Source/CPack/cmCPackRPMGenerator.cxx
b/Source/CPack/cmCPackRPMGenerator.cxx
index 2d675c1..cc50580 100644
--- a/Source/CPack/cmCPackRPMGenerator.cxx
+++ b/Source/CPack/cmCPackRPMGenerator.cxx
@@ -31,6 +31,21 @@ int cmCPackRPMGenerator::InitializeInternal()
{
this-SetOption(CPACK_SET_DESTDIR, I_ON);
}
+ /* Replace space in CPACK_PACKAGE_NAME in order to avoid
+ * rpmbuild scream on unwanted space in filename issue
+ * Moreover RPM file do not usually embed space in filename
+ */
+ if (this-GetOption(CPACK_PACKAGE_NAME)) {
+std::string packageName=this-GetOption(CPACK_PACKAGE_NAME);
+cmSystemTools::ReplaceString(packageName, ,-);
+this-SetOption(CPACK_PACKAGE_NAME,packageName.c_str());
+ }
+ /* same for CPACK_PACKAGE_FILE_NAME */
+ if (this-GetOption(CPACK_PACKAGE_FILE_NAME)) {
+std::string packageName=this-GetOption(CPACK_PACKAGE_FILE_NAME);
+cmSystemTools::ReplaceString(packageName, ,-);
+this-SetOption(CPACK_PACKAGE_FILE_NAME,packageName.c_str());
+ }
return this-Superclass::InitializeInternal();
}
---
Summary of changes:
Source/CPack/cmCPackRPMGenerator.cxx | 15 +++
1 files changed, 15 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-developers] Test failing because Test directory is not clean
2011/2/23 Eric Noulard eric.noul...@gmail.com: 2011/2/23 Clinton Stimpson clin...@elemtech.com: I've having problems with these tests too. If they fail once, they will keep failing until some files generated by the failed test are cleaned up. Some files should be, the package files located at the root of the build dir. Seems to me that an extra cleanup step should be done before or during the ctest --build-and-test for these tests that glob for generated files. Could you do this with a ctest script that cleans the test specific build directory before doing the configure/build/test? And call that ctest script in the add_test() call? I'm not sure if this is a good idea, but what if the glob was done under the _CPack_Packages directory which cpack always cleans beforehand. In my case it wouldn't be enough to kill _CPack_Packages there will remain spurious files in the build tree. I did pushed forward the CPack-ChangeComponentNamingScheme branch the test itself is cleaning up the build tree from expected package files before running CPack. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] cpack issue: %1 is not a valid Win32 application
2011/2/24 thehighhat thehighhat+...@gmail.com: On Thu, Feb 24, 2011 at 12:20 PM, David Cole david.c...@kitware.com wrote: Do you have the same problem if you use a real binary for the 'make' instead of this symlink? Yes, the same problem persists. I started with a clean builddir. Changed all references to use the actual file, not symlinks. Called make using the actual file, not symlinks. The build succedded. and teh binary works. But I still have the same problem: %1 is not a valid Win32 application I cannot get cpack to build the NSIS installer correctly. Does this mean that other CPack generators works? Could you try ZIP ? cpack --verbose -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] cpack issue: %1 is not a valid Win32 application
2011/2/25 Martin O'Brien martin.matthew.obr...@gmail.com: I haven't really read most if this thread, so this may not apply, but this dialog box can be caused by trying to run a Win64 application on Win32, or trying to run any binary other than Win32 with a format that Windows understands on Win32. Interesting, Is the NSIS application used a 32bits or 64bits one? -- 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.4-996-g3397e54
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 3397e54c3c77d1b1f713e6066a47154cc8d487d7 (commit)
via f2ab270e6f0f1c95fe134a7b9b1ad4037d0ef0fe (commit)
from 6dbbf23a3973b076870f1f6e97a1dbe81d3fb311 (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=3397e54c3c77d1b1f713e6066a47154cc8d487d7
commit 3397e54c3c77d1b1f713e6066a47154cc8d487d7
Merge: 6dbbf23 f2ab270
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Wed Feb 23 18:30:04 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Feb 23 18:30:04 2011 -0500
Merge topic 'CPack-ChangeComponentNamingScheme' into next
f2ab270 CPack fix KWStyle warning
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f2ab270e6f0f1c95fe134a7b9b1ad4037d0ef0fe
commit f2ab270e6f0f1c95fe134a7b9b1ad4037d0ef0fe
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Thu Feb 24 00:29:25 2011 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Thu Feb 24 00:29:25 2011 +0100
CPack fix KWStyle warning
diff --git a/Source/CPack/cmCPackGenerator.cxx
b/Source/CPack/cmCPackGenerator.cxx
index 4cb4f36..86200c1 100644
--- a/Source/CPack/cmCPackGenerator.cxx
+++ b/Source/CPack/cmCPackGenerator.cxx
@@ -1344,7 +1344,7 @@ std::string cmCPackGenerator::GetComponentPackageFileName(
else
{
std::string dispVar = CPACK_COMPONENT_
-+ cmSystemTools::UpperCase(groupOrComponentName) +
_DISPLAY_NAME;
+ + cmSystemTools::UpperCase(groupOrComponentName) + _DISPLAY_NAME;
const char* dispName = GetOption(dispVar.c_str());
if(dispName)
{
---
Summary of changes:
Source/CPack/cmCPackGenerator.cxx |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
[Cmake-commits] CMake branch, next, updated. v2.8.4-998-gb831e88
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 b831e88b5acbf9749980a02157e1c726884c5479 (commit)
via 3fb89cf8bdae9b534dddb45b786903de4c9ac7aa (commit)
from 3397e54c3c77d1b1f713e6066a47154cc8d487d7 (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=b831e88b5acbf9749980a02157e1c726884c5479
commit b831e88b5acbf9749980a02157e1c726884c5479
Merge: 3397e54 3fb89cf
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Wed Feb 23 18:50:22 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Feb 23 18:50:22 2011 -0500
Merge topic 'CPack-ChangeComponentNamingScheme' into next
3fb89cf CPack remove previously CPack generated files (if any) before
running CPack
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3fb89cf8bdae9b534dddb45b786903de4c9ac7aa
commit 3fb89cf8bdae9b534dddb45b786903de4c9ac7aa
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Thu Feb 24 00:43:29 2011 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Thu Feb 24 00:49:11 2011 +0100
CPack remove previously CPack generated files (if any) before running CPack
diff --git a/Tests/CPackComponentsForAll/RunCPackVerifyResult.cmake
b/Tests/CPackComponentsForAll/RunCPackVerifyResult.cmake
index d5137bd..45a3b17 100644
--- a/Tests/CPackComponentsForAll/RunCPackVerifyResult.cmake
+++ b/Tests/CPackComponentsForAll/RunCPackVerifyResult.cmake
@@ -32,17 +32,6 @@ if(config_type)
set(config_args -C ${config_type})
endif()
message( ${config_args})
-execute_process(COMMAND ${CPackCommand} -G ${CPackGen} ${config_args}
-RESULT_VARIABLE CPack_result
-OUTPUT_VARIABLE CPack_output
-ERROR_VARIABLE CPack_error
-WORKING_DIRECTORY ${CPackComponentsForAll_BINARY_DIR})
-
-if (CPack_result)
- message(FATAL_ERROR error: CPack execution went wrong!,
CPack_output=${CPack_output}, CPack_error=${CPack_error})
-else (CPack_result)
- message(STATUS CPack_output=${CPack_output})
-endif(CPack_result)
if(CPackGen MATCHES ZIP)
set(expected_file_mask ${CPackComponentsForAll_BINARY_DIR}/MyLib-*.zip)
@@ -63,6 +52,26 @@ if(CPackGen MATCHES ZIP)
endif (${CPackComponentWay} STREQUAL AllGroupsInOne)
endif(CPackGen MATCHES ZIP)
+# clean-up previously CPack generated files
+if(expected_file_mask)
+ file(GLOB expected_file ${expected_file_mask})
+ if (expected_file)
+file(REMOVE ${expected_file})
+ endif(expected_file)
+endif(expected_file_mask)
+
+execute_process(COMMAND ${CPackCommand} -G ${CPackGen} ${config_args}
+RESULT_VARIABLE CPack_result
+OUTPUT_VARIABLE CPack_output
+ERROR_VARIABLE CPack_error
+WORKING_DIRECTORY ${CPackComponentsForAll_BINARY_DIR})
+
+if (CPack_result)
+ message(FATAL_ERROR error: CPack execution went wrong!,
CPack_output=${CPack_output}, CPack_error=${CPack_error})
+else (CPack_result)
+ message(STATUS CPack_output=${CPack_output})
+endif(CPack_result)
+
# Now verify if the number of expected file is OK
# - using expected_file_mask and
# - expected_count
---
Summary of changes:
.../RunCPackVerifyResult.cmake | 31 +---
1 files changed, 20 insertions(+), 11 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.4-989-ged5bad8
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 ed5bad815d43106784547ebda938b4d58c257b47 (commit)
via 4deb308e82b8f9e56ce41eba211f330ff66902a3 (commit)
via 8c450f6287e45fa737de7d09a4f29ee7f4fdc9dd (commit)
from 1929bb27a92aeb99edf25684d0a0583ea0090d8b (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=ed5bad815d43106784547ebda938b4d58c257b47
commit ed5bad815d43106784547ebda938b4d58c257b47
Merge: 1929bb2 4deb308
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Tue Feb 22 18:03:36 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Feb 22 18:03:36 2011 -0500
Merge topic 'CPack-ChangeComponentNamingScheme' into next
4deb308 CPack Authorize DISPLAY_NAME usage in component package
8c450f6 CPack remove -ALL suffix for ALL-IN-ONE packages
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4deb308e82b8f9e56ce41eba211f330ff66902a3
commit 4deb308e82b8f9e56ce41eba211f330ff66902a3
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Tue Feb 22 23:49:49 2011 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Tue Feb 22 23:49:49 2011 +0100
CPack Authorize DISPLAY_NAME usage in component package
Second (last) part fix of feature request #11814
diff --git a/Source/CPack/cmCPackArchiveGenerator.cxx
b/Source/CPack/cmCPackArchiveGenerator.cxx
index ff88412..3c670a1 100644
--- a/Source/CPack/cmCPackArchiveGenerator.cxx
+++ b/Source/CPack/cmCPackArchiveGenerator.cxx
@@ -121,9 +121,11 @@ int cmCPackArchiveGenerator::PackageComponents(bool
ignoreGroup)
std::endl);
// Begin the archive for this group
std::string packageFileName= std::string(toplevel);
- packageFileName += /
-+std::string(this-GetOption(CPACK_PACKAGE_FILE_NAME))
-+-+compGIt-first + this-GetOutputExtension();
+ packageFileName += /+
+ GetComponentPackageFileName(this-GetOption(CPACK_PACKAGE_FILE_NAME),
+ compGIt-first,
+ true)
+ + this-GetOutputExtension();
// open a block in order to automatically close archive
// at the end of the block
{
@@ -154,9 +156,11 @@ int cmCPackArchiveGenerator::PackageComponents(bool
ignoreGroup)
std::string packageFileName = std::string(toplevel);
localToplevel += /+ compIt-first;
- packageFileName += /
-+std::string(this-GetOption(CPACK_PACKAGE_FILE_NAME))
-+-+compIt-first + this-GetOutputExtension();
+ packageFileName += /+
+ GetComponentPackageFileName(this-GetOption(CPACK_PACKAGE_FILE_NAME),
+ compIt-first,
+ false)
++ this-GetOutputExtension();
{
DECLARE_AND_OPEN_ARCHIVE(packageFileName,archive);
// Add the files of this component to the archive
diff --git a/Source/CPack/cmCPackGenerator.cxx
b/Source/CPack/cmCPackGenerator.cxx
index 69d9b8c..4cb4f36 100644
--- a/Source/CPack/cmCPackGenerator.cxx
+++ b/Source/CPack/cmCPackGenerator.cxx
@@ -1309,10 +1309,51 @@ int cmCPackGenerator::PrepareGroupingKind()
return 1;
}
+//--
std::string cmCPackGenerator::GetComponentInstallDirNameSuffix(
const std::string componentName) {
return componentName;
}
+//--
+std::string cmCPackGenerator::GetComponentPackageFileName(
+const std::string initialPackageFileName,
+const std::string groupOrComponentName,
+bool isGroupName) {
+
+ /*
+ * the default behavior is to use the
+ * component [group] name as a suffix
+ */
+ std::string suffix=-+groupOrComponentName;
+ /* check if we should use DISPLAY name */
+ std::string dispNameVar = CPACK_+Name+_USE_DISPLAY_NAME_IN_FILENAME;
+ if (IsOn(dispNameVar.c_str()))
+{
+/* the component Group case */
+if (isGroupName)
+ {
+ std::string groupDispVar = CPACK_COMPONENT_GROUP_
+ + cmSystemTools::UpperCase(groupOrComponentName) + _DISPLAY_NAME;
+ const char* groupDispName = GetOption(groupDispVar.c_str());
+ if (groupDispName)
+{
+suffix = -+std::string(groupDispName);
+}
+ }
+/* the [single] component case */
+else
+ {
+ std::string dispVar = CPACK_COMPONENT_
++ cmSystemTools::UpperCase(groupOrComponentName) +
_DISPLAY_NAME;
+const char* dispName = GetOption(dispVar.c_str());
+if(dispName
Re: [CMake] Setting global make variable from CMake,
2011/2/21 Łukasz Tasz luk...@tasz.eu: Hi All, Could somebody help me how to provide own predefined make varibable from cmake configuration? Such a variable should be avaliable in the context of all generated makefiles. Since the makefiles are generated by CMake WHY do you need to define a make var? What do you want to do ? CMake was not designed to let you decide generator specifics things. I would like to receive output in a way: in master Makefile: export MY_OWN_DEBUG_VAR=3 MY_OWN_DEBUG_VAR should be predefined inside cmake, of passed to cmake via -DMY_OWN_DEBUG_VAR=3 passing throu make macro is not a sollution. What is your use case? -- 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] Setting global make variable from CMake,
2011/2/21 Łukasz Tasz luk...@tasz.eu: 2011/2/21 Eric Noulard eric.noul...@gmail.com: What is your use case? In my case I'm making integration with ccache, and distcc, and as you know all of them are tuned only via ENV_VARS. Depending on CMAKE_BUILD_TYPE, compiler version, OS I would like to prepare correct DISTCC_HOSTS variable etc. Ok I see. That is why in my mind setting global make variable is a solution, at least my brain wouled generate such a makefile:) Another solution that poped up in my mind is to register this variable before calling compiler/linker, Do you know such a call can be configured? for example: export MYVARIABVLE=test; cd dir; compiler_call I don't think there is an easy way to do that from within CMake. You would need some way to set env var before launching the compile rule the only way I see would be to craft a compile script for each case. -- 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] Setting global make variable from CMake,
2011/2/21 Michael Wild them...@gmail.com: Do you know such a call can be configured? for example: export MYVARIABVLE=test; cd dir; compiler_call I don't think there is an easy way to do that from within CMake. You would need some way to set env var before launching the compile rule the only way I see would be to craft a compile script for each case. You could experiment with the RULE_LAUNCH_COMPILE and RULE_LAUNCH_LINK properties... However, that would only work for Makefile-based generators. I didn't even know those properties existed :-] Thank you Michael. -- 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 32bit rpm on a 64bit system
2011/2/17 Yngve Inntjore Levinsen yngve.levin...@gmail.com: Dear Eric, So I answered my own question perhaps, the very issue was in fact that I set CPACK_RPM_PACKAGE_ARCHITECTURE to i686 when I tried to build. Commenting out that part and the packaging worked. OK. Two questions: - Will this package now be installable on both 32 and 64bit systems? If not, can I get it to be installable on both architectures somehow? It will work if the 64 bits distro is installed with 32 bits compat' lib or if the content of your executable is fully static, since most 64 bits linux systems are capable of runing 32 bits executable. That said I would rather build two packages, one for 64 bits and another one for 32 bits. There is no such thing as MacOS Universal Binaries on Linux but there is at least 1 project trying to do it: FatELF: http://icculus.org/fatelf/ - Why shouldn't I set the variable? I'll have to check but this probably due to the fact that the rpmbuild command expected CPACK_RPM_PACKAGE_ARCHITECTURE and host advertised arch to be consistent. setting CPACK_RPM_PACKAGE_ARCHITECTURE to noarch always worked, in fact it was introduced just for that purpose (when you know that your package does not contains arch specific files). Concerning cross-packaging which is somehow what you are trying to do it is mostly untested and it will probably work in a very limited number of case (including yours) Cross packaging may be done by other tools like PBuilder for Ubuntu (https://wiki.ubuntu.com/PbuilderHowto) or Mock for Fedora/RHEL (http://fedoraproject.org/wiki/Projects/Mock) or even OBS (https://build.opensuse.org/). Clean cross-packaging is usually far more complicated than package some cross-compiled file and pretends arch is YYY. -- 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] Gyp VS CMake
2011/2/17 Felipe Ferreri Tonello felipe.tone...@totvs.com.br: On Thursday 17 February 2011 06:15:34 Nicolas Desprès wrote: That being said, I feel sad to see other CMake's like projects started instead of contributing. Regards, I'm with you. I don't know why there are companies or people who starts other open source projects instead of improving some other that do the same thing. It's exaclty like Nokia that prefer to create QtCreator instead of improving KDevelop, which is a gread developer tool. I like CMake very much, but I'm glad there are other tools to do the same task out there even new ones. Diversity is good because it brings you choice. What would be Open Source without the freedom of choice? I'd like to be able to switch from KDE to Gnome to XFCE to Enlightment from time to time. I may even provide patch to everyone of them. Moreover if you can afford the freedom to do it your own way, why wouldn't you do it ? That said companies have their own marketing view which may be far away from my point of view. E.g. from my side when you say Nokia that prefer to create QtCreator instead of improving KDevelop I would answer that create QtCreator does not prevent from improving KDevelop. Both project can benefit from one another. From the Nokia side I doubt it but I honestly don't know. -- 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 32bit rpm on a 64bit system
2011/2/16 Yngve Inntjore Levinsen yngve.levin...@gmail.com: Dear Eric, First, thank you for a very quick reply! The log you requested is attached. The rpmbuild.out file is empty, and the rpmbuild.err has one line which states: error: No compatible architectures found for build I am using cmake/cpack version 2.6-patch 4. I have rpmbuild version 4.4.2.3. CMake 2.6.4 is ancient...and the 2.6.x branch has been stopped. Would you be able to try 2.8.3 see http://www.cmake.org/files/v2.8/ ? Why I am doing it? I suppose it is a rather weird request, but I want to build a 32bit binary on my 64bit server and distribute the program to many people that still use a 32bit machine. In order to have maximum compability, it has been decided that we should provide a statically linked 32bit executable. It is not necessary to provide this in an rpm of course, but it would be nice if it was possible. It should be, and it should work because you build static. I do not remember the state of CPack RPM in 2.6.4 so I have to dig it out in order to see how you can enforce the appropriate arch. Before I do that, could you tell me if you can afford to use CMake 2.8.3 ? -- 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 32bit rpm on a 64bit system
2011/2/16 Yngve Inntjore Levinsen yngve.levin...@gmail.com: The server OS is quite conservative when it comes to new packages, so I already had to go into a fight to get 2.6 series installed. I do not think that is possible system-wide but I am of course able to compile cmake myself and put it on my own share. I understand. You may try 2.8.3 (or even todays 2.8.4) without compiling it by taking precompiled one: http://www.cmake.org/files/v2.8/cmake-2.8.3-Linux-i386.tar.gz or http://www.cmake.org/files/v2.8/cmake-2.8.4-Linux-i386.tar.gz Untar them somewhere in your directory. Then invoke the installed CMake. I propose you let me know how to do it with 2.8.3 and I do that workaround. I'm not sure it will work with CMake 2.8.3 but it would easier for me to fix it in the maintained 2.8.x branch than trying to fix the unmaintained 2.6.4. Normally set(CPACK_RPM_PACKAGE_ARCHITECTURE i686) should be enough. If it is not try: $ setarch i686 $ cpack -G RPM this last method may work with CMake 2.6.4 too. I can put a feature request to upgrade cmake. I forgot to answer one of your questions, I build 32bit with the -m32 flag, that is correct. -- 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] Setting target destination and rpath per generator
2011/2/15 Daryl N darylhouse2...@yahoo.com:
Hi,
I have a question on the use of CPack. I have CMake setup to generate
binaries and shared libraries. Up until now I have only created a TGZ with
rpath set to .. This has worked nicely, but now I would like to create a
Debian package for proper installation. I have added DEB to CPACK_GENERATOR
and I've created my own cpack_config.cmake file. My goal is:
1. Run cmake/make package once and create the tar.gz file with all exe/libs
in the root folder of the tar.gz file with rpath set to ..
2. Create new .deb package with exes in /usr/local/bin and libs in
/usr/local/lib. Alternatively, since files are private, all could be put in
/usr/local/some folder.
I've attempted this by creating my own cpack_config.cmake file to try to
override some settings per generator. Some observations:
1. I've been unable to set the install(target DESTINATION) path per
generator in my cpack_config.cmake file. Whatever the variable is set to
when the install(...) is processed in the CMakeLists.txt file is what is
used for all generators. Just want to confirm changing this isn't an option
per generator.
The above has prevented me from having my install lines like:
install(target DESTINATION ${BIN_PATH})
install(target DESTINATION ${LIB_PATH})
and then setting BIN_PATH to bin and LIB_PATH to lib for DEB, but setting
them to . for TGZ, since I can't change the variable in
.
I suppose cpack_config.cmake is your CPACK_PROJECT_CONFIG_FILE.
As far as I know you cannot change install rules on CPack generator basis.
install rules belongs to CMakeLists.txt and they are evaluated at CMake-time
(not CPack-time).
cpack_config.cmake is evaluated at CPack-time, i.e. when CPack runs.
You can do CPack-generator specific actions in this file.
(like setting CPACK_SET_DESTDIR OFF or ON or changing
CPACK_PACKAGING_INSTALL_PREFIX etc...)
I did not tried playing with rpath but may be you can
if(CPACK_GENERATOR MATCHES TGZ)
set(CMAKE_INSTALL_RPATH .)
set(CPACK_SET_DESTDIR OFF)
endif(CPACK_GENERATOR MATCHES TGZ)
if(CPACK_GENERATOR MATCHES DEB)
set(CPACK_PACKAGING_INSTALL_PREFIX /usr/local/somefolder)
endif(CPACK_GENERATOR MATCHES DEB)
2. I would also like to set the rpath per generator. So the targets in the
TGZ only look in . while the DEB installed targets only look in
/usr/local/some folder. But I haven't been able to update the rpath per
generator in cpack_config.cmake. I've tried both setting
CMAKE_INSTALL_RPATH and using set_target_properties(... PROPERTIES
INSTALL_RPATH). Again, I'm assuming this can't be changed at CPack time.
I don't know whether if CMAKE_INSTALL_RPATH can be changed at CPack time
(as I suggested in my previous example) you'll have to try and
may be verify in the CMake source code in order to check when it is handled.
Whatever the current status,
I don't see why it couldn't be handled at CPack time
(but I may be missing something).
Do I need to run cpack
separately changing the variables before hand? I suppose that would mean 2
builds cycles also, once for each generator.
2 build cycles will definitely work.
However if you gives us more information on what's inside your
cpack_config.cmake
what works what does not work with it, may be we can see if it it can
be done in a single build.
I think the main issue is the fact that as far as I understand your
need you want
to put all files (libs, exe) in a single folder for the TGZ and have
prefix+/lib, prefix+/bin
in the DEB case?
Changing the prefix is easy but adding (or removing) the extra /lib
and /bin I don't
currently know how to do that. Why won't you keep the lib and bin
suffix in the TGZ case?
--
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] Setting target destination and rpath per generator
2011/2/15 David Cole david.c...@kitware.com: You cannot do cmake-ish things in the CPACK_PROJECT_CONFIG_FILE. Neither install commands nor set_target_properties calls do anything in this context. Yes you are right, but we may have expected that CMAKE_INSTALL_RPATH may be used at INSTALL time just like CMAKE_INSTALL_DO_STRIP or CMAKE_INSTALL_PREFIX are. That said, current status is one needs to build twice for fulfilling the Daryl's needs. -- 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 32bit rpm on a 64bit system
2011/2/15 Yngve Inntjore Levinsen yngve.levin...@gmail.com: Dear CMakers, I am trying to package a 32bit binary on a 64bit system. It breaks with the (useless?) verbose output which follows below. What I could find of useful information was in _CPack_Packages/Linux/RPM/rpmbuild.err, which stated error: No compatible architectures found for build Which version of CMake/CPack ? I tried to set CPACK_RPM_PACKAGE_ARCHITECTURE and CPACK_PACKAGE_ARCHITECTURE to i686, but that didn't do much. I found that e.g. the TGZ generator works just fine, so I suppose it is something with the RPM generator, but I am not clever enough to figure out what... Can anyone help? Could you send me the log obtained with: cpack -V -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM and send me the advertised rpmbuild.err, rpmbuild.out, yourpackageName.spec files? Some more questions: What is your linux distribution ? How did you build the 32bits binaries with CMake (? add -m32 using CFLAGS?) ? RPM packaging of 32bits apps on 64bits may not be portable at all, why are you trying to do 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://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.3-1645-g6707097
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 670709703faf6388ab3096bf43c3221ee2a6e838 (commit) via 0cf1d72e3c1be9218f4dc0d1dcc0aaf03f160684 (commit) from 43d96cfe881eed354414195938deaefa537749e5 (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=670709703faf6388ab3096bf43c3221ee2a6e838 commit 670709703faf6388ab3096bf43c3221ee2a6e838 Merge: 43d96cf 0cf1d72 Author: Eric Noulard eric.noul...@gmail.com AuthorDate: Tue Feb 15 14:00:22 2011 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 15 14:00:22 2011 -0500 Merge topic 'CPackRPM-HonorAllComponentWays' into next 0cf1d72 CPackRPM fix IRIX compiler warning (variable never used) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0cf1d72e3c1be9218f4dc0d1dcc0aaf03f160684 commit 0cf1d72e3c1be9218f4dc0d1dcc0aaf03f160684 Author: Eric NOULARD eric.noul...@gmail.com AuthorDate: Tue Feb 15 19:55:36 2011 +0100 Commit: Eric NOULARD eric.noul...@gmail.com CommitDate: Tue Feb 15 19:55:36 2011 +0100 CPackRPM fix IRIX compiler warning (variable never used) diff --git a/Source/CPack/cmCPackRPMGenerator.cxx b/Source/CPack/cmCPackRPMGenerator.cxx index a5a9753..2d675c1 100644 --- a/Source/CPack/cmCPackRPMGenerator.cxx +++ b/Source/CPack/cmCPackRPMGenerator.cxx @@ -182,7 +182,7 @@ int cmCPackRPMGenerator::PackageComponentsAllInOne(bool allComponent) // add the generated package to package file names list packageFileNames.push_back(packageFileName); - return 1; + return retval; } //-- --- Summary of changes: Source/CPack/cmCPackRPMGenerator.cxx |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] Link directories
2011/2/14 Robert Bielik robert.bie...@xponaut.se: Hi all, I seem to be missing something, cause I cannot find a target property for setting additional library directories (for a MSVC project) Usually you do not specify additional lib directories you should specify all libs you need with target_link_libraries. In any case have a look at the documentation of the following CMake commands target_link_libraries link_directories link_libraries (DEPRECATED) -- 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] Work on the graphviz support - compatibility ?
2011/2/13 Alexander Neundorf neund...@kde.org: On Monday 07 February 2011, Alexander Neundorf wrote: On Sunday 06 February 2011, Eric Noulard wrote: 2011/2/5 Alexander Neundorf neund...@kde.org: Hi, in general we keep cmake as backward compatible as possible, so no builds are broken. In a local branch I have a version of cmake with a small improvement to the graphviz support in cmake. It turns the variable GRAPHVIZ_IGNORE_TARGETS from a list of strings into a list of regular expressions. I.e. everything which was before in GRAPHVIZ_IGNORE_TARGETS and excluded from the dot-files, is now still excluded, but now there may be more targets excluded (e.g. for kio now not only kio is excluded, but also kio_ftp etc.) Also, with this change, the variable GRAPHVIZ_TARGET_IGNORE_REGEX is not supported anymore, so targets previously excluded from the dot-files via this (one) regex are now included. Both issues can be fixed by, for the first, putting ^...$ around the string, and for the second by just putting the regex now into GRAPHVIZ_IGNORE_TARGETS . Strictly speaking, this breaks compatibility regarding the graphviz support. But, do we care about this ? * it is and was completely undocumented (will write a wiki page soon) * the changes don't influence the build itself, so no build can be broken by this change What do you think ? I think that, I didn't even know the existence of this, so I wouldn't care about breaking it :-] Moreover I am basically ok that the breakage of an undocumented feature is not a real breakage. Now may be you can: 1) rename GRAPHVIZ_IGNORE_TARGETS to CMAKE_GRAPHVIZ_IGNORE_TARGETS which is more consistent with other var names. 2) check GRAPHVIZ_IGNORE_TARGETS and GRAPHVIZ_TARGET_IGNORE_REGEX and issue a WARNING if they are used. 2) may even be unecessary with the new --warn-unused-vars option. the baseline is if you break it, then break it ALL there won't be any confusion. I could also make these variables cache variables. That's IMO easier to use and also better discoverable. With GRAPHVIZ_IGNORE_TARGETS they would be all in the GRAPHVIZ subtree, with CMAKE_GRAPHVIZ_IGNORE_TARGETS they would be all together with the other cmake variables in the CMAKE subtree. Being in a GRAPHVIZ subtree would make them easier to spot, so maybe I'd prefer this. But I don't have a strong opinion. Other comments ? I guess this means that backward compatibility is no issue here. Eric, what do you think about the naming and whether make them cache variables or not ? Naming scheme with GRAPHVIZ prefix is good you are right for the subtree thing. Caching looks ok too, I don't think such var needs to be seen at first sight. My opinion may not be that valuable in this area because I'm not using the feature :-] Now the argument of the subtree is a good one even if we can think that sub-subtree (more than one level tree) may be implemented in cmake-gui too. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] CPACK_STRIP_FILES has no effect on DSOs
2011/2/11 Moritz Moeller realr...@virtualritz.com: On 02/11/2011 09:56 AM, Moritz Moeller wrote: None of the DSOs gets stripped. Is this intentional with shared libs? Any workaround or anything I am missing? So I worked around this myself by setting set( CMAKE_MODULE_LINKER_FLAGS -s ) And I am aware I can manually do a make install/strip I'd still like to know why the CPack flag doesn't work as advertised. :) Which kind of CPack package are you building? DEB, RPM, TGZ, etc... Would you be able to craft a simple project reproducing 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_STRIP_FILES has no effect on DSOs
2011/2/11 Moritz Moeller realr...@virtualritz.com: On 02/11/2011 10:57 AM, Eric Noulard wrote: Which kind of CPack package are you building? DEB, RPM, TGZ, etc... I am building a tbz2. But this should happen long before the package is compressed, innit. Nope. With CPACK_STRIP_FILES strip is called by CPack when CPack is installing (in a local CPack-specific install tree) the package before building the package. This process is normally shared by all generators. So you may perfectly have shared lib in your build tree which are not stripped and get them stripped in the package. Would you be able to craft a simple project reproducing the problem? Not sure. This is big project, 2 dozen sub-folders with their own CMakeLists, 50k lines of code. I can't really justify devoting any time to this, now that I found a workaround. :P I may be able carve out some time next week to make a simple test case. I understand. That's just there is a better chance of fix if we get a test case. -- 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] CPack RPM in next RC (if there is one)?
2011/2/8 Brad King brad.k...@kitware.com: On 02/06/2011 03:58 PM, Eric Noulard wrote: if there is one RC left before 2.8.4 it would be nice to include this patchset. Does this fix a regression from a previous release? No this is not a regression fix. Just a wish to have ArchiveGenerator at the same level of component packaging support in the same version. 2.8.3 has component support for ArchiveGenerator (with a regression against 2.8.2 which is fixed in 2.8.4-rc's) and no component support at all for RPMGenerator. 2.8.4-rc2 has component for both ArchiveGenerator and RPMGenerator but not at the same level. not a big deal but this is a consistency request. If there is no RC left then I'll wait for 2.8.5 and try to be more on-time next time :-] If there are could you tell us how many (1 or 2) and the approximate release date. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Automatic out of source build's possible?
2011/2/8 Martin O'Brien martin.matthew.obr...@gmail.com: While I too find myself sometimes wanting convenience scripts - some people find the use of '-DENABLE_whatever=ON' instead of --enable-whatever' foreign, for example - the problem with them, IMO, is that they're impossible to make crossplatform without requiring the presence of some tool - perl, python, bash, whatever - on each system in a location that can be located pre-configure, which is exactly what using cmake gets you out of. You can use CMake instead of perl, python etc... you write your CMake script and then propose to the user to run, something like: cmake -P easyBuild.cmake Many [portable] CMake commands are usable for that, mainly file( ...), execute_process, string, message. As an example I did propose in the past a CMake script which can be used to build a new CMake version (provided you already have one installed) with the following single line: cmake -P CMake-autobuild.cmake You can write a similar cross-platform script(s) for your users. It doesn't give you the possibility to use --enable but it's easy to use for your user and is definitely cross-platform. If some options have to be chosen by the users they can either edit the script or you may launch cmake-gui / ccmake at the end of the script in order to give a chance to the user to select the choices. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org CMake-autobuild.cmake Description: Binary data ___ 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] Automatic out of source build's possible?
2011/2/8 Michael Wild them...@gmail.com: And there's the hidden trap that the -D options must be *before* the -P option. Very nasty, especially for people who never used CMake before. Yes right I was caught by that in the past. On 02/08/2011 09:27 AM, Martin O'Brien wrote: Absolutely, and that is what I do in some cases, but in the particular case that I described - which is what I had in mind; I should have been clearer - it doesn't help, as it's still -D... syntax. Ok then may be you can propose a patch for some generic --enable- --disable- cmake command line option that will be automatically translated to -D=ON seems do-able. I don't know if many people would like 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] Automatic out of source build's possible?
2011/2/8 Martin O'Brien martin.matthew.obr...@gmail.com: I've resisted the urge to patch, since I really don't want to be dependent on a custom version of CMake. My idea was more like proposing a feature request + patch in order to make the feature go in upstream CMake. I cannot ensure it will but... As far as how many people would like it, I don't know, but my guess would be that most who were more familiar with configure or really anything that Getopt long-ish than CMake would probably find it more familiar. this may be discussed by people listening to the list :-] My opinion is that it's sometimes annoying to have several ways to do something (-D OPT=ON vs --enable-opt) but it can ease the transition and/or some common place way to handle option on the command line. What I've done in the past in a few cases where people complained mightily (as well as pretty unreasonably, as this is hardly end of the world) was: -DCONFIGOPTS=--enable-whatever --verbose --debug... AND/OR -DCONFIGOPTSFILE=somefile which contained options, one per line And then parse that/those (using a cmake module). Very ugly, but they could usually handle that with much less complaining, and it also prevented potential conflicts with cmake '--' options. I see. -- 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: CPACK_COMPONENT_GROUP in cmake 2.8.3 / Windows binary zip
2011/2/8 Clinton Stimpson clin...@elemtech.com: I also saw that warning with this example (there's nothing in this example about a MONOLITHIC install): cmake_minimum_required(VERSION 2.8) project(hello) install(CODE message(installing...) COMPONENT Hello) set(CPACK_COMPONENTS_ALL Hello) set(CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE 1) set(CPACK_ARCHIVE_COMPONENT_INSTALL 1) include(CPack) $ cpack -G TGZ Why is it a warning if no groups are defined? Is it because one should use groups? However, I can suppress that warning with set(CPACK_COMPONENTS_IGNORE_GROUPS 1) Oh sorry.. This isn't related... Anyway, I was seeing a different warning: CPack Warning: [TGZ] Some Components defined but NO component group: Ignoring component group. Ok good. I tried my best to generate warning about possible misuse of component setttings However I did not include a way to turn those warnings OFF I'll try to do it before 2.8.5, just in case I did over-warn. -- 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 components archive generators
2011/2/7 Clinton Stimpson clin...@elemtech.com:
Is there a reason the archive generators append -ALL to the package file
name
I specify when I set CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE=1?
Can we leave that to the user to decide if they want -ALL by putting it in
CPACK_PACKAGE_FILE_NAME?
Yes there is.
It is to makes it clear that your requested a ALL-IN-ONE package
mainly because *-ALL packages may not have the same content as MONOLITHIC
which do not get the extra -ALL.
If you use 2.8.4-rcX you will be able to use CPACK_MONOLITHIC_INSTALL
http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#Controlling_Differents_Ways_of_packaging_components
in order to get ALL-IN-ONE package without the extra -ALL.
CPACK_MONOLITHIC_INSTALL is now handled at CPack time too so that
you can get monolothic install on a per-generator basis if you use
a CPACK_PROJECT_CONFIG_FILE
see:
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29
Now we can makes it easier fo control the name mangling scheme of
the multi-files component generators (Archive, RPM and the next to come)
if you have some proposal in mind please go ahead.
Currently the naming scheme is:
${CPACK_PACKAGE_FILE_NAME}-ALL.ext for ALL-IN-ONE package
${CPACK_PACKAGE_FILE_NAME}-ComponentName.ext for the 1 file per
component case
${CPACK_PACKAGE_FILE_NAME}-ComponentName.ext for the 1 file per
component group case
We can add some extra vars to control the name mangling scheme for
ALL cases.
Note that CMake 2.8.3 had a backward compatibility breakage
http://public.kitware.com/Bug/view.php?id=11452
which makes archive generator generate componentized package the default.
2.8.4 won't and became backward compatible again with 2.8.2.
With 2.8.4 and up you'll have to
set(CPACK_ARCHIVE_COMPONENT_INSTALL ON)
to get componentized archive.
(this may be specified on CPack command line or in CPACK_PROJECT_CONFIG_FILE too
i.e. it is handled at CPack time)
--
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 components archive generators
2011/2/7 Clinton Stimpson clin...@elemtech.com:
On Monday, February 07, 2011 01:38:22 pm Eric Noulard wrote:
2011/2/7 Clinton Stimpson clin...@elemtech.com:
Is there a reason the archive generators append -ALL to the package
file name I specify when I set CPACK_COMPONENTS_ALL_IN_ONE_PACKAGE=1?
Can we leave that to the user to decide if they want -ALL by putting it
in CPACK_PACKAGE_FILE_NAME?
Yes there is.
It is to makes it clear that your requested a ALL-IN-ONE package
mainly because *-ALL packages may not have the same content as MONOLITHIC
which do not get the extra -ALL.
I know what I'm asking for :) A subset of components go into one package
file.
I was wondering if there was some issue such as one config file generating
both
all-in-one and monolith packages, in which case a filename distinction might
be
necessary. If separate config files are necessary, or if one can control this
in CPACK_PROJECT_CONFIG_FILE, then I don't really see a need for adding -
ALL.
No there no config issue.
Just a silly idea of mine to differentiate package type from name
and OK you are right adding -ALL is a bad idea.
By the way, I think -ALL could be misleading because it may not contain all
components (only the ones given in CPACK_COMPONENTS_ALL) where the monolith
package will include them all. Also, -ALL isn't added when I use the NSIS
generator with the same config file.
Yes right again, even if NSIS always generate a single file.
But you are right, I'm convinced that this was a non-sense idea,
I'll remove the -ALL suffix the idea was just a bad idea.
But, I could add a step of renaming the files I get out of it.
No you are right I will remove the ALL suffix, I hope I'll get a chance
to do it before 2.8.4 is released.
Currently the naming scheme is:
${CPACK_PACKAGE_FILE_NAME}-ALL.ext for ALL-IN-ONE package
${CPACK_PACKAGE_FILE_NAME}-ComponentName.ext for the 1 file per
component case
${CPACK_PACKAGE_FILE_NAME}-ComponentName.ext for the 1 file per
component group case
We can add some extra vars to control the name mangling scheme for
ALL cases.
Or just use the already existing *_DISPLAY_NAME variables?
OK again that's a very pertinent remark.
I'll use *_DISPLAY_NAME if they are defined and then the previous
scheme if they don't.
The only possible drawback would be to get filename with embedded whitespace,
which is unusual (and sometime anoying) on Unix for die-hard command line user
because you'll have to escape them.
What do you think?
I'll try to work on this later during this week
(after the next -- master turn-around because I already have 2 patchset
in the pipe) or may be you'd like to propose a patch yourself ?
Could you file a bug report concerning this naming scheme issue,
I'll assign it to me right after.
Thank you very much for your remark.
--
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/NSIS and launching the application after the installation completed
2011/2/7 Crni Gorac cgo...@gmail.com: On Mon, Feb 7, 2011 at 10:09 PM, David Cole david.c...@kitware.com wrote: [ ... ] The commit to fix this bug is in the 2.8.4-rc2 release candidate: http://public.kitware.com/Bug/view.php?id=11144 With it, you can set CPACK_NSIS_MUI_FINISHPAGE_RUN to an executable in your installation directory, and it will generate a page with a checkbox on it, giving the end user the choice of running or not running... Thanks Clinton and David for replying. I tried what David suggested, after switching to CMake 2.8.4-rc2, and it worked like charm. Let me just mention that you need to cite only the name of the executable in CPACK_NSIS_MUI_FINISHPAGE_RUN: I have it installed in bin subdirectory of the install directory, but in that case you should not mention bin here, or otherwise the executable won't be run (it helps to examine generated NSIS script for debugging here). It would be nice to update the Wiki with this information: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#NSIS -- 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] Work on the graphviz support - compatibility ?
2011/2/5 Alexander Neundorf neund...@kde.org: Hi, in general we keep cmake as backward compatible as possible, so no builds are broken. In a local branch I have a version of cmake with a small improvement to the graphviz support in cmake. It turns the variable GRAPHVIZ_IGNORE_TARGETS from a list of strings into a list of regular expressions. I.e. everything which was before in GRAPHVIZ_IGNORE_TARGETS and excluded from the dot-files, is now still excluded, but now there may be more targets excluded (e.g. for kio now not only kio is excluded, but also kio_ftp etc.) Also, with this change, the variable GRAPHVIZ_TARGET_IGNORE_REGEX is not supported anymore, so targets previously excluded from the dot-files via this (one) regex are now included. Both issues can be fixed by, for the first, putting ^...$ around the string, and for the second by just putting the regex now into GRAPHVIZ_IGNORE_TARGETS . Strictly speaking, this breaks compatibility regarding the graphviz support. But, do we care about this ? * it is and was completely undocumented (will write a wiki page soon) * the changes don't influence the build itself, so no build can be broken by this change What do you think ? I think that, I didn't even know the existence of this, so I wouldn't care about breaking it :-] Moreover I am basically ok that the breakage of an undocumented feature is not a real breakage. Now may be you can: 1) rename GRAPHVIZ_IGNORE_TARGETS to CMAKE_GRAPHVIZ_IGNORE_TARGETS which is more consistent with other var names. 2) check GRAPHVIZ_IGNORE_TARGETS and GRAPHVIZ_TARGET_IGNORE_REGEX and issue a WARNING if they are used. 2) may even be unecessary with the new --warn-unused-vars option. the baseline is if you break it, then break it ALL there won't be any confusion. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
