416571 - cp of prcpucfg.h in dist/sdk/include causes rebuilding of tools

Status: RESOLVED FIXED

Description

[jag (Peter Annema)]

Created attachment 302315 [details] [diff] [review]
Avoid updating the mtime on dist/sdk/include/prcpucfg.h

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.

Comment 1

[Wan-Teh Chang]

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.

Comment 2

[Wan-Teh Chang]

jag: where do you do "make install" during Mozilla build?
Doesn't Mozilla's build system only use the "export libs" targets
now?

Comment 3

[jag (Peter Annema)]

wtc: it seems to be driven from the libs_tier_nspr make target.

Comment 4

[jag (Peter Annema)]

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

[Ted Mielczarek [:ted.mielczarek]]

This is causing me pain, for some reason extensions/universalchardet winds up rebuilding due to this, which is screwing my profile-guided optimization builds.

Comment 6

[jag (Peter Annema)]

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

[Kai Engert (:kaie:)]

Could you simply use the -p argument to "cp", which would keep the timestamp?

Comment 8

[jag (Peter Annema)]

Since everything else uses nsinstall I think I'll stick to that.

Comment 9

[jag (Peter Annema)]

Created attachment 304172 [details] [diff] [review]
As previous, but also drop OpenVMS bits

Not obsoleting the previous patch yet, I'll leave that one up to you, wtc.

Comment 10

[Wan-Teh Chang]

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?

Comment 11

[Ted Mielczarek [:ted.mielczarek]]

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

[Mike Schroepfer]

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? 

Comment 13

[Wan-Teh Chang]

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.

Comment 14

[jag (Peter Annema)]

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

[Kai Engert (:kaie:)]

I updated Mozilla trunk to use NSPR_4_7_1_BETA1