The primary use cases we have in mind for -ffat-lto-objects is improving build performance when sharing translation units between distribution and test binaries. For example, in our build of Clang distribution which uses LTO, having to perform LTO for binaries only used by tests doubles the total test time.
I agree that this could be in theory addressed through build system, but it’s not something I’m particularly keen on implementing. It would likely require an extra layer of indirection to choose either the native or LTO target for every dependency, and this selection would need to done transitively.
I know of a way to implement this idea in a build system like GN, since we already use a similar approach elsewhere in Fuchsia, and it’s one of the most complicated parts of our build that few people understand and is a source of significant maintenance overhead. I don’t know yet of a way to implement this in CMake; there might be one, but it would likely be non-trivial.
The biggest advantage of supporting this feature directly in the compiler and the linker is simplicity and convenience. Doing this inside the build system is going to require a lot of complexity that’s going to be duplicated across every project that wishes to use it, and it would be difficult to maintain.
Supporting -ffat-lto-objects would improve compatibility with GCC and ICC which already implement this option. I’ve done a quick search and found a number of projects that already use this feature (including Linux). It appears to be especially common in the embedded domain.
Using -ffat-lto-objects is also potentially more efficient since you don’t need to parse the code twice (although the potential benefit depends on the input and its complexity).
I agree that [RFC] A Unified LTO Bitcode Frontend should be a prerequisite for this feature.