Closed Bug 643817 Opened 14 years ago Closed 14 years ago

Replace xpt_link/dump with pyxpt

Categories

(Firefox Build System :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla6

People

(Reporter: glandium, Assigned: glandium)

References

()

Details

Attachments

(2 files)

Everything is in the summary
Blocks: 602245
Attached patch Patch (deleted) — Splinter Review
python code is current trunk on your pyxpt repo. As for the config.mk/rules.mk changes, I didn't think there was much interest in complicating things to keep the dependency for xpt files on XPIDL_LINK, the error message in case XPIDL_LINK doesn't work should be as explicit as a dependency miss.
Attachment #521078 - Flags: review?(ted.mielczarek)
Comment on attachment 521078 [details] [diff] [review] Patch The build bits look fine, but since I wrote all that Python code, someone else needs to give this a once-over. I don't know if bsmedberg has the time or inclination to review it, but if not, perhaps catlee would?
Attachment #521078 - Flags: review?(ted.mielczarek) → review+
Attachment #521078 - Flags: review?(shaver)
Attached patch Test patch (deleted) — Splinter Review
I used this patch to try to see how things differ, and I hit a breakage pretty early: cmp _xpidlgen/xpcom_base.xpt _xpidlgen/xpcom_base-new.xpt _xpidlgen/xpcom_base.xpt _xpidlgen/xpcom_base-new.xpt differ: char 24, line 3 make[5]: *** [_xpidlgen/xpcom_base.xpt] Error 1 However, if I xpt_dump both, the output is exactly the same.
If I don't compare the files directly but compare dumps instead, I can go further, but stop again later: --- obj-i686-pc-linux-gnu/xpcom/components/_xpidlgen/xpcom_components.xpt.dump 2011-03-25 09:34:00.702062243 +0000 +++ obj-i686-pc-linux-gnu/xpcom/components/_xpidlgen/xpcom_components-new.xpt.dump 2011-03-25 09:34:00.702062243 +0000 @@ -8,8 +8,6 @@ Interface Directory: - ::nsIFile (00000000-0000-0000-0000-000000000000): [Unresolved] - - ::nsISimpleEnumerator (00000000-0000-0000-0000-000000000000): - [Unresolved] - ::nsISupports (00000000-0000-0000-c000-000000000046): [Unresolved] - ::nsIFactory (00000001-0000-0000-c000-000000000046): @@ -114,3 +112,5 @@ uint32 createInstanceByContractID(in string, in nsISupports, in nsIID &, out retval InterfaceIs *); Constants: No Constants + - ::nsISimpleEnumerator (d1899240-f9d2-11d2-bdd6-000064657374): + [Unresolved]
I investigated this, and it looks harmless. My patch from bug 455512 ( http://hg.mozilla.org/mozilla-central/rev/a78f9bb9006e ) attempted to make xpt_link prefer unresolved interface descriptors with a valid IID, but apparently that's broken and it prefers the ones with zero IIDs. xpt.py gets it right, so that's the only difference, This difference disappears in the final linked xpt, since all interfaces are resolved at that point. I think we simply declare the xpt_link binary buggy and move on in life.
Attachment #521078 - Flags: review?(shaver) → review?(benjamin)
Attachment #521078 - Flags: review?(benjamin) → review+
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
Ftr, http://hg.mozilla.org/comm-central/rev/e11c23c9a55b "Fix xpt_link bustage from bug 643817 as it got replaced with xpt.py."
Depends on: 650476
Depends on: 651975
Depends on: 654448
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: