Last Comment Bug 275790 - more ccache friendly NSPR_CFLAGS
: more ccache friendly NSPR_CFLAGS
Status: REOPENED
:
Product: Firefox
Classification: Client Software
Component: Build Config (show other bugs)
: unspecified
: x86 Linux
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-23 02:28 PST by basic
Modified: 2010-03-03 18:48 PST (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (2.46 KB, patch)
2004-12-23 02:34 PST, basic
no flags Details | Diff | Splinter Review
patch 2 (1.31 KB, patch)
2004-12-23 02:36 PST, basic
bryner: review+
roc: superreview+
Details | Diff | Splinter Review

Description basic 2004-12-23 02:28:56 PST
I'm filing this under firefox because I don't know where to file this. This
affects all mozilla apps. The NSPR_CFLAGS could be more friendly towards people
who build with ccache http://ccache.samba.org/ or other compiler cache systems.

Currently it uses an absolute path, causing many false negative as the absolute
path is different between builds.

For example, I build xulrunner under a 'object-xulrunner' object dir. After that
 I build firefox under 'object-firefox', since they are from the same source I 
expect that there should be some cache hits. However due to the absolute dir
difference in NSPR_CFLAGS it would never hit the cache. I've a patch (coming up)
that makes it slightly better that gets NSPR_CFLAGS to use relative dirs in most
places.

People using source based distros (with ccache enabled) like gentoo should
benefit from this too as they use different path to build each release. This
should increase the likelyhood of hitting the cache specially for minor releases.
Comment 1 basic 2004-12-23 02:34:28 PST
Created attachment 169428 [details] [diff] [review]
patch
Comment 2 basic 2004-12-23 02:36:38 PST
Created attachment 169430 [details] [diff] [review]
patch 2

oops attached the wrong file
Comment 3 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-01-20 13:58:31 PST
Argh, you beat me to it! I've just done exactly this.
Comment 4 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-01-20 15:34:34 PST
BTW check out my new blog post on this issue. It includes my solution to the
problem of hardlinking across multiple trees.

http://weblogs.mozillazine.org/roc/archives/2005/01/sharing_binarie.html
Comment 5 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-03-28 13:29:10 PST
checked in. Thanks!
Comment 6 Justin Lebar (not reading bugmail) 2010-03-02 22:41:16 PST
It appears that this may have regressed.

I'm building on Linux with the following mozconfig:

  . $topsrcdir/browser/config/mozconfig
  ac_add_options --enable-application=browser
  ac_add_options --enable-debug
  ac_add_options --srcdir=..
  mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@

Here's a call to gcc for a random file out of my builds:

c++ -o json.o -c [snip] -I/mnt/mozbuilds/code/ff-4/src/obj-i686-pc-linux-gnu/dist/include/nspr [snip] ../../../js/src/json.cpp

As I understand it, the path to nspr here should be relative, not absolute.
Comment 7 Justin Lebar (not reading bugmail) 2010-03-03 10:51:10 PST
It also appears that NSS is included with an absolute path.
Comment 8 Justin Lebar (not reading bugmail) 2010-03-03 18:48:45 PST
This may no longer be necessary, since ccache 3.0pre0 appears to cache builds between different trees as is.

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