make : deprecate

[ggerganov]

ref #10268

Disabling the Makefile unless LLAMA_MAKEFILE is defined. This should give more focus for the CMake build and will help clean-up any usage of make in the existing CI. The Makefile will be eventually removed or stripped to a very minimal version.

[MaggotHATE]

stripped to a very minimal version

That would be a much more preferred option. Like LostRuins mentioned in the original discussion, Makefile is a very simple and handy option that gives additional flexibility to projects that use llama.cpp, and it is multiplatform.

If you see the current state of Makefile as a burden, it is worth at least leaving a simplified version - for example, main and server as the most popular applications. This would serve not only as a quick "build and test" option, but also as an example for those who use Makefile in their projects. Then, for all advanced options users can be directed towards CMake only.

[slaren]

Is there a single platform that does not have easy access to cmake? If typing two commands instead of one is too much effort, we can always have the Makefile run cmake. In any case, let's keep that discussion to #10268.

[ggerganov]

Need to fix the scripts/compare* to use CMake builds instead of the Makefile and we can merge. The Swift build can be fixed later in #10525.

[max-krasnyansky]

Very nice!
Good to see mostly deletions in the changes :)

[jboero]

This breaks the SRPM specs again. Does anybody who uses the RPM specs have a preference for cmake+libs vs make+static builds? The rate things change in cmake I'm tempted to just stick with static Makefile builds, rather than mess with rpath issues, shared objects, and extra binaries.

[slaren]

If you want a static build just disable BUILD_SHARED_LIBS. Do not use make, it will be removed completely in the future.

I am not sure how people are using the RPMs, but if the goal is to distribute binaries, then you should use shared libraries, GGML_BACKEND_DL and GGML_CPU_ALL_VARIANTS to ensure best compatibility and performance.

[jboero]

#10663

Unfortunately packaging RPMs isn't quite so simple. Every time a build change refactors out a different library or file the rpm inventory needs to be updated to list which files it includes. This was breaking quite a bit of my COPR build automation as updates arrived so I stuck with static builds.

I suppose the proper way to do this would be refactor out separate RPMs for just libs and server binaries, etc.