In switching to a new build environment, I've come across a problem when I perform an incremental build. Just about everything in NSPR and Mozilla gets rebuilt. I tracked it down to dist/include/nspr/prcpucfg.h always being "updated". Here's the problem: http://lxr.mozilla.org/nspr/source/nsprpub/pr/include/md/Makefile.in#48 export:: $(MDCPUCFG_H) $(INSTALL) -m 444 $(srcdir)/$(MDCPUCFG_H) $(dist_includedir) $(INSTALL) -m 444 $(CONFIGS) $(HEADERS) $(dist_includedir)/md mv -f $(dist_includedir)/$(MDCPUCFG_H) $(dist_includedir)/prcpucfg.h On OpenVMS, a file rename (the mv in the last line) causes the modification time on the real file to get updated (this is with "hardlinks"; we don't have true symbolic link support yet). And prcpucfg.h is included by just about everything. Possible solutions (thinking out loud): 1. Use nsinstall to name the file as well as locate it, then we can get rid of the mv command. Trouble is that nsinstall currently only takes a directory name for the destination. 2. Use "ln -s" instead of nsinstall/mv. Only GNV on OpenVMS doesn't have symbolic link support yet, hence "ln -s" doesn't work. 3. Just cp the file instead of nsinstall/mv. Doesn't help, since copying a file sets the new file's modification date to the current time. 4. Use BACKUP (a native VMS command) to copy the file. Advantage is that BACKUP will preserve the file's modification time. Disadvantage is that BACKUP doesn't understand UNIX style filespecs, only native VMS filespecs. 5. Check to see if we're in symlink mode (NSDISTMODE is null) and if we are, only perform the nsinstall/mv if dist/include/nspr/prcpucfg.h doesn't already exist.
Option 6. cd $(srcdir); set file /enter=prcpucfg.h $(MDCPUCFG_H) $(INSTALL) -m 444 $(srcdir)/prcpucfg.h $(dist_includedir) rm (srcdir)/prcpucfg.h I think this will work for OpenVMS. "set file /enter" creates a hardlink (the same as nsinstall does), but allows me to specify the name. So I create a temporary link to get the name changed, then link the temporary link to dist_includedir (which really links the original file), and then I delete the temporary link.
This appears to fix the problem for OpenVMS.
Comment on attachment 124726 [details] [diff] [review] Patch Colin, This patch has two problems. 1. It assumes that the source tree is writable. So it won't work if the source tree is read-only. 2. It will break if you are doing two builds off the same source tree at the same time because both will try to create and delete the temporary link $(srcdir)/prcpucfg.h. If these two problems are acceptable to you, I guess the patch is fine.
> 1. It assumes that the source tree is writable. So it won't work if the > source tree is read-only. OpenVMS doesn't have true symlinks yet, but what it does have are "hardlinks". And with hardlinks both the file and link(s) have to reside on the same device. So if NSDISTMODE is NULL I already know that the source tree is writable. > 2. It will break if you are doing two builds off the same source tree at > the same time because both will try to create and delete the temporary > link $(srcdir)/prcpucfg.h. True. But given how long builds take on OpenVMS, its unlikely that someone would be doing two builds in parallel. And they'd have to be building from the same source tree, and you'd have to hit this very small window. So I can live with this restriction. Symlinks are coming to OpenVMS, and once we have them, then hopefully I'll be able to remove this VMS-specific change.
Colin, how about this patch, or something along this line?
The line: dcl set file /enter=prcpucfg.h $(MDCPUCFG_H) needs to be: dcl set file /enter=prcpucfg.h $(srcdir)$(MDCPUCFG_H) but I like the idea and think it will work. Also I'd like the OpenVMS test to include NSDISTMODE so that we only do this if we are using "symlink mode", since "copy mode" is valid on OpenVMS too.
1. I want the hard link to be created exactly like this: dcl set file /enter=prcpucfg.h $(MDCPUCFG_H) in the $(dist_includedir) directory. Does this not work? 2. I intentionally do not test for NSDISTMODE. I want to use the same code in the "copy" mode, because $(INSTALL) in the "copy" mode preserves file times (see nsinstall.c) and 'mv' would updates the file's modified time.
I should point out that with my patch, OpenVMS will have an extra copy/link of $(MDCPUCFG_H) in $(dist_includedir). In other words, we will have: $(srcdir)/$(MDCPUCFG_H) original file $(dist_includedir)/$(MDCPUCFG_H) a link or copy $(dist_includedir)/prcpucfg.h a link to $(MDCPUCFG_H)
You're absolutely right, I'd overlooked the fact that $(MDCPUCFG_H) was installed NSINSTALL'd to $(dist_includedir). And creating the hard link, even if NSDISTMODE is copy, if also the correct thing to do. And much neater solution. Please check in this patch!
Patch checked into the NSPR tip (4.4) and NSPRPUB_PRE_4_2_CLIENT_BRANCH (Mozilla 1.5 alpha). Colin, could you verify the fix as follows? 1. If nsprpub/pr/include/md/_openvms.cfg is changed, the Mozilla files that include prcpucfg.h get recompiled. 2. If nsprpub/pr/include/md/_openvms.cfg is NOT changed, the Mozilla files that include prcpucfg.h do NOT get recompiled. Thanks.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.4
Everything is working correctly. FYI this change is NOT in the MOZILLA_1_4_BRANCH. I can live with that, just wanted to let you know in case you'd intended otherwise.
Marked the bug verified. Colin, I can also live with this bug not being in the MOZILLA_1_4_BRANCH.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.