Last Comment Bug 207614 - prcpucfg.h always updated
: prcpucfg.h always updated
Status: VERIFIED FIXED
:
Product: NSPR
Classification: Components
Component: NSPR (show other bugs)
: other
: DEC OpenVMS
: -- major (vote)
: 4.4
Assigned To: Wan-Teh Chang
: Wan-Teh Chang
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-30 05:26 PDT by Colin Blake
Modified: 2003-06-10 14:13 PDT (History)
0 users
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Patch (987 bytes, patch)
2003-06-02 05:07 PDT, Colin Blake
no flags Details | Diff | Splinter Review
wtc's suggests this patch (936 bytes, patch)
2003-06-05 15:22 PDT, Wan-Teh Chang
no flags Details | Diff | Splinter Review

Description Colin Blake 2003-05-30 05:26:09 PDT
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.
Comment 1 Colin Blake 2003-05-30 06:04:19 PDT
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.
Comment 2 Colin Blake 2003-06-02 05:07:38 PDT
Created attachment 124726 [details] [diff] [review]
Patch

This appears to fix the problem for OpenVMS.
Comment 3 Wan-Teh Chang 2003-06-02 22:22:03 PDT
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.
Comment 4 Colin Blake 2003-06-03 04:54:00 PDT
> 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.
Comment 5 Wan-Teh Chang 2003-06-05 15:22:03 PDT
Created attachment 125039 [details] [diff] [review]
wtc's suggests this patch

Colin, how about this patch, or something along this line?
Comment 6 Colin Blake 2003-06-05 16:01:48 PDT
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.
Comment 7 Wan-Teh Chang 2003-06-05 17:36:38 PDT
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.
Comment 8 Wan-Teh Chang 2003-06-05 17:48:24 PDT
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)
Comment 9 Colin Blake 2003-06-06 04:42:48 PDT
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!
Comment 10 Wan-Teh Chang 2003-06-06 14:33:30 PDT
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.
Comment 11 Colin Blake 2003-06-10 03:13:03 PDT
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.
Comment 12 Wan-Teh Chang 2003-06-10 14:13:18 PDT
Marked the bug verified.  Colin, I can also live with
this bug not being in the MOZILLA_1_4_BRANCH.

Note You need to log in before you can comment on or make changes to this bug.