gecko build date only occasionally updated

RESOLVED FIXED in mozilla1.7beta

Status

()

Core
Layout
RESOLVED FIXED
17 years ago
14 years ago

People

(Reporter: dmose, Unassigned)

Tracking

Trunk
mozilla1.7beta
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 5 obsolete attachments)

(Reporter)

Description

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

Comment 1

17 years ago
Created attachment 36588 [details] [diff] [review]
patch to tweak the *nix makefiles to keep gecko build date uptodate

Comment 2

17 years ago
why is this assigned to me?  is it because i'm the last person to touch gbdate.pl?
(Reporter)

Comment 3

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

Comment 4

17 years ago
Ugh.  There is at least one build-order issue with my patch; taking until I can
sort it out.

Updated

17 years ago
OS: Linux → All

Comment 5

17 years ago
See bug 81344.

Comment 6

17 years ago
->dmose
Assignee: darin → dmose
(Reporter)

Updated

17 years ago
Target Milestone: --- → Future
(Reporter)

Updated

16 years ago
Attachment #36588 - Flags: needs-work+

Comment 7

16 years ago
This is still a problem, and it affects the build-id that is displayed in the 
about: page. This really should get fixed.

Comment 8

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

Comment 10

15 years ago
-> per cls.
Assignee: dmose → other
Component: Networking: HTTP → Layout
QA Contact: benc → ian

Comment 11

15 years ago
Created attachment 128801 [details] [diff] [review]
update gbdate.h when SHARED_LIBRARY_LIBS change

Comment 12

15 years ago
Created attachment 128830 [details] [diff] [review]
add explicit dependency upon gbdate.h
Attachment #128801 - Attachment is obsolete: true

Comment 13

15 years ago
Created attachment 129057 [details] [diff] [review]
third time's a charm
Attachment #36588 - Attachment is obsolete: true
Attachment #128830 - Attachment is obsolete: true

Updated

14 years ago
Attachment #129057 - Flags: review?(bryner)
Attachment #129057 - Flags: review?(bryner) → review+

Comment 14

14 years ago
The patch was checked in a couple of months ago by timeless.

Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.7beta

Comment 15

14 years ago
*** Bug 238478 has been marked as a duplicate of this bug. ***

Comment 16

14 years ago
Reopening.  The patch causes a regression when rebuilding just the layout module
as pointed out in bug 238478.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 17

14 years ago
Created attachment 145606 [details] [diff] [review]
the hard way

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

Updated

14 years ago
Attachment #145606 - Flags: review?(bsmedberg)

Comment 18

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

Updated

14 years ago
Attachment #145606 - Flags: approval1.7?

Comment 19

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

Comment 20

14 years ago
The patch has been checked in with the gbdate.tstamp change.
Status: REOPENED → RESOLVED
Last Resolved: 14 years ago14 years ago
Resolution: --- → FIXED

Comment 21

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

Comment 22

14 years ago
Created attachment 145712 [details] [diff] [review]
use ksh on solaris

Use ksh on solaris.

We should just require ksh universally for solaris as we do for OSF/1 in NSPR.

Comment 23

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

Comment 24

14 years ago
Created attachment 145761 [details] [diff] [review]
Use ksh93 on Solaris
Attachment #145712 - Attachment is obsolete: true

Comment 25

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

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

Comment 27

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

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

Comment 29

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

Comment 30

14 years ago
For Tru64 Unix also, observed that the following error occurs in the directory
mozilla/layout/build:
/bin/sh: test: unknown operator -nt
 

Comment 31

14 years ago
Created attachment 149321 [details] [diff] [review]
Fix for Tru64 Unix (OSF1)

Proposing the fix of using ksh in OSF1 to get the build right.

Comment 32

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