On 2013-11-18 10:04 PM, 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.
This is something which we can easily measure over a period of time.
For example, this has not happened at least as of earlier today since
the first build unification patch that I have written. My gut feeling
is that this problem would not occur very often in practice, but I could
be wrong.
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.
We can definitely write static analyses for such specific cases
(especially if we have reason to believe that they may be common
problems.) If you have ideas for such analyses please file bugs.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
