cmake help! - update w/ latest seastar cmake
emaxerrno opened this issue · comments
#contributors/help w/ cmake pls!
Seastar added a complicated cmake set up here:
I found cmake-cooking.sh hard to understand.
I think it does:
ExternalProjectAdd and given how cmake build systems are I'm sure it's doing the right thing under the covers.
It uses (i think standard ML) to generate a bash script.
This bash script contains a giant string.
The string is a cmake macro
This cmake macro builds & passes through arguments for ExternalProjectAdd
It build them and tells cmake to add it.
It builds them w/ default options (we want to change some options to make them as static a build as possible)
I'm not sure if cmake-cooking.sh is a good fit for this project to use.
Ideally we should strive to have as a static of a compilation as we can it gives the compiler much more room for optimizing function calls etc.
We already have a git submodules for some dependencies and some apt-get or dnf-install dependencies. The mix is less than ideal. We should do one consistently. I vote for explicitly declaring all our deps. Testing against a known set and supporting that.
I like jessies idea of a recipe but as the main way of building this project.
We can say we tested against a known set of dependencies. Harder to find ABI crashes and try to debug other issues in practice. Except of course for openssl / gnutls (makes making security updates easier)
Jessie already did a lot of hardwork here: https://github.com/scylladb/seastar/blob/master/recipe/dev.cmake
We can try to make that our main dependency file. But of course it requires cmake-cooking.sh macro.
A potential route is we render it and just save it to a cooking.cmake and use it as is for the first pass.
The ideal scenario would be for all our deps to be an ExternalProjectAdd type of defs.
Alternative designs are welcomed.
/cc @noahdesu =) we need your wisdom.
I'll check this out tonight. One thing to do is watch for what happens here: https://github.com/ceph/ceph/blob/master/src/CMakeLists.txt#L279
What about installing seastar and using the pkg config? My only fear here is when smf decides to bump dependencies. That seems like a nightmare to manage
@Lwelch45 I'm not sure i understand the bumping dependencies part.
Seastar deps actually haven't changed - just the way of providing the dependencies. From submodules to ExternalProjectAdd or apt-get-install-type libs. (they had some of this reqs already).
I try to update seastar pretty often. if you look at the history the last pull is probably the longest because I was waiting for this giant patch to land upstream. I'll make sure that smf is updated frequently - it's used in projects that are kept pretty up to date w/ upstream.
So for smf-downstream projects, we'll provide a standard way - similar to smfrpc/getting-started-cpp.
this is new build setup is super confusing. no doubt some projects (like ceph) that had been just doing add_subdirectory will need to figure all this out too and maybe there'll be a specific solution for this scenario.
i think the best approach for smf is sorta dependent on how much time there is to throw at it.
-
definitely someone if they haven't already should reply on the mailing list asking for a example of using add_subdirectory or something of equivalent simplicity. their setup seems comprehensive, so maybe it just isn't documented.
-
the right-now solution is probably to just call
./configure.py --mode=release; ninja whateverfrom AddExternalProject. So much for using cmake.
installing seastar as a dependency (either in /usr) or a user-local directory and pointing smf CMake at the CMake build configuration files produced by seastar would also be simple, it would just make smf build instructions a bit more complex.
Let me know what you think of those options, I'm happy to help with whatever is decided.
@noahdesu the issue w/ ./configure.py is that compiler flags, optimization, portability, etc are all compromised by shelling out.
Is there a way to leverage their dev.cmake file as our potential main dependencies for seastar. That kinda would solve it.
One interesting note is that I am open to doing what ceph does w/ the git submodule & add_subdirectory().
I think - from what I can tell ( & maybe wrong) - is that the new seastar cmake file just wants users to fulfill the dependencies themselves either via apt-get or somehow such that find_pkg(SOME_THING) would resolve.
So in the submodule case we can call add_subdirectory(...)/ExternalProjectAdd before calling add_subdirectory(seastar) so that it can find their transitive packages.
so the shelling out seems less exciting to me.
Thoughts?
Yeh ok I'm seeing now something that is more promising. Have you been able to build seastar yet by just cloning and running cmake .; make?
installing seastar as a dependency (either in /usr) or a user-local directory and pointing smf CMake at the CMake build configuration files produced by seastar would also be simple, it would just make smf build instructions a bit more complex.
This is what I was referring to @senior7515 if we do the install in /usr upgrading to the latest head of seastar every time would require an uninstall of seastar from the machine unless I missed something.
yeh. i would say this is a last resort solution, though it really isn't that bad. install to $HOME/install or whatever. Eventually I would assume Seastar reaches a level of maturity that this is feasible, but at this point it's moving fast so tracking HEAD as a sub-module is nice.
To be clear, the AddExternalProject approach is effectively the same thing, it is just that the installation directory is hidden and managed by Cmake.
What i like best about add_subdirectory is actually the clean compiler interface.
i.e.: compiling w/ debug symbols compiles all deps w/ debug symbols giving nice stack tracers.
Changing a compiler flag, adding link time optimization, or whole program optimization becomes possible if all deps can be reasoned about by the build system. not to mention sanitizer flags, etc.
Maybe a nicer interface is git submodules for those that have cmake already and for those that don't we use ExternalProjectAdd
@noahdesu what about this approach: https://github.com/abseil/googletest/blob/master/googletest/README.md
So it generates 1 CMakeLists.txt file per downloaded dep & then we add it to our repo.
So it would download deps per every release target (Debug,Release) but that's OK. and what's nice about this is that we keep the same niceties of git submodule but without the git module tracking.
yeh i think add_subdirectory should still work, i just haven't yet figured out how to get seastar to build without running the cooking script yet. that's not a deal breaker, but it would make things simpler.
so this is merged in master now.
Closing. The sample projects have been updated too.
@Lwelch45 - the latest smfrpc/smf-getting-started-cpp project has the updated build system.
Everything is local let me know if you test it.