On Sat, Nov 16, 2013 at 4:34 AM, Ms2ger <ms2...@gmail.com> wrote: > On 11/14/2013 11:49 PM, Ehsan Akhgari wrote: > >> I've started to work on a project in my spare time to switch us to use >> unified builds for C/C++ compilation. The way that unified builds work is >> >> by using the UNIFIED_SOURCES instead of the SOURCES variable in moz.build >> files. With that, the build system creates files such as: >> >> // Unified_cpp_path_0.cpp >> #include "Source1.cpp" >> #include "Source2.cpp" >> // ... >> >> And compiles them instead of the individual source files. >> > > One issue I only thought of today: this means that Source2.cpp can use all > headers included into Source1.cpp–until enough files are added between > Source1 and Source2 that Source2 ends up in the next unified file. This > hasn't been much of an issue for autogenerated C++, but it seems like it > could be harder to get right with hand-written C++. >
Yes, that's correct. > One way around it would be not to unify sources in automation. On one > hand, this could cause more bustage when changes that built locally turn > out not to have enough includes; on the other, it might be better than > having to fix up a dozen unrelated files whenever you add a new one. > I don't think that we need to try to fix this problem any more than the general problem of denoting our dependencies explicitly. It's common for you to remove an #include from a header and find dozens of .cpp files in the tree that implicitly depended on it. And that is much more likely to happen than people adding/removing cpp files. We have enough bustage caused by differences in the way we build on our build slaves than the way that we build locally -- let's not add more of it. Cheers, -- Ehsan <http://ehsanakhgari.org/> _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
