Closed
Bug 592323
Opened 14 years ago
Closed 14 years ago
Fastload not invalidated after `make`ing on OS X
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: zpao, Assigned: benedict)
References
Details
Attachments
(1 file)
(deleted),
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
I chatted with Ben and he said running make should create a .purgecaches in obj/dist/bin, which it does. However on OS X we run MinefieldDebug.app and my fastload isn't invalidated, so I have to run it twice for my fastload to be invalidated.
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → bhsieh
Assignee | ||
Comment 1•14 years ago
|
||
Huh, didn't catch that earlier. So the situation is: make, run once (not invalidated), run again (now, invalidated)? I thought the situation was that running from MinefieldDebug.app means we don't find the .purgecaches file, but seems maybe that's not the case. Anyways, I have an OSX setup so I can look into this myself also.
Reporter | ||
Comment 2•14 years ago
|
||
(In reply to comment #1) > Huh, didn't catch that earlier. So the situation is: make, run once (not > invalidated), run again (now, invalidated)? Correct.
Reporter | ||
Comment 3•14 years ago
|
||
If you want to test my case as closely as possible... add a line in browser/components/sessionstore/src/nsSessionStore.js in init... dump("\n\nCAN'T MISS THIS LINE\n\n"); % make -C browser/components/sessionstore && make -C browser/app % ./dist/MinefieldDebug.app/Contents/MacOS/firefox -P whatever The dump won't show up the first time, but will the 2nd time you run. .purgecaches does exist in dist/MinefieldDebug.app/Contents/MacOS (everything in dist/bin gets rsynced when running make in browser/app). It gets put in dist/bin after the first make so get's rsynced. So perhaps it's looking for the file in the wrong place? It looks like it should be ok, unless there's something special that needs to be done on Mac...
Assignee | ||
Comment 4•14 years ago
|
||
Seems that the problem here is that >nsDirectoryService::gService->Get(NS_XPCOM_CURRENT_PROCESS_DIR, ...) is equivalent to >gAppData->directory on Linux but not on OSX. On OSX, the former returns [obj-dir]/dist/MinefieldDebug.app/Contents/MacOS, and the latter returns [obj-dir]/dist/MinefieldDebug.app/Contents/ Haven't tested on Windows, yet. Not sure if this is a bug in gAppData or intended. nsDirectoryService isn't available when I'm checking for the .purgecaches file, so maybe I need to check for it later in nsXPComInit.cpp. I'll ask around, just sticking these notes in the bug for now.
Assignee | ||
Comment 5•14 years ago
|
||
Yikes, the above comment is wrong in every way. Some bad test code / patch queues led me astray. I didn't investigate why it used to work on the second run, but this patch makes it work the first time around. I think that reason that this bug surfaced now instead of months ago, when I checked in the offending code, was that the old fastload dependency code was saving us.
Attachment #471582 -
Flags: review?(benjamin)
Comment 6•14 years ago
|
||
Comment on attachment 471582 [details] [diff] [review] fix Heh!
Attachment #471582 -
Flags: review?(benjamin) → review+
Assignee | ||
Updated•14 years ago
|
Attachment #471582 -
Flags: approval2.0?
Updated•14 years ago
|
blocking2.0: --- → final+
Updated•14 years ago
|
Attachment #471582 -
Flags: approval2.0?
Assignee | ||
Updated•14 years ago
|
Keywords: checkin-needed
Comment 7•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/499c24ccb868
You need to log in
before you can comment on or make changes to this bug.
Description
•