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:
$(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.
cd $(srcdir); set file /enter=prcpucfg.h $(MDCPUCFG_H)
$(INSTALL) -m 444 $(srcdir)/prcpucfg.h $(dist_includedir)
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
Created attachment 124726 [details] [diff] [review]
This appears to fix the problem for OpenVMS.
Comment on attachment 124726 [details] [diff] [review]
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
> 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
Symlinks are coming to OpenVMS, and once we have them, then hopefully I'll be
able to remove this VMS-specific change.
Created attachment 125039 [details] [diff] [review]
wtc's suggests this patch
Colin, how about this patch, or something along this 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
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.
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.