ben.boeckel added a comment. There is another motivating factor for 1-phase: the build graph is far simpler. With 2-phase, CMake will have to write out rules to perform:
- source -> .bmi - .bmi -> .withbmi.o - source -> .o because we do not know if a BMI is needed or not. If it isn't we use the latter. If it is, we use the former. Note that this also means we need 2 different `.o` filenames (as neither `make` nor `ninja` doesn't support multiple rules making the same output). This also means that the collator needs to generate a response file for the linker to direct which `.o` file to use for each TU based on the contents. Also with 2-phase, it is an open question of whether it actually helps with distributed builds (or anywhere process execution and I/O are expensive compared to some minimal work unit such as, say, Windows compiling from a network drive). Since this is not a bright line, giving the option to say "I know that split BMI is better for me in this instance" and "please combine here" would be handy (depending on actual real-world perf results on real-world projects). Yes, this is a chicken-and-egg cycle :) . Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D137059/new/ https://reviews.llvm.org/D137059 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
