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

39 lines
896 B
CMake
Raw Normal View History

CMake compiles all binaries except for bindings
2018-05-04 07:06:30 +08:00
set(FDBBACKUP_SRCS
backup.actor.cpp)
simplify actorcompiler and target to compile coveragetool
2019-02-09 08:51:13 +08:00
add_flow_target(EXECUTABLE NAME fdbbackup SRCS ${FDBBACKUP_SRCS})
CMake compiles all binaries except for bindings
2018-05-04 07:06:30 +08:00
target_link_libraries(fdbbackup PRIVATE fdbclient)
Some more improvements to the build and preparations for packaging
2018-05-06 00:43:50 +08:00
Tell cmake not to link/install on ide build
2019-02-18 09:54:54 +08:00
if(NOT OPEN_FOR_IDE)
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(TARGETS fdbbackup DESTINATION bin COMPONENT clients)
Tell cmake not to link/install on ide build
2019-02-18 09:54:54 +08:00
install_symlink(
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
FILE_DIR bin
several minor bug fixes
2019-03-03 06:05:05 +08:00
LINK_DIR fdbmonitor
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_NAME fdbbackup
several minor bug fixes
2019-03-03 06:05:05 +08:00
LINK_NAME backup_agent/backup_agent)
Tell cmake not to link/install on ide build
2019-02-18 09:54:54 +08:00
install_symlink(
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
FILE_DIR bin
LINK_DIR bin
FILE_NAME fdbbackup
LINK_NAME fdbrestore)
Tell cmake not to link/install on ide build
2019-02-18 09:54:54 +08:00
install_symlink(
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
FILE_DIR bin
LINK_DIR bin
FILE_NAME fdbbackup
LINK_NAME dr_agent)
Tell cmake not to link/install on ide build
2019-02-18 09:54:54 +08:00
install_symlink(
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
FILE_DIR bin
LINK_DIR bin
FILE_NAME fdbbackup
LINK_NAME fdbdr)
Tell cmake not to link/install on ide build
2019-02-18 09:54:54 +08:00
endif()
Enhance cmake's gperftools support Add compiler flags and link flags for gperftools.
2019-04-03 08:34:29 +08:00
if (GPERFTOOLS_FOUND)
add_compile_definitions(USE_GPERFTOOLS)
target_link_libraries(fdbbackup PRIVATE gperftools)
endif()