-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Comments
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. |
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
I wrote this CMakeLists to use seastar in my project.
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.
The text was updated successfully, but these errors were encountered: