I agree with everything Mark said in his reply I just wanted to add another benefit of having a non-unified build specifically to support build time optimization.
> > 2) In my contributions, I don’t just want to add missing includes, I want > > to remove unnecessary ones taking full advantage of forward declarations > > and moving code out of headers. Too many includes and too much dependency > > has a dramatic bad effect on the project, making colossal project build > > times even worse. > I too try to do this when writing my patches. I would argue that a > non-unified EWS gives me greater confidence that a forward declaration is > sufficient, and that I’m not just mistakenly thinking that it is only because > some other file in the same unified unit also happen to include the header. > So, again, a non-unified EWS is helping here. If we wanted to try any tooling around identifying when an include or forward declaration should be used we need a functioning non-unified build. We could try IWYU on the codebase, https://github.com/include-what-you-use/include-what-you-use , and see what happens. There's also tools for analyzing where the build is spending its time. For Clang users the ClangBuildAnalyzer could be used, https://github.com/aras-p/ClangBuildAnalyzer . For Visual Studio a project that looks interesting is CompileScore, https://github.com/Viladoman/CompileScore . _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
