[CMake] Multi-component packaging support
I have following requirement: I have big source tree (~100 projects -
libraries or binaries), and want to package them in different ways. And
encapsulate packaging knowledge in single place.
That is I want that some libraries may enter into different packages. That is
pakcageA contains libA and libB, packageA-devel contains libA-static and
libB-static and libA-headers, packageB contains libB and libX, and so on.
Obviously, I can't specify it in install command, because when I write
CMakeLists.txt for some library, I don't know which package it will belong
to.
Other words, I want somewhere in top-level makefile to write something like
add_install_package(packageA libA libB)
add_install_package(packageA-devel libA-static libB-static libA-headers)
add_install_package(packageB libB libX)
and later, to install particular package, I should call something like
make install_package_packageA
Also, it will be very helpfull to have some kind of install manifest for whole
package. It will simplify packaging on different platforms (wither with or
without CPack). For example, you can tell rpmbuild to get file list form text
file rather than specifying them in .spec. Same way I can wrap other
packaging tools on windows.
Now, I came to following solution: put every library into separate component
with same name: install(TARGETS libA COMPONENT libA)
Next, add custom target:
add_custom_target(install_packageA
COMMAND ${CMAKE_COMMAND}
-DINSTALL_PACKAGE_NAME:STRING=packageA
-DINSTALL_COMPONENTS:STRING=libA libB
-H${CMAKE_SOURCE_DIR}
-B${CMAKE_BINARY_DIR}
-P ${CMAKE_SOURCE_DIR}/build/InstallHelper.cmake
COMMENT Installing package packageA
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
)
where InstallHelper.cmake is:
# Convert space-separated string into list.
separate_arguments(INSTALL_COMPONENTS)
# Install components
foreach(component ${INSTALL_COMPONENTS})
# Set component
set(CMAKE_INSTALL_COMPONENT ${component})
message(STATUS Processing component ${CMAKE_INSTALL_COMPONENT})
# Run install script with active component
include(${CMAKE_BINARY_DIR}/cmake_install.cmake)
endforeach(component)
set(_manifest_file
${CMAKE_BINARY_DIR}/install_manifest_${INSTALL_PACKAGE_NAME}.txt)
# Truncate output manifest file.
file(WRITE ${_manifest_file} )
# Append installed files to manifest.
foreach(file ${CMAKE_INSTALL_MANIFEST_FILES})
file(APPEND ${_manifest_file} ${file}\n)
endforeach(file)
Is there more straight-forward way to do same things? Possibly, with CPack,
but I don't completely understand one's architecture yet.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Sun GCC builds (cooltools)
Brad, More info compiling with SUN GCC 4.2 (cooltools) on sun sparc. I think I have narrowed it to HAVE_POSIX_STRERROR_R not being defined in Utilities/cmcurl. It seems strange since it compiles and produces the expected results when I do it by hand. -bash-3.00$ env | grep CC CC=/opt/gcc/bin/gcc -bash-3.00$ $CC -DHAVE_POSIX_STRERROR_R CurlTests.c -bash-3.00$ ./a.out -bash-3.00$ ./a.out ; echo $? 0 This appears to be the cause of my troubles, Linking C executable cmTryCompileExec /export/home/gneill/src/build/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec.dir/link.txt --verbose=1 /opt/gcc/bin/gcc -DHAVE_POSIX_STRERROR_R -fPIC CMakeFiles/cmTryCompileExec.dir/CurlTests.c.o -o cmTryCompileExec -ldl -lsocket -lnsl -lcrypto -lssl ld.so.1: cmTryCompileExec: fatal: libcrypto.so.0.9.7: open failed: No such file or directory Child killed libcrypto.so.0.9.7 and libssl.so.0.9.7 are in /usr/sfw/lib on my system (but they are certainly not in my LD_LIBRARY_PATH or system path) so I am not sure why it's trying to use those. -bash-3.00$ crle Default configuration file (/var/ld/ld.config) not found Default Library Path (ELF): /lib:/usr/lib (system default) Trusted Directories (ELF):/lib/secure:/usr/lib/secure (system default) -bash-3.00$ echo $LD_LIBRARY_PATH I will do some more digging ... Thanks, George. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Sun GCC builds (cooltools)
Brad, I will do some more digging ... So this is why the CMake SS12 compile works, -bash-3.00$ /opt/SUNWspro/bin/cc -lcrypto -lssl test.c ld: fatal: library -lcrypto: not found ld: fatal: library -lssl: not found ld: fatal: File processing errors. No output written to a.out and this is why the SUN GCC 4.2.0 (cooltools) compile fails. -bash-3.00$ /opt/gcc/bin/gcc -lcrypto -lssl test.c -bash-3.00$ ./a.out ld.so.1: a.out: fatal: libcrypto.so.0.9.7: open failed: No such file or directory Killed The pre-installed /usr/sfw/bin/gcc (3.4.3) compiles/runs just fine. -bash-3.00$ /usr/sfw/bin/gcc -lcrypto -lssl test.c -bash-3.00$ ./a.out Hello there. So I guess the temporary fix is to just .. export LD_LIBRARY_PATH=/usr/sfw/lib:$LD_LIBRARY_PATH before the bootstrap. Later, George. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Sun GCC builds (cooltools)
Brad,
This proved to be useful for me, if it is worth including ...
-bash-3.00$ cvs diff CMakeLists.txt
Index: CMakeLists.txt
===
RCS file: /cvsroot/CMake/CMake/Utilities/cmcurl/CMakeLists.txt,v
retrieving revision 1.19
diff -r1.19 CMakeLists.txt
521a522,526
IF(${${CURL_TEST}} MATCHES FAILED_TO_RUN)
MESSAGE(FATAL_ERROR Unable to run test for ${CURL_TEST}. Command
output is ${OUTPUT})
ENDIF(${${CURL_TEST}} MATCHES FAILED_TO_RUN)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Sun GCC builds (cooltools)
George Neill wrote: and this is why the SUN GCC 4.2.0 (cooltools) compile fails. -bash-3.00$ /opt/gcc/bin/gcc -lcrypto -lssl test.c -bash-3.00$ ./a.out ld.so.1: a.out: fatal: libcrypto.so.0.9.7: open failed: No such file or directory Killed The pre-installed /usr/sfw/bin/gcc (3.4.3) compiles/runs just fine. -bash-3.00$ /usr/sfw/bin/gcc -lcrypto -lssl test.c -bash-3.00$ ./a.out Hello there. So I guess the temporary fix is to just .. export LD_LIBRARY_PATH=/usr/sfw/lib:$LD_LIBRARY_PATH Sounds like the pre-installed gcc is broken. That path should be in some sort of system path. Thanks for looking into this. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] [CPack.cmake] take into account CPACK_PACKAGE_VERSION_xxxxxxxxx only once
Hi,
I have noticed that the overwriting of CPACK_PACKAGE_VERSION have no impact
on the .deb packages file name (and have impact on sources packages).
I propose to use the CPACK_PACKAGE_VERSION_x macros only once to set
(if not set !) the CPACK_PACKAGE_VERSION and then only use the
CPACK_PACKAGE_VERSION macro:
Index: Modules/CPack.cmake
===
RCS file: /cvsroot/CMake/CMake/Modules/CPack.cmake,v
retrieving revision 1.35
diff -u -r1.35 CPack.cmake
--- Modules/CPack.cmake26 Dec 2007 21:57:13 -1.35
+++ Modules/CPack.cmake21 Mar 2008 14:30:09 -
@@ -73,7 +73,7 @@
# project-major.minor.patch-release-platform.pkgtype
cpack_set_if_not_set(CPACK_PACKAGE_FILE_NAME
-
${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}-${CPACK_SYSTEM_NAME})
+ ${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION})
cpack_set_if_not_set(CPACK_PACKAGE_INSTALL_DIRECTORY
${CPACK_PACKAGE_NAME} ${CPACK_PACKAGE_VERSION})
cpack_set_if_not_set(CPACK_PACKAGE_INSTALL_REGISTRY_KEY
@@ -202,7 +202,7 @@
${CMAKE_SOURCE_DIR};/)
cpack_set_if_not_set(CPACK_SOURCE_TOPLEVEL_TAG
${CPACK_SYSTEM_NAME}-Source)
cpack_set_if_not_set(CPACK_SOURCE_PACKAGE_FILE_NAME
-
${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}-Source)
+ ${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION}-Source)
cpack_set_if_not_set(CPACK_SOURCE_IGNORE_FILES
/CVS/;/.svn/;.swp$;.#;/#)
SET(CPACK_INSTALL_CMAKE_PROJECTS ${CPACK_SOURCE_INSTALL_CMAKE_PROJECTS})
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Sun GCC builds (cooltools)
Bill, Sounds like the pre-installed gcc is broken. That path should be in some sort of system path. Thanks for looking into this. You bet. The pre-installed (gcc 3.4.3) works fine. But it looks like the SUN gcc 4.2.0 cooltools compiler has some kind of pathing issue going on with it (or I have screwed something up! .. which is quite possible). I suppose we'll find out. http://forum.java.sun.com/thread.jspa?threadID=5277589 Later, George. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Getting Makefiles sensitive tonew/deleted files/directories?
Can you do the glob, configure the result out to a file, then INCLUDE
that
file. I believe that will solve the problem. Something like
file(GLOB SRC *.cpp)
configure_file(somefile.in somefile)
include(somefile)
where somefile.in looks like
# list of files as a comment -- ${SRC}
This works because CMake does check (at make time) to see if any
included
file in CMake has changed but is smart in that configure_file only
writes
the file if it has changed. I'm pretty sure something like that will
work.
Thinking about this some more I think you could add a custom target that
does the glob at build time, and stores the results in a file that gets
included by CMake. So what would happen is:
cmake -- files are globbed and used as well as written into a files.last
make -- files are globbed and written into a files.last if different
(which at this point they are not)
joe schmo adds some new files into the tree
make -- files are globbed and written into a files.last if different
(which they will be) the build will probably fail as the makefiles do not
have the new files
make -- detects that files.last is different and reruns cmake producing
valid makefiles with the new source files.
Not a great solution as the build can fail the first time new files are
added but ...meh...really the fix is to have Cmake handle this if it can be
handled without making other builds that do glob for other reasons not slow
down.
Ken
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
