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

20 lines
930 B
CMake
Raw Normal View History

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
# RPM specifics
if(CPACK_GENERATOR MATCHES "RPM")
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_PACKAGING_INSTALL_PREFIX "/")
remove support for el6
2020-10-29 03:10:59 +08:00
set(CPACK_COMPONENTS_ALL clients-el7 server-el7 clients-versioned server-versioned)
This makes package generation work Resulting packages are not tested yet
2019-03-01 06:05:24 +08:00
set(CPACK_RESOURCE_FILE_README ${CMAKE_SOURCE_DIR}/README.md)
set(CPACK_RESOURCE_FILE_LICENSE ${CMAKE_SOURCE_DIR}/LICENSE)
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(CPACK_GENERATOR MATCHES "DEB")
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_PACKAGING_INSTALL_PREFIX "/")
CPack refactoring and introduction of multiversion
2020-10-29 02:55:15 +08:00
set(CPACK_COMPONENTS_ALL clients-deb server-deb clients-versioned server-versioned)
This makes package generation work Resulting packages are not tested yet
2019-03-01 06:05:24 +08:00
set(CPACK_RESOURCE_FILE_README ${CMAKE_SOURCE_DIR}/README.md)
set(CPACK_RESOURCE_FILE_LICENSE ${CMAKE_SOURCE_DIR}/LICENSE)
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(CPACK_GENERATOR MATCHES "TGZ")
set(CPACK_STRIP_FILES TRUE)
set(CPACK_COMPONENTS_ALL clients-tgz server-tgz)
This makes package generation work Resulting packages are not tested yet
2019-03-01 06:05:24 +08:00
set(CPACK_RESOURCE_FILE_README ${CMAKE_SOURCE_DIR}/README.md)
set(CPACK_RESOURCE_FILE_LICENSE ${CMAKE_SOURCE_DIR}/LICENSE)
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 "Unsupported package format ${CPACK_GENERATOR}")
endif()