Closed
Bug 416571
Opened 16 years ago
Closed 16 years ago
cp of prcpucfg.h in dist/sdk/include causes rebuilding of tools
Categories
(NSPR :: NSPR, defect, P1)
NSPR
NSPR
Tracking
(Not tracked)
RESOLVED
FIXED
4.7.1
People
(Reporter: jag+mozilla, Assigned: jag+mozilla)
References
()
Details
Attachments
(2 files)
1.46 KB,
patch
|
wtc
:
review+
|
Details | Diff | Splinter Review |
1.64 KB,
patch
|
wtc
:
review+
|
Details | Diff | Splinter Review |
See the bug URL. Because we do cp there instead of what is done for export the prcpucfg.h timestamp in dist/sdk/include keeps getting updated for every make install, causing us to do some unnecessary rebuilds during the make tools phase. I have a patch that makes us do what make export does.
Attachment #302315 -
Flags: review?(wtc)
Comment 1•16 years ago
|
||
Comment on attachment 302315 [details] [diff] [review] Avoid updating the mtime on dist/sdk/include/prcpucfg.h r=wtc. This looks correct. We don't need the OpenVMS code because I don't think it's supported any more.
Attachment #302315 -
Flags: review?(wtc) → review+
Comment 2•16 years ago
|
||
jag: where do you do "make install" during Mozilla build? Doesn't Mozilla's build system only use the "export libs" targets now?
Assignee | ||
Comment 3•16 years ago
|
||
wtc: it seems to be driven from the libs_tier_nspr make target.
Assignee | ||
Comment 4•16 years ago
|
||
wtc: btw, if you want I can remove the OpenVMS stuff here, but it'd probably be cleaner to file a new bug on cleaning up OpenVMS related things in NSPR in general if it's no longer supported.
Comment 5•16 years ago
|
||
This is causing me pain, for some reason extensions/universalchardet winds up rebuilding due to this, which is screwing my profile-guided optimization builds.
Assignee | ||
Comment 6•16 years ago
|
||
libs_tier_nspr iterates over tier_nspr_dirs and calls make -C $dir libs for each. tier_nspr_dirs contains config/nspr, and make -C config/nspr libs runs make -C nsprpub install And that's how we end up calling the code I'm fixing.
Comment 7•16 years ago
|
||
Could you simply use the -p argument to "cp", which would keep the timestamp?
Assignee | ||
Comment 8•16 years ago
|
||
Since everything else uses nsinstall I think I'll stick to that.
Assignee | ||
Comment 9•16 years ago
|
||
Not obsoleting the previous patch yet, I'll leave that one up to you, wtc.
Attachment #304172 -
Flags: review?(wtc)
Comment 10•16 years ago
|
||
Comment on attachment 304172 [details] [diff] [review] As previous, but also drop OpenVMS bits jag: your old patch is fine. It's just that I haven't got around to checking it in. Sorry :-) Ted: does jag's patch (either one) fix the problem for you?
Attachment #304172 -
Flags: review?(wtc) → review+
Comment 11•16 years ago
|
||
Yes, I meant to comment on that. I'm using the second one, but it works just fine. If you could get that checked in, that would be great, as we'd like to start doing PGO on our Windows builds (bug 361343).
Comment 12•16 years ago
|
||
Wan-Teh thanks for the quick help on this. Can we get this landed and the NSPR tag updated so we can get PGO into nighties?
Flags: blocking1.9+
Priority: -- → P1
Comment 13•16 years ago
|
||
The root cause of this bug is that mozilla/config/nspr/Makefile.in incorrectly maps its 'libs' makefile target to NSPR's 'install' makefile target. It should be mapped to NSPR's 'libs' or 'export' target. I don't know why it wasn't done that way. In any case, it is less work to change NSPR than to do the "right thing" and fix mozilla/config/nspr/Makefile.in. jag's patch is a good idea anyway because we install the other headers using $(NSINSTALL) -t. I checked in the first patch on the NSPR trunk for NSPR 4.7.1. Checking in Makefile.in; /cvsroot/mozilla/nsprpub/pr/include/md/Makefile.in,v <-- Makefile.in new revision: 1.22; previous revision: 1.21 done I will update Mozilla's NSPR CVS tag tomorrow morning.
Status: NEW → ASSIGNED
Target Milestone: --- → 4.7.1
Assignee | ||
Comment 14•16 years ago
|
||
Fixing config/nspr/Makefile.in's libs target seems pretty easy. I guess we just need to make sure all the right things still happen.
Comment 15•16 years ago
|
||
I updated Mozilla trunk to use NSPR_4_7_1_BETA1
Updated•16 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•