wbtiger
/
foundationdb
mirror of https://github.com/apple/foundationdb.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
foundationdb/cmake/InstallLayout.cmake

460 lines
20 KiB
CMake
Raw Normal View History

docker-compose can now build rpm weirdly it still generates a foundationd-unspecified rpm. However, it is empty and can be ignored for now
2019-02-11 12:51:36 +08:00
################################################################################
# Helper Functions
################################################################################
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
function(install_symlink_impl)
Put rpm, deb, or msi into the packages folder This additionally fixes a dependency bug on Windows
2019-02-17 04:07:52 +08:00
if (NOT WIN32)
set(options "")
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
set(one_value_options TO DESTINATION)
set(multi_value_options COMPONENTS)
Put rpm, deb, or msi into the packages folder This additionally fixes a dependency bug on Windows
2019-02-17 04:07:52 +08:00
cmake_parse_arguments(SYM "${options}" "${one_value_options}" "${multi_value_options}" "${ARGN}")
file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/symlinks)
get_filename_component(fname ${SYM_DESTINATION} NAME)
get_filename_component(dest_dir ${SYM_DESTINATION} DIRECTORY)
set(sl ${CMAKE_CURRENT_BINARY_DIR}/symlinks/${fname})
execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ${SYM_TO} ${sl})
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
foreach(component IN LISTS SYM_COMPONENTS)
install(FILES ${sl} DESTINATION ${dest_dir} COMPONENT ${component})
endforeach()
Put rpm, deb, or msi into the packages folder This additionally fixes a dependency bug on Windows
2019-02-17 04:07:52 +08:00
endif()
docker-compose can now build rpm weirdly it still generates a foundationd-unspecified rpm. However, it is empty and can be ignored for now
2019-02-11 12:51:36 +08:00
endfunction()
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
function(install_symlink)
if(NOT WIN32 AND NOT OPEN_FOR_IDE)
set(options "")
set(one_value_options COMPONENT LINK_DIR FILE_DIR LINK_NAME FILE_NAME)
set(multi_value_options "")
cmake_parse_arguments(IN "${options}" "${one_value_options}" "${multi_value_options}" "${ARGN}")
Some more improvements to the build and preparations for packaging
2018-05-06 00:43:50 +08:00
fixed cmake generated symlinks
2019-03-03 02:58:54 +08:00
set(rel_path "")
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
string(REGEX MATCHALL "\\/" slashes "${IN_LINK_NAME}")
fixed cmake generated symlinks
2019-03-03 02:58:54 +08:00
foreach(ignored IN LISTS slashes)
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
set(rel_path "../${rel_path}")
endforeach()
if("${IN_FILE_DIR}" MATCHES "bin")
if("${IN_LINK_DIR}" MATCHES "lib")
install_symlink_impl(
fixed cmake generated symlinks
2019-03-03 02:58:54 +08:00
TO "../${rel_path}bin/${IN_FILE_NAME}"
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
DESTINATION "lib/${IN_LINK_NAME}"
COMPONENTS "${IN_COMPONENT}-tgz")
install_symlink_impl(
fixed cmake generated symlinks
2019-03-03 02:58:54 +08:00
TO "../${rel_path}bin/${IN_FILE_NAME}"
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
DESTINATION "usr/lib64/${IN_LINK_NAME}"
COMPONENTS "${IN_COMPONENT}-el6"
"${IN_COMPONENT}-el7"
"${IN_COMPONENT}-deb")
install_symlink_impl(
fixed cmake generated symlinks
2019-03-03 02:58:54 +08:00
TO "../${rel_path}bin/${IN_FILE_NAME}"
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
DESTINATION "usr/lib64/${IN_LINK_NAME}"
COMPONENTS "${IN_COMPONENT}-deb")
elseif("${IN_LINK_DIR}" MATCHES "bin")
install_symlink_impl(
fixed cmake generated symlinks
2019-03-03 02:58:54 +08:00
TO "../${rel_path}bin/${IN_FILE_NAME}"
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
DESTINATION "bin/${IN_LINK_NAME}"
COMPONENTS "${IN_COMPONENT}-tgz")
install_symlink_impl(
fixed cmake generated symlinks
2019-03-03 02:58:54 +08:00
TO "../${rel_path}bin/${IN_FILE_NAME}"
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
DESTINATION "usr/bin/${IN_LINK_NAME}"
COMPONENTS "${IN_COMPONENT}-el6"
"${IN_COMPONENT}-el7"
"${IN_COMPONENT}-deb")
several minor bug fixes
2019-03-03 06:05:05 +08:00
elseif("${IN_LINK_DIR}" MATCHES "fdbmonitor")
install_symlink_impl(
TO "../../${rel_path}bin/${IN_FILE_NAME}"
DESTINATION "lib/foundationdb/${IN_LINK_NAME}"
COMPONENTS "${IN_COMPONENT}-tgz")
install_symlink_impl(
TO "../../${rel_path}bin/${IN_FILE_NAME}"
DESTINATION "usr/lib/foundationdb/${IN_LINK_NAME}"
COMPONENTS "${IN_COMPONENT}-el6"
"${IN_COMPONENT}-el7"
"${IN_COMPONENT}-deb")
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
else()
message(FATAL_ERROR "Unknown LINK_DIR ${IN_LINK_DIR}")
endif()
else()
message(FATAL_ERROR "Unknown FILE_DIR ${IN_FILE_DIR}")
endif()
endif()
endfunction()
docker container and docker-compose for cmake This is still in the testing-phase. However, it should be mostly functional
2019-02-11 07:50:11 +08:00
Changed the name of a cmake functions Added working directory for cmake command
2019-12-12 05:59:03 +08:00
function(symlink_files)
Added support for creating symlinks to fdbbackup within bin and packages/bin directory
2019-12-11 03:35:18 +08:00
if (NOT WIN32)
set(options "")
set(one_value_options LOCATION SOURCE)
set(multi_value_options TARGETS)
cmake_parse_arguments(SYM "${options}" "${one_value_options}" "${multi_value_options}" "${ARGN}")
file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/${SYM_LOCATION})
foreach(component IN LISTS SYM_TARGETS)
Changed the name of a cmake functions Added working directory for cmake command
2019-12-12 05:59:03 +08:00
execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ${SYM_SOURCE} ${CMAKE_BINARY_DIR}/${SYM_LOCATION}/${component} WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/${SYM_LOCATION})
Added support for creating symlinks to fdbbackup within bin and packages/bin directory
2019-12-11 03:35:18 +08:00
endforeach()
endif()
endfunction()
Use 'map' for finding install paths
2019-05-23 07:09:04 +08:00
# 'map' from (destination, package) to path
# format vars like install_destination_for_${destination}_${package}
set(install_destination_for_bin_tgz "bin")
set(install_destination_for_bin_deb "usr/bin")
set(install_destination_for_bin_el6 "usr/bin")
set(install_destination_for_bin_el7 "usr/bin")
set(install_destination_for_bin_pm "usr/local/bin")
set(install_destination_for_sbin_tgz "sbin")
set(install_destination_for_sbin_deb "usr/sbin")
set(install_destination_for_sbin_el6 "usr/sbin")
set(install_destination_for_sbin_el7 "usr/sbin")
set(install_destination_for_sbin_pm "usr/local/libexec")
set(install_destination_for_lib_tgz "lib")
set(install_destination_for_lib_deb "usr/lib")
set(install_destination_for_lib_el6 "usr/lib64")
set(install_destination_for_lib_el7 "usr/lib64")
set(install_destination_for_lib_pm "lib")
Put fdbmonitor into `sbin` dir in tgz-package Fixes #1753
2019-07-24 00:40:33 +08:00
set(install_destination_for_fdbmonitor_tgz "sbin")
Use 'map' for finding install paths
2019-05-23 07:09:04 +08:00
set(install_destination_for_fdbmonitor_deb "usr/lib/foundationdb")
set(install_destination_for_fdbmonitor_el6 "usr/lib/foundationdb")
set(install_destination_for_fdbmonitor_el7 "usr/lib/foundationdb")
set(install_destination_for_fdbmonitor_pm "usr/local/libexec")
set(install_destination_for_include_tgz "include")
set(install_destination_for_include_deb "usr/include")
set(install_destination_for_include_el6 "usr/include")
set(install_destination_for_include_el7 "usr/include")
set(install_destination_for_include_pm "usr/local/include")
set(install_destination_for_etc_tgz "etc/foundationdb")
set(install_destination_for_etc_deb "etc/foundationdb")
set(install_destination_for_etc_el6 "etc/foundationdb")
set(install_destination_for_etc_el7 "etc/foundationdb")
set(install_destination_for_etc_pm "usr/local/etc/foundationdb")
set(install_destination_for_log_tgz "log/foundationdb")
set(install_destination_for_log_deb "var/log/foundationdb")
set(install_destination_for_log_el6 "var/log/foundationdb")
set(install_destination_for_log_el7 "var/log/foundationdb")
set(install_destination_for_log_pm "")
set(install_destination_for_data_tgz "lib/foundationdb")
set(install_destination_for_data_deb "var/lib/foundationdb")
set(install_destination_for_data_el6 "var/lib/foundationdb")
set(install_destination_for_data_el7 "var/lib/foundationdb")
set(install_destination_for_data_pm "")
Support pkg-config
2019-05-24 05:13:07 +08:00
set(generated_dir "${CMAKE_CURRENT_BINARY_DIR}/generated")
function(fdb_configure_and_install)
if(NOT WIN32 AND NOT OPEN_FOR_IDE)
set(one_value_options COMPONENT DESTINATION FILE DESTINATION_SUFFIX)
cmake_parse_arguments(IN "${options}" "${one_value_options}" "${multi_value_options}" "${ARGN}")
foreach(package tgz deb el6 el7 pm)
set(INCLUDE_DIR "${install_destination_for_include_${package}}")
set(LIB_DIR "${install_destination_for_lib_${package}}")
set(install_path "${install_destination_for_${IN_DESTINATION}_${package}}")
string(REGEX REPLACE "\.in$" "" name "${IN_FILE}")
get_filename_component(name "${name}" NAME)
set(generated_file_name "${generated_dir}/${package}/${name}")
configure_file("${IN_FILE}" "${generated_file_name}" @ONLY)
install(
FILES "${generated_file_name}"
DESTINATION "${install_path}${IN_DESTINATION_SUFFIX}"
COMPONENT "${IN_COMPONENT}-${package}")
endforeach()
endif()
endfunction()
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
function(fdb_install)
if(NOT WIN32 AND NOT OPEN_FOR_IDE)
Prepare for exporting fdb_c
2019-05-24 02:15:39 +08:00
set(one_value_options COMPONENT DESTINATION EXPORT DESTINATION_SUFFIX)
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
set(multi_value_options TARGETS FILES DIRECTORY)
cmake_parse_arguments(IN "${options}" "${one_value_options}" "${multi_value_options}" "${ARGN}")
docker container and docker-compose for cmake This is still in the testing-phase. However, it should be mostly functional
2019-02-11 07:50:11 +08:00
include(/path/to/cmake/file) now works for fdb_c
2019-05-24 02:46:31 +08:00
set(install_export 0)
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
if(IN_TARGETS)
set(args TARGETS ${IN_TARGETS})
elseif(IN_FILES)
set(args FILES ${IN_FILES})
elseif(IN_DIRECTORY)
set(args DIRECTORY ${IN_DIRECTORY})
include(/path/to/cmake/file) now works for fdb_c
2019-05-24 02:46:31 +08:00
elseif(IN_EXPORT)
set(install_export 1)
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
else()
message(FATAL_ERROR "Expected FILES or TARGETS")
endif()
Use 'map' for finding install paths
2019-05-23 07:09:04 +08:00
foreach(package tgz deb el6 el7 pm)
set(install_path "${install_destination_for_${IN_DESTINATION}_${package}}")
include(/path/to/cmake/file) now works for fdb_c
2019-05-24 02:46:31 +08:00
if(install_export)
Prepare for exporting fdb_c
2019-05-24 02:15:39 +08:00
install(
include(/path/to/cmake/file) now works for fdb_c
2019-05-24 02:46:31 +08:00
EXPORT "${IN_EXPORT}-${package}"
Prepare for exporting fdb_c
2019-05-24 02:15:39 +08:00
DESTINATION "${install_path}${IN_DESTINATION_SUFFIX}"
include(/path/to/cmake/file) now works for fdb_c
2019-05-24 02:46:31 +08:00
FILE "${IN_EXPORT}.cmake"
Prepare for exporting fdb_c
2019-05-24 02:15:39 +08:00
COMPONENT "${IN_COMPONENT}-${package}")
include(/path/to/cmake/file) now works for fdb_c
2019-05-24 02:46:31 +08:00
else()
set(export_args "")
if (IN_EXPORT)
set(export_args EXPORT "${IN_EXPORT}-${package}")
endif()
if(NOT ${install_path} STREQUAL "")
install(
${args}
${export_args}
DESTINATION "${install_path}${IN_DESTINATION_SUFFIX}"
COMPONENT "${IN_COMPONENT}-${package}")
endif()
Use 'map' for finding install paths
2019-05-23 07:09:04 +08:00
endif()
endforeach()
docker-compose can now build rpm weirdly it still generates a foundationd-unspecified rpm. However, it is empty and can be ignored for now
2019-02-11 12:51:36 +08:00
endif()
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
endfunction()
Some more improvements to the build and preparations for packaging
2018-05-06 00:43:50 +08:00
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
if(APPLE)
Use productbuild instead of PackageMaker on MacOS fixes #1547 fixes #1549
2019-05-12 05:42:48 +08:00
set(CPACK_GENERATOR TGZ productbuild)
Fix merge conflicts
2019-02-08 08:35:08 +08:00
else()
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
set(CPACK_GENERATOR RPM DEB TGZ)
Fix merge conflicts
2019-02-08 08:35:08 +08:00
endif()
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
set(CPACK_PACKAGE_CHECKSUM SHA256)
Use productbuild instead of PackageMaker on MacOS fixes #1547 fixes #1549
2019-05-12 05:42:48 +08:00
configure_file("${CMAKE_SOURCE_DIR}/cmake/CPackConfig.cmake" "${CMAKE_BINARY_DIR}/packaging/CPackConfig.cmake")
set(CPACK_PROJECT_CONFIG_FILE "${CMAKE_BINARY_DIR}/packaging/CPackConfig.cmake")
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
Some more improvements to the build and preparations for packaging
2018-05-06 00:43:50 +08:00
################################################################################
# Version information
################################################################################
string(REPLACE "." ";" FDB_VERSION_LIST ${FDB_VERSION_PLAIN})
list(GET FDB_VERSION_LIST 0 FDB_MAJOR)
list(GET FDB_VERSION_LIST 1 FDB_MINOR)
list(GET FDB_VERSION_LIST 2 FDB_PATCH)
################################################################################
# General CPack configuration
################################################################################
First version of working rpm packages
2018-05-06 03:08:39 +08:00
include(InstallRequiredSystemLibraries)
Some more improvements to the build and preparations for packaging
2018-05-06 00:43:50 +08:00
set(CPACK_PACKAGE_NAME "foundationdb")
Fixed the cmake package vendor and email information in order to prevent cpack errors
2019-05-03 13:14:18 +08:00
set(CPACK_PACKAGE_VENDOR "FoundationDB")
set(CPACK_PACKAGE_CONTACT "fdb-dist@apple.com")
Some more improvements to the build and preparations for packaging
2018-05-06 00:43:50 +08:00
set(CPACK_PACKAGE_VERSION_MAJOR ${FDB_MAJOR})
set(CPACK_PACKAGE_VERSION_MINOR ${FDB_MINOR})
set(CPACK_PACKAGE_VERSION_PATCH ${FDB_PATCH})
Put rpm, deb, or msi into the packages folder This additionally fixes a dependency bug on Windows
2019-02-17 04:07:52 +08:00
set(CPACK_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}-${FDB_VERSION}-${CPACK_SYSTEM_NAME}")
set(CPACK_OUTPUT_FILE_PREFIX "${CMAKE_BINARY_DIR}/packages")
Some more improvements to the build and preparations for packaging
2018-05-06 00:43:50 +08:00
set(CPACK_PACKAGE_DESCRIPTION_FILE ${CMAKE_SOURCE_DIR}/packaging/description)
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY
"FoundationDB is a scalable, fault-tolerant, ordered key-value store with full ACID transactions.")
set(CPACK_PACKAGE_ICON ${CMAKE_SOURCE_DIR}/packaging/foundationdb.ico)
RPM package now building correctly
2018-05-07 05:20:21 +08:00
set(CPACK_PACKAGE_CONTACT "The FoundationDB Community")
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_COMPONENT_SERVER-EL6_DEPENDS clients-el6)
set(CPACK_COMPONENT_SERVER-EL7_DEPENDS clients-el7)
set(CPACK_COMPONENT_SERVER-DEB_DEPENDS clients-deb)
set(CPACK_COMPONENT_SERVER-TGZ_DEPENDS clients-tgz)
set(CPACK_COMPONENT_SERVER-PM_DEPENDS clients-pm)
set(CPACK_COMPONENT_SERVER-EL6_DISPLAY_NAME "foundationdb-server")
set(CPACK_COMPONENT_SERVER-EL7_DISPLAY_NAME "foundationdb-server")
set(CPACK_COMPONENT_SERVER-DEB_DISPLAY_NAME "foundationdb-server")
set(CPACK_COMPONENT_SERVER-TGZ_DISPLAY_NAME "foundationdb-server")
set(CPACK_COMPONENT_SERVER-PM_DISPLAY_NAME "foundationdb-server")
set(CPACK_COMPONENT_CLIENTS-EL6_DISPLAY_NAME "foundationdb-clients")
set(CPACK_COMPONENT_CLIENTS-EL7_DISPLAY_NAME "foundationdb-clients")
set(CPACK_COMPONENT_CLIENTS-DEB_DISPLAY_NAME "foundationdb-clients")
set(CPACK_COMPONENT_CLIENTS-TGZ_DISPLAY_NAME "foundationdb-clients")
set(CPACK_COMPONENT_CLIENTS-PM_DISPLAY_NAME "foundationdb-clients")
This makes package generation work Resulting packages are not tested yet
2019-03-01 06:05:24 +08:00
# MacOS needs a file exiension for the LICENSE file
configure_file(${CMAKE_SOURCE_DIR}/LICENSE ${CMAKE_BINARY_DIR}/License.txt COPYONLY)
################################################################################
# Filename of packages
################################################################################
if(NOT FDB_RELEASE)
Changed the name of the rpm packages to conform to the existing names when building release project
2019-12-23 12:11:40 +08:00
if(CURRENT_GIT_VERSION)
set(git_string ".${CURRENT_GIT_VERSION}")
endif()
Set the package release version based on if the build is a release package or not like the make builds
2019-12-23 18:42:02 +08:00
set(CPACK_RPM_PACKAGE_RELEASE 0)
set(prerelease_string "-0${git_string}.PRERELEASE")
else()
set(CPACK_RPM_PACKAGE_RELEASE 1)
set(prerelease_string "-1")
Some more improvements to the build and preparations for packaging
2018-05-06 00:43:50 +08:00
endif()
Changed the cmake naming convention of rpms and deb packages to match the existing format which is sadly different between the formats.
2019-12-12 14:18:05 +08:00
Only include the git version within the rpm and deb name if defined Removed platform el6 and el7 from package name
2019-12-17 06:40:40 +08:00
Changed the cmake naming convention of rpms and deb packages to match the existing format which is sadly different between the formats.
2019-12-12 14:18:05 +08:00
# RPM filenames
Set the package release version based on if the build is a release package or not like the make builds
2019-12-23 18:42:02 +08:00
set(rpm-clients-filename "foundationdb-clients-${PROJECT_VERSION}${prerelease_string}")
set(rpm-server-filename "foundationdb-server-${PROJECT_VERSION}${prerelease_string}")
Changed the cmake naming convention of rpms and deb packages to match the existing format which is sadly different between the formats.
2019-12-12 14:18:05 +08:00
# Deb filenames
Set the package release version based on if the build is a release package or not like the make builds
2019-12-23 18:42:02 +08:00
set(deb-clients-filename "foundationdb-clients_${PROJECT_VERSION}${prerelease_string}")
set(deb-server-filename "foundationdb-server_${PROJECT_VERSION}${prerelease_string}")
Some more improvements to the build and preparations for packaging
2018-05-06 00:43:50 +08:00
install fdb service with rpm and add dependencies
2018-05-06 06:33:21 +08:00
################################################################################
# Configuration for RPM
################################################################################
Several bug fixes - debian package working Did some manual minor testing on the debian package
2019-02-11 14:51:40 +08:00
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_RPM_PACKAGE_LICENSE "Apache 2.0")
set(CPACK_RPM_PACKAGE_NAME "foundationdb")
Fix package naming
2019-03-02 07:21:21 +08:00
set(CPACK_RPM_CLIENTS-EL6_PACKAGE_NAME "foundationdb-clients")
set(CPACK_RPM_CLIENTS-EL7_PACKAGE_NAME "foundationdb-clients")
set(CPACK_RPM_SERVER-EL6_PACKAGE_NAME "foundationdb-server")
set(CPACK_RPM_SERVER-EL7_PACKAGE_NAME "foundationdb-server")
several minor improvements
2019-03-02 06:13:16 +08:00
Changed the cmake naming convention of rpms and deb packages to match the existing format which is sadly different between the formats.
2019-12-12 14:18:05 +08:00
set(CPACK_RPM_CLIENTS-EL6_FILE_NAME "${rpm-clients-filename}.el6.x86_64.rpm")
set(CPACK_RPM_CLIENTS-EL7_FILE_NAME "${rpm-clients-filename}.el7.x86_64.rpm")
set(CPACK_RPM_SERVER-EL6_FILE_NAME "${rpm-server-filename}.el6.x86_64.rpm")
set(CPACK_RPM_SERVER-EL7_FILE_NAME "${rpm-server-filename}.el7.x86_64.rpm")
several minor improvements
2019-03-02 06:13:16 +08:00
Changed the cmake naming convention of rpms and deb packages to match the existing format which is sadly different between the formats.
2019-12-12 14:18:05 +08:00
set(CPACK_RPM_CLIENTS-EL6_DEBUGINFO_FILE_NAME "${rpm-clients-filename}.el6-debuginfo.x86_64.rpm")
set(CPACK_RPM_CLIENTS-EL7_DEBUGINFO_FILE_NAME "${rpm-clients-filename}.el7-debuginfo.x86_64.rpm")
set(CPACK_RPM_SERVER-EL6_DEBUGINFO_FILE_NAME "${rpm-server-filename}.el6-debuginfo.x86_64.rpm")
set(CPACK_RPM_SERVER-EL7_DEBUGINFO_FILE_NAME "${rpm-server-filename}.el7-debuginfo.x86_64.rpm")
several minor improvements
2019-03-02 06:13:16 +08:00
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
file(MAKE_DIRECTORY "${CMAKE_BINARY_DIR}/packaging/emptydir")
several minor improvements
2019-03-02 06:13:16 +08:00
fdb_install(DIRECTORY "${CMAKE_BINARY_DIR}/packaging/emptydir/" DESTINATION data COMPONENT server)
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
fdb_install(DIRECTORY "${CMAKE_BINARY_DIR}/packaging/emptydir/" DESTINATION log COMPONENT server)
Include empty etc dir in cmake clients deb This seems to be necessary since without it the postinstall script complains that directory is missing.
2019-03-19 07:02:12 +08:00
fdb_install(DIRECTORY "${CMAKE_BINARY_DIR}/packaging/emptydir/" DESTINATION etc COMPONENT clients)
install fdb service with rpm and add dependencies
2018-05-06 06:33:21 +08:00
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_RPM_SERVER-EL6_USER_FILELIST
"%config(noreplace) /etc/foundationdb/foundationdb.conf"
"%attr(0700,foundationdb,foundationdb) /var/log/foundationdb"
"%attr(0700, foundationdb, foundationdb) /var/lib/foundationdb")
set(CPACK_RPM_SERVER-EL7_USER_FILELIST
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
"%config(noreplace) /etc/foundationdb/foundationdb.conf"
"%attr(0700,foundationdb,foundationdb) /var/log/foundationdb"
"%attr(0700, foundationdb, foundationdb) /var/lib/foundationdb")
Prevent server and clients rpm's from conflicting Before, the file /etc/foundationdb conflicted between the server and clients package, and /usr/lib64/cmake and /usr/lib64/pkgconfig conflicted with some system packages.
2020-04-17 05:55:15 +08:00
set(CPACK_RPM_CLIENTS-EL6_USER_FILELIST "%dir /etc/foundationdb")
set(CPACK_RPM_CLIENTS-EL7_USER_FILELIST "%dir /etc/foundationdb")
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
set(CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION
"/usr/sbin"
"/usr/share/java"
Prevent server and clients rpm's from conflicting Before, the file /etc/foundationdb conflicted between the server and clients package, and /usr/lib64/cmake and /usr/lib64/pkgconfig conflicted with some system packages.
2020-04-17 05:55:15 +08:00
"/usr/lib64/cmake"
"/etc/foundationdb"
"/usr/lib64/pkgconfig"
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
"/usr/lib64/python2.7"
"/usr/lib64/python2.7/site-packages"
"/var"
"/var/log"
"/var/lib"
"/lib"
"/lib/systemd"
"/lib/systemd/system"
"/etc/rc.d/init.d")
set(CPACK_RPM_DEBUGINFO_PACKAGE ON)
several minor improvements
2019-03-02 06:13:16 +08:00
#set(CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX /usr/src)
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
set(CPACK_RPM_COMPONENT_INSTALL ON)
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_RPM_CLIENTS-EL6_PRE_INSTALL_SCRIPT_FILE
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
${CMAKE_SOURCE_DIR}/packaging/rpm/scripts/preclients.sh)
set(CPACK_RPM_clients-el7_PRE_INSTALL_SCRIPT_FILE
${CMAKE_SOURCE_DIR}/packaging/rpm/scripts/preclients.sh)
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_RPM_CLIENTS-EL6_POST_INSTALL_SCRIPT_FILE
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
${CMAKE_SOURCE_DIR}/packaging/rpm/scripts/postclients.sh)
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_RPM_CLIENTS-EL7_POST_INSTALL_SCRIPT_FILE
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
${CMAKE_SOURCE_DIR}/packaging/rpm/scripts/postclients.sh)
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_RPM_SERVER-EL6_PRE_INSTALL_SCRIPT_FILE
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
${CMAKE_SOURCE_DIR}/packaging/rpm/scripts/preserver.sh)
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_RPM_SERVER-EL7_PRE_INSTALL_SCRIPT_FILE
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
${CMAKE_SOURCE_DIR}/packaging/rpm/scripts/preserver.sh)
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_RPM_SERVER-EL6_POST_INSTALL_SCRIPT_FILE
Remove pidof hack as it was not stable
2019-03-03 06:36:55 +08:00
${CMAKE_SOURCE_DIR}/packaging/rpm/scripts/postserver-el6.sh)
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_RPM_SERVER-EL7_POST_INSTALL_SCRIPT_FILE
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
${CMAKE_SOURCE_DIR}/packaging/rpm/scripts/postserver.sh)
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_RPM_SERVER-EL6_PRE_UNINSTALL_SCRIPT_FILE
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
${CMAKE_SOURCE_DIR}/packaging/rpm/scripts/preunserver.sh)
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_RPM_SERVER-EL7_PRE_UNINSTALL_SCRIPT_FILE
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
${CMAKE_SOURCE_DIR}/packaging/rpm/scripts/preunserver.sh)
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_RPM_SERVER-EL6_PACKAGE_REQUIRES
several minor bug fixes
2019-03-03 06:05:05 +08:00
"foundationdb-clients = ${FDB_MAJOR}.${FDB_MINOR}.${FDB_PATCH}")
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_RPM_SERVER-EL7_PACKAGE_REQUIRES
Support generating el6 and el7 rpms
2019-03-02 08:02:51 +08:00
"foundationdb-clients = ${FDB_MAJOR}.${FDB_MINOR}.${FDB_PATCH}")
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
#set(CPACK_RPM_java_PACKAGE_REQUIRES
# "foundationdb-clients = ${FDB_MAJOR}.${FDB_MINOR}.${FDB_PATCH}")
several minor improvements
2019-03-02 06:13:16 +08:00
#set(CPACK_RPM_python_PACKAGE_REQUIRES
# "foundationdb-clients = ${FDB_MAJOR}.${FDB_MINOR}.${FDB_PATCH}")
RPM package now building correctly
2018-05-07 05:20:21 +08:00
################################################################################
# Configuration for DEB
################################################################################
Changed the cmake naming convention of rpms and deb packages to match the existing format which is sadly different between the formats.
2019-12-12 14:18:05 +08:00
set(CPACK_DEBIAN_CLIENTS-DEB_FILE_NAME "${deb-clients-filename}_amd64.deb")
set(CPACK_DEBIAN_SERVER-DEB_FILE_NAME "${deb-server-filename}_amd64.deb")
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
set(CPACK_DEB_COMPONENT_INSTALL ON)
set(CPACK_DEBIAN_DEBUGINFO_PACKAGE ON)
set(CPACK_DEBIAN_PACKAGE_SECTION "database")
set(CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS ON)
RPM package now building correctly
2018-05-07 05:20:21 +08:00
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_DEBIAN_SERVER-DEB_PACKAGE_NAME "foundationdb-server")
set(CPACK_DEBIAN_CLIENTS-DEB_PACKAGE_NAME "foundationdb-clients")
Remove python dep from cmake-generated deb
2019-03-19 01:24:01 +08:00
set(CPACK_DEBIAN_SERVER-DEB_PACKAGE_DEPENDS "adduser, libc6 (>= 2.12), foundationdb-clients (= ${FDB_VERSION})")
Update cmake/InstallLayout.cmake Co-Authored-By: atn34 <anoyes34@gmail.com>
2019-03-20 00:51:52 +08:00
set(CPACK_DEBIAN_SERVER-DEB_PACKAGE_RECOMMENDS "python (>= 2.6)")
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
set(CPACK_DEBIAN_CLIENTS-DEB_PACKAGE_DEPENDS "adduser, libc6 (>= 2.12)")
set(CPACK_DEBIAN_PACKAGE_HOMEPAGE "https://www.foundationdb.org")
set(CPACK_DEBIAN_CLIENTS-DEB_PACKAGE_CONTROL_EXTRA
${CMAKE_SOURCE_DIR}/packaging/deb/DEBIAN-foundationdb-clients/postinst)
set(CPACK_DEBIAN_SERVER-DEB_PACKAGE_CONTROL_EXTRA
${CMAKE_SOURCE_DIR}/packaging/deb/DEBIAN-foundationdb-server/conffiles
${CMAKE_SOURCE_DIR}/packaging/deb/DEBIAN-foundationdb-server/preinst
${CMAKE_SOURCE_DIR}/packaging/deb/DEBIAN-foundationdb-server/postinst
${CMAKE_SOURCE_DIR}/packaging/deb/DEBIAN-foundationdb-server/prerm
${CMAKE_SOURCE_DIR}/packaging/deb/DEBIAN-foundationdb-server/postrm)
Some more improvements to the build and preparations for packaging
2018-05-06 00:43:50 +08:00
started macos builder
2019-02-08 07:10:32 +08:00
################################################################################
# MacOS configuration
################################################################################
Use productbuild instead of PackageMaker on MacOS fixes #1547 fixes #1549
2019-05-12 05:42:48 +08:00
if(APPLE)
Fix merge conflicts
2019-02-08 08:35:08 +08:00
install(PROGRAMS ${CMAKE_SOURCE_DIR}/packaging/osx/uninstall-FoundationDB.sh
DESTINATION "usr/local/foundationdb"
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
COMPONENT clients-pm)
Fix merge conflicts
2019-02-08 08:35:08 +08:00
install(FILES ${CMAKE_SOURCE_DIR}/packaging/osx/com.foundationdb.fdbmonitor.plist
DESTINATION "Library/LaunchDaemons"
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
COMPONENT server-pm)
started macos builder
2019-02-08 07:10:32 +08:00
endif()
This makes package generation work Resulting packages are not tested yet
2019-03-01 06:05:24 +08:00
################################################################################
# Configuration for DEB
################################################################################
set(CPACK_ARCHIVE_COMPONENT_INSTALL ON)
Changed the cmake naming convention of rpms and deb packages to match the existing format which is sadly different between the formats.
2019-12-12 14:18:05 +08:00
set(CPACK_ARCHIVE_CLIENTS-TGZ_FILE_NAME "${deb-clients-filename}.x86_64")
set(CPACK_ARCHIVE_SERVER-TGZ_FILE_NAME "${deb-server-filename}.x86_64")
This makes package generation work Resulting packages are not tested yet
2019-03-01 06:05:24 +08:00
First version of working rpm packages
2018-05-06 03:08:39 +08:00
################################################################################
# Server configuration
################################################################################
string(RANDOM LENGTH 8 description1)
string(RANDOM LENGTH 8 description2)
set(CLUSTER_DESCRIPTION1 ${description1} CACHE STRING "Cluster description")
set(CLUSTER_DESCRIPTION2 ${description2} CACHE STRING "Cluster description")
some more windows installer modifications
2019-02-07 04:02:19 +08:00
if(NOT WIN32)
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
install(FILES ${CMAKE_SOURCE_DIR}/packaging/osx/foundationdb.conf.new
DESTINATION "usr/local/etc"
COMPONENT server-pm)
fdb_install(FILES ${CMAKE_SOURCE_DIR}/packaging/foundationdb.conf
DESTINATION etc
some more windows installer modifications
2019-02-07 04:02:19 +08:00
COMPONENT server)
install(FILES ${CMAKE_SOURCE_DIR}/packaging/make_public.py
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
DESTINATION "usr/lib/foundationdb"
COMPONENT server-el6)
install(FILES ${CMAKE_SOURCE_DIR}/packaging/make_public.py
DESTINATION "usr/lib/foundationdb"
COMPONENT server-deb)
Added linux-pkgs command to docker-compose file
2019-02-11 13:30:50 +08:00
install(FILES ${CMAKE_SOURCE_DIR}/packaging/rpm/foundationdb.service
DESTINATION "lib/systemd/system"
First implementaion of more user-friendly cpack Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run
2019-02-28 12:17:11 +08:00
COMPONENT server-el7)
install(PROGRAMS ${CMAKE_SOURCE_DIR}/packaging/rpm/foundationdb-init
DESTINATION "etc/rc.d/init.d"
RENAME "foundationdb"
COMPONENT server-el6)
install(PROGRAMS ${CMAKE_SOURCE_DIR}/packaging/deb/foundationdb-init
DESTINATION "etc/init.d"
RENAME "foundationdb"
COMPONENT server-deb)
install fdb service with rpm and add dependencies
2018-05-06 06:33:21 +08:00
endif()