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.

[MaggotHATE]

@slaren answering your question here: it's not about just building commands - I personally find Makefile easier to organize and maintain even despite all of its problems. I don't see much reason to use CMake for a relatively small personal project that targets one-two platforms. Maybe keeping Makefile small like proposed will solve the issue of maintenance.

Standardizing on only one build system is good, but removing the alternatives completely will cut off a portion of developers and will potentially create more questions in future.

[Man2Dev]

I believe removing the versus build system and maintaining a clean CMake setup makes the most sense. By having a single method for customizing the build, it simplifies writing detailed documentation and enhances maintainability. This approach can also benefit third-party software.

[wtarreau]

What's the correct way to run "make clean" now ? I couldn't find one in the docs when looking for "clean". I had to run a pretty disgusting:

find . -name '*.[ao]' | xargs rm

after changing options in order to rebuild, that I really don't like at all.

[wtarreau]

Apparently that was not even sufficient, options were kept, I had to rm -rf build. There's likely something cleaner, right ?

[danbev]

With cmake it should be possible to use the generated clean target:

$ cmake --build build --target clean

And if you want to regenerate the cmake cache (if you have changed cmake options for example):

$ cmake --build build --target rebuild_cache

To see the list of available targets:

$ cmake --build build --target help

[wtarreau]

Thank you! Maybe it would be useful to mention this in the "make" error ? "make clean" is the universal method to clean a project (and way more intuitive to remember) than the command above that one will systematically need too look up right here.

[danbev]

The make build is currently being deprecated. You can still use it by specifying the environment variable LLAMA_MAKEFILE though, for example:

$ env LLAMA_MAKEFILE=1 make clean

[wtarreau]

OK but my point is that all these info are difficult to find. I mean, I'm a developer and I couldn't figure out how to clean by looking around. That's why I'm suggesting that trivial and more importantly standard things like "make clean" continue to work or at least emit "you should now use cmake --yadayada etc ..." so that users can find the info they're looking for.