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.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
