PragmaTwice opened a new issue, #562: URL: https://github.com/apache/incubator-kvrocks/issues/562
[`FetchContent`](https://cmake.org/cmake/help/latest/module/FetchContent.html) has been adopted by many projects as a dependency fetching method introduced in newer versions of cmake, for example [the official documentation for gtest](https://google.github.io/googletest/quickstart-cmake.html#set-up-a-project) already recommends using `FetchContent` to import itself into other projects (replacing the previous recommended `ExternalProject`). The advantage of `FetchContent` is that it is executed during the cmake configuration phase, which allows the configuration information of dependent projects to be introduced into the main project, unlike `ExternalProject`, which is executed during the build phase. This is quite useful especially for dependency projects built with cmake, because the configured cmake target of a dependency project can be used directly in the main project via `add_subdirectory` (e.g. `gtest::gtest`), instead of having to manually configure the dependency's header directories, static or shared libraries, compilation options, install directories, etc. and keeping maintaining these redundant information in the main project. This also makes git submodules unnecessary: by `FetchContent`, dependencies can be downloaded and configured at the cmake configuration stage, and URLs and commit hash/tag can be flexibly adjusted based on cmake options. There are NOT a lot of dependencies in kvrocks, and I think using `FetchContent` to manage dependencies as opposed to `ExternalProject` will improve the development experience. Of course, introducing a dependency manager such as vcpkg or conan may be a good option, but it introduces additional complexityin development and build management, so there is a trade-off. I'm happy to provide PRs if that sounds like a good idea. @tisonkun -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
