Closed
Bug 293485
Opened 20 years ago
Closed 19 years ago
Changing an IDL file does not rebuild IDLs that include it (IDL dependencies)
Categories
(Firefox Build System :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bugzilla-mozilla-20000923, Assigned: neil)
Details
Attachments
(4 files, 1 obsolete file)
|
4.34 KB,
text/plain
|
Details | |
|
2.90 KB,
patch
|
Details | Diff | Splinter Review | |
|
11.14 KB,
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
|
10.41 KB,
patch
|
benjamin
:
review+
shaver
:
superreview+
|
Details | Diff | Splinter Review |
Many IDL files include others, but no provision is made for this in the rebuilding of XPTs and Hs. If an IDL file is changed, and another includes it, the XPT for the second interface will continue to reference the old UUID of the first, which then promptly breaks when it is used. I have a new Perl script that checks this dependency tree, and makes XPTs and Hs rebuild when anything they use changes.
| Reporter | ||
Comment 1•20 years ago
|
||
I'm attaching this first, so people can see just what it does and agree/disagree with the method it takes. The basic idea is to store a cache of the mtime of all the files used to make an XPT/H, and only rebuild if there is a change in at least one item. There are also some tweaks to rules.mk to call this script and rebuild only for certain return values.
| Reporter | ||
Comment 2•20 years ago
|
||
Just for completeness, here is my changes to rules.mk to support the Perl script.
| Assignee | ||
Comment 3•20 years ago
|
||
* Adds -d option to xpidl to generate .pp output * Tells rules.mk that .idl files generate .pp files I tried it on xpfe/components/search/public and it seems ok, so...
| Assignee | ||
Comment 4•20 years ago
|
||
OK, so it doesn't break my build. But I suppose the real test is to change some .idl file and see what happens.
Updated•20 years ago
|
Attachment #183489 -
Flags: review?(benjamin)
Comment 5•20 years ago
|
||
Comment on attachment 183489 [details] [diff] [review] xpidl dependency hack that I'll trial tonight I don't think I understand the IDLS bits in rules.mk... why use a wildcard instead of XPIDLSRCS?
Comment 6•19 years ago
|
||
Comment on attachment 183489 [details] [diff] [review] xpidl dependency hack that I'll trial tonight other than IDLS = $(strip $(wildcard *.idl)) this looks great! Why can't we use IDLS = $(XPIDLSRCS) $(SDK_XPIDLSCRCS) or something like that?
Attachment #183489 -
Flags: review?(benjamin) → review-
| Assignee | ||
Comment 7•19 years ago
|
||
Assignee: nobody → neil.parkwaycc.co.uk
Attachment #183489 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #206658 -
Flags: superreview?(shaver)
Attachment #206658 -
Flags: review?(benjamin)
Updated•19 years ago
|
Attachment #206658 -
Flags: review?(benjamin) → review+
| Assignee | ||
Comment 8•19 years ago
|
||
biesi pointed out that the .h files don't matter as it's the .cpp files that need to track dependency information. This allows me to trim the patch a little.
| Assignee | ||
Comment 9•19 years ago
|
||
Attachment #207081 -
Flags: superreview?(shaver)
Attachment #207081 -
Flags: review?(benjamin)
Updated•19 years ago
|
Attachment #207081 -
Flags: review?(benjamin) → review+
Comment 10•19 years ago
|
||
Comment on attachment 207081 [details] [diff] [review] Trimmed patch sr=shaver
Attachment #207081 -
Flags: superreview?(shaver) → superreview+
Comment 11•19 years ago
|
||
Comment on attachment 206658 [details] [diff] [review] improved patch and addressed review comments cancelling outdated (I think, though the patch isn't obsoleted) sr request
Attachment #206658 -
Flags: superreview?(shaver)
| Assignee | ||
Comment 12•19 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 13•18 years ago
|
||
I presume this leaks if someone does: -d foo -d bar :)
Updated•7 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•