There are 3 configuration values here. The default value is for zig to automatically decide whether to use any of these three projects or to use its own implementations. These flags switch from the default value to override a forced choice.
By default, Zig will use its own backend for Debug builds, and LLVM for release builds. It will use its own linker code for Debug builds and LLD for release builds. It will also prefer LLD for linking when third party objects, libraries, or a linker scripts, or other advanced features are used that Zig's own linker does not support. For example when compiling C source files, Zig will prefer to use its own linker to write an object file, but then use LLD to link that together with the objects produced from compiling C source files. It will use Clang for @cImport and compiling C source code, assembly files, preprocessor, and other miscellaneous things. However -fno-LLVM could be used to force zig to make a release build without the LLVM backend, and likewise -fno-LLD could be used to force Zig to always use its own linker (even if that would result in an error). Using -fno-Clang will cause all translate-c and C compilation features to result in an error, unless the proposal to add a C frontend is accepted and implemented, in which case you can see how that would fit in here.
For a zig compiler which does not have LLVM extensions compiled in, the automatic choice that zig will make for all 3 of these values is equivalent to if -fno-LLVM, -fno-LLD, -fno-Clang had been passed. Additionally passing these arguments redundantly is no problem and will have no effect.
Passing -fLLVM, -fLLD, or -fClang to a zig compiler which does not have LLVM extensions compiled in will result in an error message such as, "cannot use LLVM backend; compiler was not built with LLVM extensions enabled".
There are 3 configuration values here. The default value is for zig to automatically decide whether to use any of these three projects or to use its own implementations. These flags switch from the default value to override a forced choice.
By default, Zig will use its own backend for Debug builds, and LLVM for release builds. It will use its own linker code for Debug builds and LLD for release builds. It will also prefer LLD for linking when third party objects, libraries, or a linker scripts, or other advanced features are used that Zig's own linker does not support. For example when compiling C source files, Zig will prefer to use its own linker to write an object file, but then use LLD to link that together with the objects produced from compiling C source files. It will use Clang for
@cImportand compiling C source code, assembly files, preprocessor, and other miscellaneous things. However-fno-LLVMcould be used to force zig to make a release build without the LLVM backend, and likewise-fno-LLDcould be used to force Zig to always use its own linker (even if that would result in an error). Using-fno-Clangwill cause all translate-c and C compilation features to result in an error, unless the proposal to add a C frontend is accepted and implemented, in which case you can see how that would fit in here.For a zig compiler which does not have LLVM extensions compiled in, the automatic choice that zig will make for all 3 of these values is equivalent to if
-fno-LLVM,-fno-LLD,-fno-Clanghad been passed. Additionally passing these arguments redundantly is no problem and will have no effect.Passing
-fLLVM,-fLLD, or-fClangto a zig compiler which does not have LLVM extensions compiled in will result in an error message such as, "cannot use LLVM backend; compiler was not built with LLVM extensions enabled".