I think it may be worth having a cmake flag to build all the common CPU backend variations in a single build rather than having to build multiple times and combining the backend libraries.
Having this would make it easier to maintain a centralized list of the common configurations that would be supported by projects that use llama.cpp.

Yes, I agree that would be better. TBH selecting the variants is a headache because there are so many options and each microarchitecture supports a different subset of them, so I didn't want to think too much about it. It might make more sense to build a variant for each microarchitecture, but there is going to be a lot of them.

Is there an advantage to building a separate binary for each microarchitecture over determining what features can used on runtime?
I've seen both runtime and compile-time feature detection in the codebase, but I'm not sure I understand why some features are detected only on compile-time.
Having a single binary that can adapt to the system it runs on would be much easier to use, so I'm wondering what are the limitations of this approach.

That's not really an option for many reasons. It would probably require rewriting all the code in ASM and using a JIT compiler.
Why would that be easier to use? The best backend is loaded automatically, it doesn't require you to do anything.

The more variations of the CPU backend compiled with different flags means more duplication of the same code, which would increase the total build size.
Also, having many different variations with different combinations of flags would produce many more files and can take much longer to compile as more variations are added over time.
I was thinking more towards extracting the relevant functions to very small libraries that can be loaded dynamically based on runtime feature detection for this, rather than loading the entire backend compiled with different combinations of flags.

I was thinking more towards extracting the relevant functions to very small libraries that can be loaded dynamically based on runtime feature detection

That's pretty much what this is already. The build time and build size is not really significant, the CPU backend builds very quickly and most variants are below 500kB in size. E.g. these are the variants built in #10626:

-rwxr-xr-x 1 diego diego 412K Dec  2 23:58 libggml-cpu-alderlake.so*
-rwxr-xr-x 1 diego diego 412K Dec  2 23:58 libggml-cpu-haswell.so*
-rwxr-xr-x 1 diego diego 488K Dec  2 23:58 libggml-cpu-icelake.so*
-rwxr-xr-x 1 diego diego 412K Dec  2 23:58 libggml-cpu-sandybridge.so*
-rwxr-xr-x 1 diego diego 709K Dec  2 23:58 libggml-cpu-sapphirerapids.so*
-rwxr-xr-x 1 diego diego 488K Dec  2 23:58 libggml-cpu-skylakex.so*

Then all is good. Thanks for explaining :)