Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using seastar in a CMake projects #264

Closed
thongpv87 opened this issue Mar 17, 2017 · 2 comments
Closed

Using seastar in a CMake projects #264

thongpv87 opened this issue Mar 17, 2017 · 2 comments

Comments

@thongpv87
Copy link

thongpv87 commented Mar 17, 2017

I wrote this CMakeLists to use seastar in my project.

execute_process(COMMAND ./configure.py WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
execute_process(COMMAND ninja -C ${CMAKE_CURRENT_SOURCE_DIR})
#todo move seastar build directory into cmake build directory


set(SEASTAR_LIB_LOCATION ${CMAKE_CURRENT_SOURCE_DIR}/build)
if (CMAKE_BUILD_TYPE MATCHES RELEASE)
set(SEASTAR_LIB_LOCATION ${SEASTAR_LIB_LOCATION}/release)
else ()
set(SEASTAR_LIB_LOCATION ${SEASTAR_LIB_LOCATION}/debug)
endif ()
find_package(PkgConfig REQUIRED)
execute_process(COMMAND pkg-config --cflags --libs ${SEASTAR_LIB_LOCATION}/seastar.pc OUTPUT_VARIABLE SEASTAR_LIB)
string(STRIP "${SEASTAR_LIB}" SEASTAR_LIB) #remove trail while space
#string(REPLACE " -fsanitize=address -fsanitize=leak -fsanitize=undefined -fno-sanitize=vptr " " " SEASTAR_LIB ${SEASTAR_LIB})
message(STATUS ${SEASTAR_LIB})
#add library
add_library(seastar INTERFACE)
target_link_libraries(seastar INTERFACE ${SEASTAR_LIB})

But build folder of seastar still in source directory. I want to modified configure.py to move seastar's build folder into my CMake's build folder. How I can do it.

Sorry for my bad English.

@emaxerrno
Copy link
Contributor

i use cmake here:

https://github.com/senior7515/smf/blob/master/CMake/Seastar.cmake#L1

Feel free to copy paste, it's apache2 the project.

@hakuch
Copy link
Contributor

hakuch commented Apr 20, 2018

Once #313 is resolved, then using Seastar in a CMake project will be considerably easier. Experimental support for CMake may be present in the tree prior to it replacing the current build system and prior to it being officially supported.

jwnx pushed a commit to jwnx/seastar that referenced this issue Feb 7, 2019
This patch replaces the previous build system (based on Ninja files
generated from a Python script) with CMake.

For a quick walk-through, see `HACKING.md`.

I have tested this build system with all combinations of:

- GCC
- CMake 3.5.2 and CMake 3.11.2

The most important characteristic of this new build system is how
dependencies are handled.

Previously, dependencies of Seastar that were not readily available as
system packages were included as Git submodules and compiled as part of
the generated `rules.ninja` file.

In this system, we specify with CMake the names and versions of all
dependencies, but we do not bundle them in the build itself. In this
way, the dependencies can be supplied from arbitrary sources. These
could include system packages, custom locations on disk, or package
managers like Conan.

`configure.py` and `test.py` still exist and should be functionally
compatible, but now wrap the CMake-based replacements. Options which are
not supported in the new build system are not included in those scripts
any longer.

Git submodules still exist for `fmt` and `dpdk`, but a consumer of
Seastar can provide these from other sources and instruct CMake on how
to find them if they wish.

One option for supplying dependencies included in this patch is the
`cooking.sh` script, part of the `cmake-cooking` project. This script
creates a local development environment containing all (or some)
dependencies by fetching their source code, compiling them, and
installing them into a project-specific location. More instructions for
using `cooking.sh` are available in the new `HACKING.md` file and on the
project's home-page.

The most convenient way to build the external dependencies included as
Git submodules is to use `cooking.sh` with the `dev` recipe (which
points to them) or to use the compatibility configure script:
`configure.py` (which also uses `cooking.sh`, but only for the
dependencies included as submodules).

Because the build system only checks that dependencies are satisfied,
when Seastar is installed via -- for example, `ninja install` -- the
installed files are relocatable to any system which includes the
dependencies and for which the installation destination exists.

As part of this build system, we also generate a pkg-config
specification which is installed alongside the CMake files necessary for
consumers to use Seastar.

This new build system also includes the new `test_dist` target. This
test verifies that clients can build applications against Seastar with
the files that the build-system installs. The test uses `cooking.sh` to
manage all dependencies and checks both "native" CMake support and also
compilation with pkg-config.

Finally, Doxygen needs to be instructed on how to output files based on
the way the build is configured. These changes are reflected in a new
template file (`Doxyfile.in`) and configured by the build system.

Fixes scylladb#67.
Fixes scylladb#264.
Fixes scylladb#313.

Signed-off-by: Jesse Haber-Kucharsky <jhaberku@scylladb.com>
Message-Id: <67178984d629d3f9acb16f8424da2a732daf75c8.1543507802.git.jhaberku@scylladb.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants