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

30 lines
1.6 KiB
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 "/")
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_COMPONENTS_ALL clients-el6 clients-el7 server-el6 server-el7)
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 "/")
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_COMPONENTS_ALL clients-deb server-deb)
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 "PackageMaker")
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_PACKAGING_INSTALL_PREFIX "/")
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_COMPONENTS_ALL clients-pm server-pm)
set(CPACK_STRIP_FILES TRUE)
set(CPACK_PREFLIGHT_SERVER_SCRIPT ${CMAKE_SOURCE_DIR}/packaging/osx/scripts-server/preinstall)
set(CPACK_POSTFLIGHT_SERVER_SCRIPT ${CMAKE_SOURCE_DIR}/packaging/osx/scripts-server/postinstall)
set(CPACK_POSTFLIGHT_CLIENTS_SCRIPT ${CMAKE_SOURCE_DIR}/packaging/osx/scripts-server/preinstall)
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}/packaging/osx/resources/conclusion.rtf)
set(CPACK_PRODUCTBUILD_RESOURCES_DIR ${CMAKE_SOURCE_DIR}/packaging/osx/resources)
set(CPACK_RESOURCE_FILE_LICENSE ${CMAKE_BINARY_DIR}/License.txt)
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()