Closed Bug 83405 Opened 23 years ago Closed 20 years ago

gecko build date only occasionally updated

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.7beta

People

(Reporter: dmosedale, Unassigned)

References

Details

Attachments

(3 files, 5 obsolete files)

My development builds have been locked out of bugzilla for weeks because the
last time I pulled an update to gbdate.pl, it was on May 14th, the day of the
form corruption bug.  (I just got around to tracking down that that was the
actual problem now).  Rather than do the hacky thing and hardcode my user-agent,
I tweaked the build system to update gbdate.h whenever the output of gbdate.pl
changes. 

I'll be attaching a patch.  It does assume that "cmp" and "mv" exist and have
certain semantics, but these are both POSIXy things, so I'm hoping this won't
cause any problems.
why is this assigned to me?  is it because i'm the last person to touch gbdate.pl?
Yeah, and because the real tangible effect is in the HTTP user-agent, and I
figured you'd be the most likely to care about that.  However, feel free to give
it to whomever...
Ugh.  There is at least one build-order issue with my patch; taking until I can
sort it out.
OS: Linux → All
See bug 81344.
->dmose
Assignee: darin → dmose
Target Milestone: --- → Future
Attachment #36588 - Flags: needs-work+
This is still a problem, and it affects the build-id that is displayed in the 
about: page. This really should get fixed.
Isn't this a build bug?
This is actually a dupe of bug 37484.  It's questionably a build bug.  The build
system generates the build id but the modules are responsible for how they use
it.    Unnecessarily relinking layout just to get an updated build id is of
questionable use.  However, if the library is being relinked anyway, then the
build id should probably be updated too.  Or just move the build date into a
separate, smaller auxillary library or data file.
-> per cls.
Assignee: dmose → other
Component: Networking: HTTP → Layout
QA Contact: benc → ian
Attachment #128801 - Attachment is obsolete: true
Attached patch third time's a charm (obsolete) — Splinter Review
Attachment #36588 - Attachment is obsolete: true
Attachment #128830 - Attachment is obsolete: true
Attachment #129057 - Flags: review?(bryner)
Attachment #129057 - Flags: review?(bryner) → review+
The patch was checked in a couple of months ago by timeless.

Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.7beta
*** Bug 238478 has been marked as a duplicate of this bug. ***
Reopening.  The patch causes a regression when rebuilding just the layout module
as pointed out in bug 238478.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch the hard waySplinter Review
This patch manually compares the timestamps of SHARED_LIBRARY_LIBS against a
timestamp file which is a dependency of gbdate.h.  Just smile and nod.
Attachment #129057 - Attachment is obsolete: true
Attachment #145606 - Flags: review?(bsmedberg)
Comment on attachment 145606 [details] [diff] [review]
the hard way

smile and nod... I would prefer if this file did not have a dot-filename,
gbdate.tstamp?
Attachment #145606 - Flags: review?(bsmedberg) → review+
Attachment #145606 - Flags: approval1.7?
Comment on attachment 145606 [details] [diff] [review]
the hard way

a=asa (on behalf of drivers) for checkin to 1.7
Attachment #145606 - Flags: approval1.7? → approval1.7+
The patch has been checked in with the gbdate.tstamp change.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
Regression on Solaris:

gmake[4]: Entering directory `/files/dsk1/lsw/anlan/m7/mozilla/layout/build'
/files/dsk1/lsw/anlan/m7/mozilla/config/nsinstall -R -m 644 nsLayoutCID.h
../../dist/include/layout
/usr/local/bin/perl -I../../config ../../config/build-list.pl
../../dist/include/layout/.headerlist nsLayoutCID.h
/bin/sh: test: unknown operator -nt
gmake[4]: *** [gbdate.tstamp] Error 1

From 'man -s1 test':
        file1-nt file2
                True, if file1 exists and is  newer  than  file2.
                (Not available in sh.)
Attached patch use ksh on solaris (obsolete) — Splinter Review
Use ksh on solaris.

We should just require ksh universally for solaris as we do for OSF/1 in NSPR.
Chris Seawood wrote:
> Use ksh on solaris.
> We should just require ksh universally for solaris as we do for OSF/1 in NSPR.

I would prefer to use /usr/dt/bin/dtksh on Solaris since this is a ksh93,
/usr/bin/ksh is ksh88 with all it's poor sideeffects.
Attachment #145712 - Attachment is obsolete: true
Comment on attachment 145761 [details] [diff] [review]
Use ksh93 on Solaris

The patch switchs shells globally - I do not like any partial switches which
may lead to further confusion. None or all. :)
(and it will protect Mozilla from further issues, ksh93 is much more compatible
to bash2 than Sun's hacked ksh88).
Attachment #145761 - Flags: review?(cls)
Comment on attachment 145761 [details] [diff] [review]
Use ksh93 on Solaris

My only concern with that change is that /usr/dt used  to be an optional
install (Motif/CDE stuff iirc).  If we're worried about bash2 compatibility, we
should just require bash2.  ksh88 should be good enough.
Chris Seawood wrote:
> My only concern with that change is that /usr/dt used  to be an optional
> install (Motif/CDE stuff iirc).

1. The Sun Gnome desktop depends on stuff in /usr/dt/ so it is NOT an optional
installation.
2. The Mozilla build itself depends on files in /usr/dt (they're also
soft-linked to /usr/lib and /usr/include but the real files reside in /usr/dt)
3. The Solaris patch checker uses /usr/dt/bin/dtksh as runtime requirement with
r= from Sun staff.
Comment on attachment 145761 [details] [diff] [review]
Use ksh93 on Solaris

Since what you said doesn't apply to older versions of solaris and we have no
requirements for ksh93, I'm giving it a minus.
Attachment #145761 - Flags: review?(cls) → review-
(In reply to comment #28)
> (From update of attachment 145761 [details] [diff] [review])
> Since what you said doesn't apply to older versions of solaris

I doubt Mozilla support Solaris 2.4 or 2.5.1, right ?
AFAIK Mozilla only builds and runs on Solaris >= 2.6 and even support for 2.6 is
fading off.

> and we have no
> requirements for ksh93

If more and more bash'ismn are used in the build system then ksh93 may become a
requirement on Solaris. bash is no option since this is an unbundeled product
and not supported by Sun.
For Tru64 Unix also, observed that the following error occurs in the directory
mozilla/layout/build:
/bin/sh: test: unknown operator -nt
 
Proposing the fix of using ksh in OSF1 to get the build right.
Comment on attachment 149321 [details] [diff] [review]
Fix for Tru64 Unix (OSF1)

Per http://www.mozilla.org/build/unix-details.html , OSF1 should be using ksh
anyway.  You should open a separate bug if you want that hardcoded.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: