CMake port of graph-tool

Here is a CMake port

May I ask what was the motivation for this? What required you to used CMake or what problem did that solve?

Do you intend to maintain this port in the long run?

I’m aiming for a SYCL-accelerated particle-MCMC library in C++, where other dependencies are CMake-based. The plan is to use this for epidemological optimal control on multiple hierarchy levels.

I’ve been working on learning CMake structuring and packaging recently, so I figured that this would be a good way of learning how the graph_tool library is structured and at the same time learn how to handle CMake package distribution.

I can’t guarantee a consistently stable CMake-port, but I considered this a better option than to learn and modify autotools.

I find CMake to be more generic than autotools. The CMake-port only utilize files located in ./cmake, ./CMakeLists.txt and ./src/graph/CMakeLists.txt to handle configuration, build and installation, along with files in ./package for pip wheels.

New source files introduced in subdirectories of ./src/graph are automatically globbed and added to their respective .so libraries, while modifications in ./src/graph_tool are added to the pip wheel.

I don’t know how large the build and install differences between the autotools and CMake configurations are, but I don’t think it will have a lot of maintainability issues if you want to pull it into your branch.

Graph-tool is packaged downstream on many platforms (Debian, homebrew, conda, etc). Changing the build system will surely break all of them. I would only consider doing that if there were clear advantages, but I don’t see them at the moment.

In fact, I find it worrying that you felt you needed to port graph-tool to CMake so that you could incorporate it as a dependency of another CMake project. A robust build system wouldn’t care about this.

I’ve used this as an example for learning how to use CMake for packaging (And simoultaneously see how graph_tool is structured) , but I don’t have any experience with repository distribution.

If the fork is disruptive and cause issues with respect to the main distribution, I can mark it as stale and revert to using pkconfig-files from the main branch.

I think that autotools is suboptimal in many ways, and if I was creating graph-tool from scratch now (instead of almost 17 years ago!), I probably would not consider using it. I think that CMake might be a better alternative, but at the moment it’s not clear to me what problem it would actually solve.

You mentioned that CMaka allows you to create Python wheel packages. How does that work? Is it automatic?