chrome.manifest not updated after a manifest file is deleted
Categories
(Firefox Build System :: General, defect)
Tracking
(Not tracked)
People
(Reporter: mccr8, Unassigned)
References
(Blocks 1 open bug)
Details
For bug 1615109, I wrote a patch that deletes browser/components/webshare/SharePicker.manifest (the entire directory isn't needed) and updated browser/components/moz.build to remove the reference to the webshare directory. Then I wrote a patch that fatally asserts in DoRegisterManifest() instead of just doing the LogMessage with "Could not read chrome manifest".
Locally, if I did mach build and started Firefox, it would crash on the assert because it couldn't find SharePicker.manifest. I had to manually delete <objdir>/dist/bin/browser/chrome.manifest (which contains the line manifest "components/SharePicker.manifest"), then build again to get it to work.
The weirder thing is that I was hitting what I think was the same error on a try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1d979862d3f229b6fb153f3688b8441f348e76a7
I thought try builds were clobber builds, but maybe that's changed and so this is expected given the local build failure.
|
Reporter | |
Comment 1•4 years ago
|
||
Maybe I should make my patch in bug 1615109 do a clobber, though under normal circumstances failing to find a manifest file doesn't seem to have any real impact.
|
||
Comment 2•4 years ago
|
||
The weirder thing is that I was hitting what I think was the same error on a try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1d979862d3f229b6fb153f3688b8441f348e76a7
Even weirder: the corresponding build from mozilla-central, without your changes, doesn't contain any of the files you remove.
I thought try builds were clobber builds, but maybe that's changed and so this is expected given the local build failure.
No build on automation is incremental. Moreover, automation runs mach package, which changes manifests anyways.
|
|
||
Comment 3•4 years ago
|
||
As for the meat of the bug, it's a known issue that removing file is not well supported by the build system. Many of the dependencies of bug 941904 are essentially about that.
|
|
||
Comment 4•4 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #2)
The weirder thing is that I was hitting what I think was the same error on a try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1d979862d3f229b6fb153f3688b8441f348e76a7
Even weirder: the corresponding build from mozilla-central, without your changes, doesn't contain any of the files you remove.
I think the try failure is a red herring. You're probably hitting something that always already happen, but since your assert doesn't print the path, you think it's your patch doing it while what it's complaining about might be something else.
|
|
Reporter | |
Comment 5•4 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #4)
I think the try failure is a red herring. You're probably hitting something that always already happen, but since your assert doesn't print the path, you think it's your patch doing it while what it's complaining about might be something else.
Ok. I'll delete that from the summary.
| Comment hidden (obsolete) |
| Comment hidden (obsolete) |
|
|
Reporter | |
Comment 8•4 years ago
|
||
I filed bug 1626810.
|
||
Comment 9•4 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)
|
||
Comment 10•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
|
Reporter | |
Updated•4 years ago
|
Description
•