On Tue, Nov 19, 2013 at 11:04:25AM +0800, L. David Baron wrote: > On Monday 2013-11-18 18:44 -0500, Ehsan Akhgari wrote: > > On 2013-11-17 7:50 PM, L. David Baron wrote: > > >On Sunday 2013-11-17 16:45 -0800, Jonas Sicking wrote: > > >>On Thu, Nov 14, 2013 at 2:49 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> > > >>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" > > >>>// ... > > >> > > >>Doesn't this negate the advantage of static global variables. I.e. > > >>when changing how you use a static global, rather than just auditing > > >>the .cpp file where that static global lives, you now how to audit all > > >>.cpp files that are "unified together". > > > > > >Could we do a static analysis to look for things whose semantics are > > >changed by this unification, such as statics with the same name > > >between files that are/might be unified? (And could we make the > > >tree turn red if it failed?) > > > > That analysis is quite hard to perform if we try to catch all kinds > > of such leakage. I think a periodic non-unified build is a much > > better way of discovering such problems. > > I'm inclined to think it'll need to be more than periodic, actually. > > I expect that otherwise we'd get pretty frequent bustage with people > forgetting to add #includes, and that bustage would then show up > when we add or remove files, which would make it a huge pain to add > or remove files. > > But I'm actually also worried (perhaps *more* worried) about cases > where there are semantic differences but things will still compile, > such as two static variables of the same name and type, in different > files (e.g., "static bool gInitialized"). We could end up with > breakage both because of code that expects such variables to be > distinct, or from new code that expects such variables to be merged.
The spilling of "using namespace" across source files could also cause some headaches. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
