Note: There are a few cases of duplicates in user autocompletion which are being worked on.

prcpucfg.h always updated

VERIFIED FIXED in 4.4

Status

NSPR
NSPR
--
major
VERIFIED FIXED
14 years ago
14 years ago

People

(Reporter: Colin Blake, Assigned: Wan-Teh Chang)

Tracking

other
DEC
OpenVMS

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

14 years ago
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.
(Reporter)

Comment 1

14 years ago
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.
(Reporter)

Comment 2

14 years ago
Created attachment 124726 [details] [diff] [review]
Patch

This appears to fix the problem for OpenVMS.
(Assignee)

Comment 3

14 years ago
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.
(Reporter)

Comment 4

14 years ago
> 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.
(Reporter)

Updated

14 years ago
Attachment #124726 - Flags: review?(wtc)
(Assignee)

Comment 5

14 years ago
Created attachment 125039 [details] [diff] [review]
wtc's suggests this patch

Colin, how about this patch, or something along this line?
(Reporter)

Comment 6

14 years ago
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.
(Assignee)

Comment 7

14 years ago
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.
(Assignee)

Comment 8

14 years ago
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)
(Reporter)

Comment 9

14 years ago
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!
(Assignee)

Comment 10

14 years ago
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
Last Resolved: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.4
(Assignee)

Updated

14 years ago
Attachment #124726 - Attachment is obsolete: true
Attachment #124726 - Flags: review?(wtc)
(Reporter)

Comment 11

14 years ago
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.
(Assignee)

Comment 12

14 years ago
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.