feat: support GGML_BACKEND_DIR environment variable

[o7si]

Currently, CMake supports setting the GGML_BACKEND_DIR variable to specify the backend installation path:

llama.cpp/ggml/CMakeLists.txt

Line 80 in 583cb83

set(GGML_BACKEND_DIR "" CACHE PATH "ggml: directory to load dynamic backends from (requires GGML_BACKEND_DL")

This path gets embedded into the code as a search path:

llama.cpp/ggml/src/ggml-backend-reg.cpp

Lines 521 to 531 in 583cb83

	std::vector<fs::path> search_paths;
	if (user_search_path == nullptr) {
	#ifdef GGML_BACKEND_DIR
	search_paths.push_back(fs::u8path(GGML_BACKEND_DIR));
	#endif
	// default search paths: executable directory, current directory
	search_paths.push_back(get_executable_path());
	search_paths.push_back(fs::current_path());
	} else {
	search_paths.push_back(fs::u8path(user_search_path));
	}

However, in some cases, users may need to adjust the backend path for various reasons, which would invalidate the embedded path in the code.

This PR adds an environment variable to improve this situation by allowing runtime path configuration.

Related Issue:

• Misc. bug: CPU backend loader does not respect LD_LIBRARY_PATH #17491
• cmake: Add GGML_BACKEND_DIR option #15074

[o7si]

Both the macro and environment variable use the same name GGML_BACKEND_DIR. To avoid confusion, should I rename the macro from GGML_BACKEND_DIR to GGML_BACKEND_INSTALL_DIR?

[ckastner]

I think this is a useful idea, for example when experimenting with other backend builds / third-party backends. There already exists a GGML_BACKEND_PATH but AFAICT that's for a single backend.

Personally I would expect that GGML_BACKEND_DIR would supersede a build-time GGML_BACKEND_DIR, but from how I read ggml_backend_load_best(), all backends in search dirs are looked at and the best is chosen. But if this is a problem, it probably deserves its own PR.