My xpcshell binary fails to start with MOZ_PSEUDO_DERECURSE set to 1. Add no-skip works around the problem. The binary starts, then exits immediately with a 1 exit code.

Look like .xpt files aren't getting installed (among other things).

I thought all the xpt stuff was done with install manifests. It's not. Installing in dist/bin is still done in rules.mk, presumably because of FINAL_TARGET. It would be interesting to see why your "bad" build has some files that the other doesn't.

Comment on attachment 813086 [details] [diff] [review] XPIDL_SOURCES impacts the libs tier Review of attachment 813086 [details] [diff] [review]: ----------------------------------------------------------------- We abandoned doing the xpt foo properly because it was just beyond the pain threshold for the bug. Now that we have dist/bin under manifest control, it's very tempting to just do that now.

(In reply to Gregory Szorc [:gps] from comment #3) > We abandoned doing the xpt foo properly because it was just beyond the pain > threshold for the bug. Now that we have dist/bin under manifest control, > it's very tempting to just do that now. I don't think that's possible until FINAL_TARGET can be computed in recursivemake.py.

Yep. I filed bug 923080 with the proper dependency on FINAL_TARGET.

cc-ing sworkman. He met me yesterday while he debugging an XPCshell bustage that looked to happen with incremental build, but *not* happen with same changeset with a clobber build.

(In reply to John O'Duinn [:joduinn] from comment #7) > cc-ing sworkman. He met me yesterday while he debugging an XPCshell bustage > that looked to happen with incremental build, but *not* happen with same > changeset with a clobber build. You shouldn't have seen this failure in automation: only on local builds that have opted in to MOZ_PSEUDO_DERECURSE. And, the regression range for this bug was only a few hours on inbound. I highly doubt you hit this.