Closed Bug 37484 Opened 24 years ago Closed 24 years ago

Build date causes layout relink on every build

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: dead, Assigned: clayton)

References

Details

We currently generate the build date on every pass through the tree, which
causes libraptorhtml.so to be relinked every time.  This is pretty annoying,
because this library takes a long time to link (I think more so on unix than
windows). Would it be possible to move this to either:

a) javascript, so nothing would have to be recompiled, or
b) some other library that doesn't take so long to link

If neither of these are possible, we should at least have a flag to turn off the
build date generation, because for most peoples' debugging purposes it's
unnecessary.
Changing component
Assignee: troy → cls
Component: Layout → Build Config
QA Contact: petersen → granrose
I thought the build date was only generated for optimized builds.

cc leaf.
Bryner, are you doing optimized builds? I remember waqar asking me questions
about where buildid's were generated and kept. Waqar... do you have to relink
layout to pickup the buildid?

Yes, that is true. The gbdate.pl generates a header file in the layout/build 
directory. gmake checks the dependency and rebuilds the library. It is possible 
to move the date generation to the autoconf, but that is only for unix, but we 
have to leave the perl script for windows. I am not familiar enough with autoconf 
to hack it.

cls@seawood.org I can help you with this if you like.

Autoconf's not going to help this problem if you want to keep the same behavior,
generating a new build id for each 'make'.  The problem with using a header to
do this is that regardless of where the header is generated, it will cause
modules that use it to be relinked on each toplevel 'make'.  If this information
were stored in a component, say necko_about, then we'd only have to rebuild one
relatively small library everytime we build the tree and everyone could use that
information with a small runtime penalty.

The other choice is to just to remove the FORCE so that the header is only
generated once.

Why does layout need the build id?


The reason layout needs a builds date is because of embeding. The user agent 
string need to have Gecko/<buildsdate>.

What I was saying about autoconf is that it would only need to be generated when 
we run configure, if we dont run configure then we dont generate the header file.

Ok, but that's a different behavior than what we currently have.  If the changed
behavior is ok with the gecko group, then I'll just remove the FORCE from the
gbdate.pl rule so that the header is only generated once.
Status: NEW → ASSIGNED
Ok, the FORCE has been removed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Re-opening and moving the platform from Linux to Win32.
Please find a better solution on Win32 as well. With MathML,
numerous compilations are needed to carefully adjust the placements...
and this is making compilations very slow on non luxurious systems.
Shouldn't the build-date be the date when the code is 
pulled from the mozilla.org's tree? (a constant date meaning
the same point of reference for all those who pulled the tree at
that moment)?
Status: RESOLVED → REOPENED
OS: Linux → Windows 95
Resolution: FIXED → ---
Except that you can selectively update separate portions of the tree and I don't
know of any cvs triggers that could do what you suggest.

Are you sure that the perl script is actually the cause of rebuilds on win32?  I
checked the makefile.win and it does not have the FORCE that the unix
Makefile.in did.


I guess waqar would know the answer?
With the current setup, gbdate.h is re-installed at each nmake, leading to the
re-complilation of nsLayoutModule.cpp.  So when doing a little modification
in the mathml directory and linking against the gecko libs, the extra time
quickly add up when doing several compilations on slow systems with limited
memory. I observe a significant difference when I disable the re-installation
of gbdate.h.
rbs, can you submit a patch to makefile.win so we can review?
Unfortunately, the change I made in my local tree defeats the purpose of
gbdate.h since it removes gbdate.h from EXPORTS in layout\build\makefile.win
Target Milestone: --- → M18
Seems a fix went it? I just pulled a fresh tree and I don't see a re-compiltaion
of nsLayoutModule.cpp anymore (Win32).
Marking fixed based upon rbs' previous comments.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
marking verified.
Status: RESOLVED → VERIFIED
*** Bug 45564 has been marked as a duplicate of this bug. ***
From bug 45564,

------- Comments From Ben Bucksch  2000-07-15 08:54 -------


You have to do a clobber (build new tree?) in order to to change the Geck
version in the UA-string. This gives wrong results.

Implementation:
Delete layout/build/gbdate.h during depend builds.



------- Additional Comments From Christopher Seawood 2000-07-18 21:55 -------

Ok, this brings up a whole can of worms I'm not going to deal with while on
vacation. (Namely always rebuilding layout.) Reassigning to leaf.




Don't ask me why, but just deleting this file and a make in layout costs just ~1
min for me, 20s of it relinking libgklayout.so. And this machine is not
high-end.

Maybe just delete it for a top-level make?
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Or delete gbdate.h during |make -f client.mk checkout|. This
- is nearer to the purpose of the string (as mentioned by rbs),
- solves my problem (having a wrong buildid nearly all the time, so I need to
look at teh cvs log to see what version I am running), but
- does not cause rebuilds during hacking.
Sigh. One week of vacation and I can no longer copy-n-paste. :-/

Ben didn't give the specs of his machine but on a PIII-600 with 192M ram,
removing layout/build/gbdate.h and doing a make in layout/ takes 2m 10s & over
110 megs of ram.  Since not everyone has a cpu and/or ram to link libgklayout.so
in a relatively decent amount of time, I don't think we should revert to the old
behavior of relinking on every pass.  

Would there be a problem just setting the gecko build id to all zeros unless
MOZILLA_OFFICIAL was set (ala nsBuildId.h)?  This means for a majority of the
developers, there will be no libgklayout.so relinking penalty and if someone
wants to have these buildId's set correctly, then they can just set
MOZILLA_OFFICIAL when running make.

> Ben didn't give the specs of his machine

Linux 2.2.16, RH, Celeron 300A, 128MB RAM, 70 MB swap.

> I don't think we should revert to the old behavior of relinking on every pass.

Agreed.

The buildid is also useful for QA (with custom builds), e.g. "I don't see that
problem with my build from xxx". What is the problem with the solution I just
proposed?
BTW: I'm building with
ac_add_options --disable-tests
ac_add_options --enable-optimize
ac_add_options --disable-debug
ac_add_options --enable-strip-libs
That's propably the reason for the difference.
There are 2 problems (nits really) with the |make -f client.mk checkout|
solution.  1) You are still causing a relinking of libgklayout.so when no code
has changed. It just happens less frequently. 2) You are adding a hack to
client.mk to fix a problem that really doesn't concern it.  

Skipping the issue of using buildIds not being the equivalent of pullIds, you
would still be able to get the buildId for QA of custom builds by doing 
|make -C layout/build MOZILLA_OFFICIAL=1|

|MOZILLA_OFFICIAL| copies rather than symlinks files in dist, right?
Nope, you're thinking of |NSDISTMODE=copy| .
Punting to the layout group.  I can't see a way to update the Gecko/date string
on each cvs checkout without a) causing a relink of liblayout every time or b)
making a fundamental change to layout.
Assignee: cls → clayton
Status: REOPENED → NEW
Component: Build Config → Layout
OS: Windows 95 → Linux
QA Contact: granrose → petersen
Closing as WONTFIX. we want the buildID but we don't want to pay the price of
keeping it up to date (this is what I understand from reading the comments
anyway). I don't think we will be undertaking a fundamental change in layout any
time soon... As usual, please post your objections and reopend etc. as necessary.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WONTFIX
verified wontfix per marc's comments.
Status: RESOLVED → VERIFIED
*** Bug 55781 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.