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

47 lines
2.2 KiB
CMake
Raw Normal View History

Switched back to allowing only one RPM platform to be built at a time. Allow the selection of el6 RPM creation to be made via environmental variable
2019-12-17 06:41:44 +08:00
set(GENERATE_EL6 OFF CACHE BOOL "Generate RPMs for EL6")
if ((NOT GENERATE_EL6) AND (NOT "$ENV{GENERATE_EL6}" STREQUAL ""))
if (("$ENV{GENERATE_EL6}" STREQUAL "ON") OR ("$ENV{GENERATE_EL6}" STREQUAL "1") OR ("$ENV{GENERATE_EL6}" STREQUAL "YES"))
set(GENERATE_EL6 ON)
endif()
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
# RPM specifics
if(CPACK_GENERATOR MATCHES "RPM")
several minor improvements
2019-03-02 06:13:16 +08:00
set(CPACK_PACKAGING_INSTALL_PREFIX "/")
Switched back to allowing only one RPM platform to be built at a time. Allow the selection of el6 RPM creation to be made via environmental variable
2019-12-17 06:41:44 +08:00
if(GENERATE_EL6)
Add support for building el6 and el7 RPM packages by default using single cpack command
2019-12-16 16:13:17 +08:00
set(CPACK_COMPONENTS_ALL clients-el6 server-el6)
Switched back to allowing only one RPM platform to be built at a time. Allow the selection of el6 RPM creation to be made via environmental variable
2019-12-17 06:41:44 +08:00
else()
set(CPACK_COMPONENTS_ALL clients-el7 server-el7)
Support generating el6 and el7 rpms
2019-03-02 08:02:51 +08:00
endif()
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)
Use productbuild instead of PackageMaker on MacOS fixes #1547 fixes #1549
2019-05-12 05:42:48 +08:00
elseif(CPACK_GENERATOR MATCHES "productbuild")
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)
Changed specification of the path to the License.txt file since previous value resulted in search at top level (/) directory.
2019-05-03 15:12:07 +08:00
# Commenting out this readme file until it works within packaging
Use productbuild instead of PackageMaker on MacOS fixes #1547 fixes #1549
2019-05-12 05:42:48 +08:00
set(CPACK_RESOURCE_FILE_README ${CMAKE_SOURCE_DIR}/packaging/osx/resources/conclusion.rtf)
This makes package generation work Resulting packages are not tested yet
2019-03-01 06:05:24 +08:00
set(CPACK_PRODUCTBUILD_RESOURCES_DIR ${CMAKE_SOURCE_DIR}/packaging/osx/resources)
Changed specification of the path to the License.txt file since previous value resulted in search at top level (/) directory.
2019-05-03 15:12:07 +08:00
# Changing the path of this file as CMAKE_BINARY_DIR does not seem to be defined
Use productbuild instead of PackageMaker on MacOS fixes #1547 fixes #1549
2019-05-12 05:42:48 +08:00
set(CPACK_RESOURCE_FILE_LICENSE ${CMAKE_BINARY_DIR}/License.txt)
Ensure that the naming convention for the OSX package is the same as it was
2019-12-12 10:43:15 +08:00
if(NOT FDB_RELEASE)
Modified compilation and package names to conform to existing compilation options and packaging names Modifications to existing standards (even when wrong should be made outside of port to cmake)
2019-12-15 23:13:46 +08:00
set(prerelease_string "-PRERELEASE")
Ensure that the naming convention for the OSX package is the same as it was
2019-12-12 10:43:15 +08:00
endif()
Modified compilation and package names to conform to existing compilation options and packaging names Modifications to existing standards (even when wrong should be made outside of port to cmake)
2019-12-15 23:13:46 +08:00
set(CPACK_PACKAGE_FILE_NAME "FoundationDB-${PROJECT_VERSION}${prerelease_string}")
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()