On 2014-09-03, 11:56 PM, Joshua Cranmer 🐧 wrote:
The worst offender is the list of source files: it is passed down as a VariablePassthru in CSRCS, CPPSRCS, etc., and UNIFIED_CSRCS, UNIFIED_CPPSRCS, etc. If you want to distinguish between source files in the build directory and source files in the source directory, the only way you can check is by peeking in GARBAGE. The logic for producing unified builds happens in recursivemake.py, and I'm not sure how a clang compilation database should handle that (considering it's a useful trick for speeding compile times, and users clang compilation databases are likely to want very fast world-rebuild times, though, it seems like it should use it as much as possible).
I think that for most of the use cases for the compilation database, the speed of compilation is crucial. Have you considered not emitting the unified build info in the compilation database at all, and just pretend that UNIFIED_SOURCES are SOURCES? That will of course mean that the generated compilation database will not map the exact builds we perform, but it will mean that clang will have less code to deal with so things will be faster. And I think as far as compiler flags etc go, this should be fine since all unified source files are compiled with the same flags by definition (you are not allowed to do UNIFIED_SOURCES['foo.cpp'].cflags += ...).
Cheers, Ehsan _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
