The idea is to define a preprocessor macro when in unified mode which we can use to check certain patterns that we know must never occur in unified builds.

Comment on attachment 8336314 [details] [diff] [review] #define MOZ_UNIFIED_BUILD for everything that is compiled in unified mode; r=gps Greg, we need this pretty badly, so fast reviews are highly appreciated! :)

this is causing a regression from talos numbers in modified page list bytes by 27%: https://groups.google.com/forum/#!topic/mozilla.dev.tree-management/zMyoTUZQgKc http://graphs.mozilla.org/graph.html#tests=[[271,131,25]]&sel=none&displayrange=7&datatype=running For reference this is the history of adding this counter: https://bugzilla.mozilla.org/show_bug.cgi?id=558613. Is this regression desired?

It's not possible to cause that regression. However, the change caused all unified sources to be rebuilt, which means a partial clobber. It's very likely that the real cause of the regression is something that landed before this patch, required a clobber but didn't get one.

How can we determine when the last clobber build was done in the sequence of pushes to inbound?

(In reply to comment #7) > How can we determine when the last clobber build was done in the sequence of > pushes to inbound? You can examine each individual build log manually. I don't know if there is an easier way.

I looked at the build log for this: https://tbpl.mozilla.org/php/getParsedLog.php?id=30918686&tree=Mozilla-Inbound&full=1 it doesn't appear to be a clobber from looking at the log file. If there is a way to determine that in the log file, please outline it here.

Not sure why you reopened this bug. (In reply to Joel Maher (:jmaher) from comment #9) > I looked at the build log for this: > https://tbpl.mozilla.org/php/getParsedLog.php?id=30918686&tree=Mozilla- > Inbound&full=1 > > it doesn't appear to be a clobber from looking at the log file. If there is > a way to determine that in the log file, please outline it here. See the entry marked as "Started checking clobber times" in the log. That code reaches out to a web server giving you a timestamp of the clobberer for the current tree, and we choose whether to clobber based on that. Please ask one of our sheriffs for a more accurate answer, I haven't done this stuff in a while.

Joel did, the log quoted in comment 9 was not a clobber, neither from the releng side, nor the in-tree CLOBBER file.

I filed bug 942920 to track this, we will need to fix this prior to the next uplift.