On Sat, Nov 16, 2013 at 10:34:38AM +0100, Ms2ger 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++. > > 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.
Another related problem is that of conflicting function or variable names, macros, etc. We're obviously fixing those when they need to be when unifying files in a given directory, but there is a chance a conflict is introduced by a file moving from Unified1 to Unified2. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
