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)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jag+mozilla, Assigned: jag+mozilla)

References

()

Details

Attachments

(2 files)

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 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+
jag: where do you do "make install" during Mozilla build?
Doesn't Mozilla's build system only use the "export libs" targets
now?
wtc: it seems to be driven from the libs_tier_nspr make target.
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.
This is causing me pain, for some reason extensions/universalchardet winds up rebuilding due to this, which is screwing my profile-guided optimization builds.
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.
Could you simply use the -p argument to "cp", which would keep the timestamp?
Since everything else uses nsinstall I think I'll stick to that.
Not obsoleting the previous patch yet, I'll leave that one up to you, wtc.
Attachment #304172 - Flags: review?(wtc)
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+
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).
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
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
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.
I updated Mozilla trunk to use NSPR_4_7_1_BETA1
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.