RFC : standardize on cmake and remove other build systems

[slaren]

Currently we have at least these build systems in llama.cpp:

• cmake
• make
• Nix
• Swift

As the project grows, the build process becomes more complicated and maintaining all of these build systems takes a significant amount of time that could be spent in more meaningful development. Additionally, it prevents adding more advanced logic to the build because having to replicate it in every other build system is not really feasible.

In my opinion there is little reason to not standardize on cmake and remove the other build systems. Compared to make, it is just one more command to build the project. The Makefile has grown to be an unmaintainable mess that effectively requires running make clean every single time because it has no idea of what are the dependencies of each source file. Build systems such as Nix can live in a separate repository where the people interested in them can keep them updated, but we should not absorb the maintenance cost of other projects. The swift build might make more sense in a separate repository together with llama.cpp API bindings.

This is not the first time this has been proposed, but in my opinion we are finally at a point where it is no longer reasonable to continue maintaining multiple build systems. I would be interested in hearing what are the opinions of other people in the community.

[max-krasnyansky]

This would be my preference as well.
CMake only at this point.

[JohannesGaessler]

I am currently using make (for local development builds) but this is simply force of habit and I don't mind at all switching to CMake. I myself would definitely not be willing to invest the effort to maintain the Makefile.

[ggerganov]

The swift build might make more sense in a separate repository together with llama.cpp API bindings.

The problem with this is that the new potential repository (e.g. llama.spm) would need to have a copy of the llama.cpp source tree since SPM is not advanced enough to support git submodules. So I think it would be more maintenance to move the SPM package out of the project. I used to do it like this with https://github.com/ggerganov/whisper.spm, but eventually moved the SPM package inside whisper.cpp to reduce the extra hassle of synchronizing the whisper.cpp code base with whisper.spm.

[slaren]

I don't know how swift handles interoperability with C/C++, but it seems overly restrictive to require to build the C/C++ code entirely within the Package.swift file. My intuition is that there must be a way to use cmake to build the C/C++ sources, otherwise many projects would have the same issue. A quick search shows that cmake has some compatibility with Swift, but I am not sure what would entail to use it to build a swift-compatible library.

[ggerganov]

I actually haven't considered to have the SPM package just provide bindings to the C/C++ library. Maybe this is the correct way to do it. It will still be a little bit of extra work for the 3rd party projects, because they would have to provide the llama.cpp binaries, but with the new CMake builds, this should be easy.

Overall I am OK with the proposal in this issue to make the CMake build the standard and drop support for the rest of the builds. Btw, one thing to keep in mind is to make effort to keep the required CMake version as low as possible. Currently we require 3.18 for the CUDA builds which is relatively OK. But even today, every now and then I still have to deploy llama.cpp on some Ubuntu 20.04 machine for example that does not have the necessary CMake version and it becomes a bit of a hassle to provide it.

[LostRuins]

I don't use nix or swift, but I do enjoy the simplicity of makefiles and how they just work out of the box even on things like w64devkit or Termux.