Closed Bug 1006541 Opened 6 years ago Closed 5 years ago

Running mach build modifies tools/quitter/chrome.manifest

Categories

(Firefox Build System :: General, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: mccr8, Unassigned)

References

(Blocks 1 open bug)

Details

If I have an unmodified directory, then do ./mach build, near the end it says this:
   1:01.20 Packaging quitter@mozilla.org.xpi...

Then somehow tools/quitter/chrome.manifest is modified, which shows up in git:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   tools/quitter/chrome.manifest

The diff is this:

diff --git a/tools/quitter/chrome.manifest b/tools/quitter/chrome.manifest
index feffe54..b01f046 100644
--- a/tools/quitter/chrome.manifest
+++ b/tools/quitter/chrome.manifest
@@ -1,4 +1,4 @@
-content quitter chrome/quitter/content/
+category profile-after-change @mozilla.org/quitter-observer;1 @mozilla.org/quitter-observer;1
 component {c235a986-5ac1-4f28-ad73-825dae9bad90} components/QuitterObserver.js
+content quitter chrome/quitter/content/
 contract @mozilla.org/quitter-observer;1 {c235a986-5ac1-4f28-ad73-825dae9bad90}
-category profile-after-change @mozilla.org/quitter-observer;1 @mozilla.org/quitter-observer;1

So I have to repeatedly do a git checkout -- tools/quitter/chrome.manifest which is obviously not great. :)  This is a recent regression.
Summary: Running mach build tools/quitter/chrome.manifest → Running mach build modifies tools/quitter/chrome.manifest
I think this was caused by bug 1005704, though I'm not totally sure why yet. Still looking into it...
Hmm, I don't have any idea how this might be happening. :(  Should I back out bug 1005704?
Oh... I can actually reproduce...
It seems like something is sorting chrome.manifest...
Oh, it's because using INSTALL_TARGETS makes obj/dist/xpi-stage/quitter/chrome.manifest a symlink back to the srcdir now (instead of a copy), so when jar.py tries to update chrome.manifest, it's changing the original.
Ah, I see...  OK, any ideas how we should fix it?
Not off-hand - I'm currently trying to see if we can make jar.py use an input manifest (the srcdir one) and write to the output manifest (the objdir one), then we can just remove chrome.manifest from the INSTALL_TARGET.
Blocks: 1005704
Just don't install chrome.manifest as a symlink.
(In reply to Mike Hommey [:glandium] from comment #8)
> Just don't install chrome.manifest as a symlink.

Do we have a way to do that? Or are you suggesting a custom INSTALL call in libs:: or something? I don't see a way to have INSTALL_TARGETS not do a symlink, but maybe I'm just missing it.
(In reply to Michael Shal [:mshal] from comment #9)
> Do we have a way to do that? Or are you suggesting a custom INSTALL call in
> libs:: or something? I don't see a way to have INSTALL_TARGETS not do a
> symlink, but maybe I'm just missing it.

I'd say just back out the part that changed how it's installed.
+1 reproducing this. This will make us hard to maintain the HG patches.
FWIW, I've now seen this make it into at least one patch posted on Bugzilla: attachment 8418822 [details] [diff] [review].

In any case, this should now be fixed on m-c by ehsan's backout of bug 1005704.
fixed by backout
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.