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

477 lines
21 KiB
CMake
Raw Normal View History

CPack refactoring and introduction of multiversion
2020-10-29 02:55:15 +08:00
include(FDBInstall)
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
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")
FoundationDB MacOS client package > add symlink, move files * In FDB 6.2, there are symlinks to backup_agent to usr/local/bin, this patch makes 6.3 adds these symlinks to the proper positions. * In FDB 6.2, the libfdb_c.dylib is installed to usr/local/lib, this patch makes 6.3 install the dylib to this path.
2020-10-31 09:21:04 +08:00
install_symlink_impl(
TO "../${rel_path}local/bin/${IN_FILE_NAME}"
DESTINATION "usr/lib64/${IN_LINK_NAME}"
COMPONENTS "${IN_COMPONENT}-pm")
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
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")
FoundationDB MacOS client package > add symlink, move files * In FDB 6.2, there are symlinks to backup_agent to usr/local/bin, this patch makes 6.3 adds these symlinks to the proper positions. * In FDB 6.2, the libfdb_c.dylib is installed to usr/local/lib, this patch makes 6.3 install the dylib to this path.
2020-10-31 09:21:04 +08:00
install_symlink_impl(
TO "../${rel_path}/bin/${IN_FILE_NAME}"
DESTINATION "usr/local/bin/${IN_LINK_NAME}"
COMPONENTS "${IN_COMPONENT}-pm")
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")
FoundationDB MacOS client package > add symlink, move files * In FDB 6.2, there are symlinks to backup_agent to usr/local/bin, this patch makes 6.3 adds these symlinks to the proper positions. * In FDB 6.2, the libfdb_c.dylib is installed to usr/local/lib, this patch makes 6.3 install the dylib to this path.
2020-10-31 09:21:04 +08:00
install_symlink_impl(
TO "../../${rel_path}/bin/${IN_FILE_NAME}"
DESTINATION "usr/local/lib/foundationdb/${IN_LINK_NAME}"
COMPONENTS "${IN_COMPONENT}-pm")
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")
FoundationDB MacOS client package > add symlink, move files * In FDB 6.2, there are symlinks to backup_agent to usr/local/bin, this patch makes 6.3 adds these symlinks to the proper positions. * In FDB 6.2, the libfdb_c.dylib is installed to usr/local/lib, this patch makes 6.3 install the dylib to this path.
2020-10-31 09:21:04 +08:00
set(install_destination_for_lib_pm "usr/local/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")
FoundationDB MacOS server package > add data/logs path The paths ./usr/local/foundationdb/logs ./usr/local/foundationdb/data exists in 6.2 but not 6.3 for MacOS pkg server package. This patch fixes the issue.
2020-10-31 04:30:48 +08:00
set(install_destination_for_log_pm "usr/local/foundationdb/logs")
Use 'map' for finding install paths
2019-05-23 07:09:04 +08:00
set(install_destination_for_data_tgz "lib/foundationdb")
Install /var/lib/foundationdb/data This is what the old buildrpms.sh and builddebs.sh seemed to do
2020-04-27 04:52:10 +08:00
set(install_destination_for_data_deb "var/lib/foundationdb/data")
set(install_destination_for_data_el6 "var/lib/foundationdb/data")
set(install_destination_for_data_el7 "var/lib/foundationdb/data")
FoundationDB MacOS server package > add data/logs path The paths ./usr/local/foundationdb/logs ./usr/local/foundationdb/data exists in 6.2 but not 6.3 for MacOS pkg server package. This patch fixes the issue.
2020-10-31 04:30:48 +08:00
set(install_destination_for_data_pm "usr/local/foundationdb/data")
remove support for el6
2020-10-29 03:10:59 +08:00
fdb_install_packages(TGZ DEB EL7 PM VERSIONED)
CPack refactoring and introduction of multiversion
2020-10-29 02:55:15 +08:00
fdb_install_dirs(BIN SBIN LIB FDBMONITOR INCLUDE ETC LOG DATA)
message(STATUS "FDB_INSTALL_DIRS -> ${FDB_INSTALL_DIRS}")
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}
CPack refactoring and introduction of multiversion
2020-10-29 02:55:15 +08:00
install_destinations(TGZ
BIN bin
SBIN sbin
LIB lib
FDBMONITOR sbin
INCLUDE include
ETC etc/foundationdb
LOG log/foundationdb
DATA lib/foundationdb)
copy_install_destinations(TGZ VERSIONED PREFIX "usr/lib/foundationdb-${PROJECT_VERSION}/")
install_destinations(DEB
BIN usr/bin
SBIN usr/sbin
LIB usr/lib
FDBMONITOR usr/lib/foundationdb
INCLUDE usr/include
ETC etc/foundationdb
LOG var/log/foundationdb
DATA var/lib/foundationdb)
remove support for el6
2020-10-29 03:10:59 +08:00
copy_install_destinations(DEB EL7)
install_destinations(EL7 LIB usr/lib64)
CPack refactoring and introduction of multiversion
2020-10-29 02:55:15 +08:00
install_destinations(PM
BIN usr/local/bin
SBIN usr/local/sbin
LIB lib
FDBMONITOR usr/local/libexec
INCLUDE usr/local/include
ETC usr/local/etc/foundationdb)
# This can be used for debugging in case above is behaving funky
#print_install_destinations()
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
Support pkg-config
2019-05-24 05:13:07 +08:00
set(generated_dir "${CMAKE_CURRENT_BINARY_DIR}/generated")
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
Attempted to fix debian directory structure
2020-04-23 07:29:28 +08:00
################################################################################
# User config
################################################################################
set(GENERATE_DEBUG_PACKAGES "${FDB_RELEASE}" CACHE BOOL "Build debug rpm/deb packages (default: only ON for FDB_RELEASE)")
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)
add alternatives to install symlinks
2020-10-29 04:03:48 +08:00
################################################################################
# Alternatives config
################################################################################
math(EXPR ALTERNATIVES_PRIORITY "(${PROJECT_VERSION_MAJOR} * 1000) + (${PROJECT_VERSION_MINOR} * 100) + ${PROJECT_VERSION_PATCH}")
set(script_dir "${PROJECT_BINARY_DIR}/packaging/multiversion/")
file(MAKE_DIRECTORY "${script_dir}/server" "${script_dir}/clients")
configure_file("${PROJECT_SOURCE_DIR}/packaging/multiversion/server/postinst" "${script_dir}/server" @ONLY)
configure_file("${PROJECT_SOURCE_DIR}/packaging/multiversion/server/prerm" "${script_dir}/server" @ONLY)
set(LIB_DIR lib)
configure_file("${PROJECT_SOURCE_DIR}/packaging/multiversion/clients/postinst" "${script_dir}/clients" @ONLY)
set(LIB_DIR lib64)
configure_file("${PROJECT_SOURCE_DIR}/packaging/multiversion/clients/postinst" "${script_dir}/clients/postinst-el7" @ONLY)
configure_file("${PROJECT_SOURCE_DIR}/packaging/multiversion/clients/prerm" "${script_dir}/clients" @ONLY)
Some more improvements to the build and preparations for packaging
2018-05-06 00:43:50 +08:00
################################################################################
# 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-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)
CPack refactoring and introduction of multiversion
2020-10-29 02:55:15 +08:00
set(CPACK_COMPONENT_SERVER-VERSIONED_DEPENDS clients-versioned)
several minor improvements
2019-03-02 06:13:16 +08:00
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")
CPack refactoring and introduction of multiversion
2020-10-29 02:55:15 +08:00
set(CPACK_COMPONENT_SERVER-VERSIONED_DISPLAY_NAME "foundationdb-server-${PROJECT_VERSION}")
several minor improvements
2019-03-02 06:13:16 +08:00
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")
CPack refactoring and introduction of multiversion
2020-10-29 02:55:15 +08:00
set(CPACK_COMPONENT_CLIENTS-VERSIONED_DISPLAY_NAME "foundationdb-clients-${PROJECT_VERSION}")
several minor improvements
2019-03-02 06:13:16 +08:00
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-EL7_PACKAGE_NAME "foundationdb-clients")
set(CPACK_RPM_SERVER-EL7_PACKAGE_NAME "foundationdb-server")
CPack refactoring and introduction of multiversion
2020-10-29 02:55:15 +08:00
set(CPACK_RPM_SERVER-VERSIONED_PACKAGE_NAME "foundationdb-server-${PROJECT_VERSION}")
several minor improvements
2019-03-02 06:13:16 +08:00
Fix minor issues for aarch64
2021-01-26 02:30:32 +08:00
set(CPACK_RPM_CLIENTS-EL7_FILE_NAME "${rpm-clients-filename}.el7.${CMAKE_SYSTEM_PROCESSOR}.rpm")
set(CPACK_RPM_CLIENTS-VERSIONED_FILE_NAME "${rpm-clients-filename}.versioned.${CMAKE_SYSTEM_PROCESSOR}.rpm")
set(CPACK_RPM_SERVER-EL7_FILE_NAME "${rpm-server-filename}.el7.${CMAKE_SYSTEM_PROCESSOR}.rpm")
set(CPACK_RPM_SERVER-VERSIONED_FILE_NAME "${rpm-server-filename}.versioned.${CMAKE_SYSTEM_PROCESSOR}.rpm")
several minor improvements
2019-03-02 06:13:16 +08:00
Fix minor issues for aarch64
2021-01-26 02:30:32 +08:00
set(CPACK_RPM_CLIENTS-EL7_DEBUGINFO_FILE_NAME "${rpm-clients-filename}.el7-debuginfo.${CMAKE_SYSTEM_PROCESSOR}.rpm")
set(CPACK_RPM_CLIENTS-VERSIONED_DEBUGINFO_FILE_NAME "${rpm-clients-filename}.versioned-debuginfo.${CMAKE_SYSTEM_PROCESSOR}.rpm")
set(CPACK_RPM_SERVER-EL7_DEBUGINFO_FILE_NAME "${rpm-server-filename}.el7-debuginfo.${CMAKE_SYSTEM_PROCESSOR}.rpm")
set(CPACK_RPM_SERVER-VERSIONED_DEBUGINFO_FILE_NAME "${rpm-server-filename}.versioned-debuginfo.${CMAKE_SYSTEM_PROCESSOR}.rpm")
several minor improvements
2019-03-02 06:13:16 +08:00
simplified further
2020-05-05 01:47:24 +08:00
file(MAKE_DIRECTORY "${CMAKE_BINARY_DIR}/packaging/emptydir")
fdb_install(DIRECTORY "${CMAKE_BINARY_DIR}/packaging/emptydir/" DESTINATION data COMPONENT server)
fdb_install(DIRECTORY "${CMAKE_BINARY_DIR}/packaging/emptydir/" DESTINATION log COMPONENT server)
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-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-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"
CPack refactoring and introduction of multiversion
2020-10-29 02:55:15 +08:00
"/usr/lib"
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")
Attempted to fix debian directory structure
2020-04-23 07:29:28 +08:00
set(CPACK_RPM_DEBUGINFO_PACKAGE ${GENERATE_DEBUG_PACKAGES})
CPack refactoring and introduction of multiversion
2020-10-29 02:55:15 +08:00
#set(CPACK_RPM_BUILD_SOURCE_FDB_INSTALL_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)
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-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-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-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-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-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}")
add alternatives to install symlinks
2020-10-29 04:03:48 +08:00
set(CPACK_RPM_SERVER-VERSIONED_POST_INSTALL_SCRIPT_FILE
${CMAKE_BINARY_DIR}/packaging/multiversion/server/postinst)
set(CPACK_RPM_SERVER-VERSIONED_PRE_UNINSTALL_SCRIPT_FILE
${CMAKE_BINARY_DIR}/packaging/multiversion/server/prerm)
set(CPACK_RPM_CLIENTS-VERSIONED_POST_INSTALL_SCRIPT_FILE
${CMAKE_BINARY_DIR}/packaging/multiversion/clients/postinst-el7)
set(CPACK_RPM_CLIENTS-VERSIONED_PRE_UNINSTALL_SCRIPT_FILE
${CMAKE_BINARY_DIR}/packaging/multiversion/clients/prerm)
RPM package now building correctly
2018-05-07 05:20:21 +08:00
################################################################################
# Configuration for DEB
################################################################################
Fix minor issues for aarch64
2021-01-26 02:30:32 +08:00
if (CMAKE_SYSTEM_PROCESSOR MATCHES "x86_64")
set(CPACK_DEBIAN_CLIENTS-DEB_FILE_NAME "${deb-clients-filename}_amd64.deb")
set(CPACK_DEBIAN_SERVER-DEB_FILE_NAME "${deb-server-filename}_amd64.deb")
Merge remote-tracking branch 'apple/release-6.3' into master-format-final release-6.3 was recently merged, and there were two PRs which were merged in between and got those changes in here. Hence, since all the changes were in, discarded the incoming changes and accepted all current.
2021-03-11 06:42:17 +08:00
set(CPACK_DEBIAN_CLIENTS-VERSIONED_FILE_NAME "${deb-clients-filename}.versioned_amd64.deb")
set(CPACK_DEBIAN_SERVER-VERSIONED_FILE_NAME "${deb-server-filename}.versioned_amd64.deb")
Fix minor issues for aarch64
2021-01-26 02:30:32 +08:00
else()
set(CPACK_DEBIAN_CLIENTS-DEB_FILE_NAME "${deb-clients-filename}_${CMAKE_SYSTEM_PROCESSOR}.deb")
set(CPACK_DEBIAN_SERVER-DEB_FILE_NAME "${deb-server-filename}_${CMAKE_SYSTEM_PROCESSOR}.deb")
Merge remote-tracking branch 'apple/release-6.3' into master-format-final release-6.3 was recently merged, and there were two PRs which were merged in between and got those changes in here. Hence, since all the changes were in, discarded the incoming changes and accepted all current.
2021-03-11 06:42:17 +08:00
set(CPACK_DEBIAN_CLIENTS-VERSIONED_FILE_NAME "${deb-clients-filename}.versioned_${CMAKE_SYSTEM_PROCESSOR}.deb")
set(CPACK_DEBIAN_SERVER-VERSIONED_FILE_NAME "${deb-server-filename}.versioned_${CMAKE_SYSTEM_PROCESSOR}.deb")
Fix minor issues for aarch64
2021-01-26 02:30:32 +08:00
endif()
fix debian packages
2021-03-03 03:41:21 +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
set(CPACK_DEB_COMPONENT_INSTALL ON)
Attempted to fix debian directory structure
2020-04-23 07:29:28 +08:00
set(CPACK_DEBIAN_DEBUGINFO_PACKAGE ${GENERATE_DEBUG_PACKAGES})
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_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")
CPack refactoring and introduction of multiversion
2020-10-29 02:55:15 +08:00
set(CPACK_DEBIAN_SERVER-VERSIONED_PACKAGE_NAME "foundationdb-server-${PROJECT_VERSION}")
set(CPACK_DEBIAN_CLIENTS-VERSIONED_PACKAGE_NAME "foundationdb-clients-${PROJECT_VERSION}")
several minor improvements
2019-03-02 06:13:16 +08:00
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
add alternatives to install symlinks
2020-10-29 04:03:48 +08:00
set(CPACK_DEBIAN_CLIENTS-VERSIONED_PACKAGE_CONTROL_EXTRA
${CMAKE_BINARY_DIR}/packaging/multiversion/clients/postinst
${CMAKE_BINARY_DIR}/packaging/multiversion/clients/prerm)
set(CPACK_DEBIAN_SERVER-VERSIONED_PACKAGE_CONTROL_EXTRA
${CMAKE_BINARY_DIR}/packaging/multiversion/server/postinst
${CMAKE_BINARY_DIR}/packaging/multiversion/server/prerm)
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)
Fix minor issues for aarch64
2021-01-26 02:30:32 +08:00
set(CPACK_ARCHIVE_CLIENTS-TGZ_FILE_NAME "${deb-clients-filename}.${CMAKE_SYSTEM_PROCESSOR}")
set(CPACK_ARCHIVE_SERVER-TGZ_FILE_NAME "${deb-server-filename}.${CMAKE_SYSTEM_PROCESSOR}")
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)
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/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/deb/foundationdb-init
DESTINATION "etc/init.d"
RENAME "foundationdb"
COMPONENT server-deb)
add service files to versioned packages This includes systemd and initd files. This way an admin can manually install them in the system
2020-10-29 04:14:58 +08:00
install(FILES ${CMAKE_SOURCE_DIR}/packaging/rpm/foundationdb.service
DESTINATION "usr/lib/foundationdb-${PROJECT_VERSION}/lib/systemd/system"
COMPONENT server-versioned)
install(PROGRAMS ${CMAKE_SOURCE_DIR}/packaging/deb/foundationdb-init
DESTINATION "usr/lib/foundationdb-${PROJECT_VERSION}/etc/init.d"
RENAME "foundationdb"
COMPONENT server-versioned)
install fdb service with rpm and add dependencies
2018-05-06 06:33:21 +08:00
endif()