Last Comment Bug 648053 - Always use absolute paths when specifying the source file to the compiler
: Always use absolute paths when specifying the source file to the compiler
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: unspecified
: All All
: -- normal (vote)
: mozilla6
Assigned To: Jonathan Watt [:jwatt] (catching up after vacation)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-06 11:29 PDT by Jonathan Watt [:jwatt] (catching up after vacation)
Modified: 2011-04-27 06:29 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
[pushed] patch 1 (706 bytes, patch)
2011-04-11 18:13 PDT, Jonathan Watt [:jwatt] (catching up after vacation)
ted: review+
Details | Diff | Splinter Review

Description Jonathan Watt [:jwatt] (catching up after vacation) 2011-04-06 11:29:48 PDT
It would be great if we always used an absolute path when specifying a source file to the compiler.

I've been trying to get Eclipse to work better with Mozilla recently. One of the problems is that it's code intelligence stuff - potentially a great productivity booster - doesn't work very well. For it to work Eclipse basically needs to know which files are built, and what defines and include paths they're built with. The preferred way for it to figure this out is by analyzing build log output to see which arguments are passed to the compiler for each compiled source file. One of the problems with Mozilla's build logs is that many source files are specified to the compiler using just their basename, or just a relative path, and there are a bunch of files being compiled with the same basename which confuses Eclipse. If we always specified the source files using absolute paths then Eclipse would have a fighting chance of figuring out what's going on (since it knows the root source directory).
Comment 1 Jonathan Watt [:jwatt] (catching up after vacation) 2011-04-11 18:13:06 PDT
Created attachment 525251 [details] [diff] [review]
[pushed] patch 1

This patch fixes everything (on Mac debug at least) except stuff in the './security' and './dbm' directories, and the following three files:

  toolkit/crashreporter/google-breakpad/src/common/md5.c
  nsprpub/lib/tests/arena.c
  objdir/dist/private/nss/templates.c

Thanks to khuey for pointing out what to change.
Comment 2 Ted Mielczarek [:ted.mielczarek] 2011-04-15 10:59:17 PDT
Comment on attachment 525251 [details] [diff] [review]
[pushed] patch 1

I think this should be okay, if you've tested it on OS X. I'm not really sure why we only had this on Windows before, perhaps to work around some Visual C++ limitation?
Comment 3 Jonathan Watt [:jwatt] (catching up after vacation) 2011-04-19 10:24:03 PDT
I'm on OS X, and a debug build worked fine for me. However, on pushing to Try I'm getting the following weird failure on various platforms:

TEST-UNEXPECTED-FAIL | check-sync-dirs.py | build file copies are not in sync
TEST-INFO | check-sync-dirs.py | file(s) found in:               /builds/slave/try-lnx/build/js/src/config
TEST-INFO | check-sync-dirs.py | differ from their originals in: /builds/slave/try-lnx/build/config
TEST-INFO | check-sync-dirs.py | differing file:                 ./rules.mk

http://tbpl.mozilla.org/?tree=MozillaTry&rev=7370688e6023
Comment 4 Mike Hommey [:glandium] 2011-04-19 10:28:04 PDT
(In reply to comment #3)
> I'm on OS X, and a debug build worked fine for me. However, on pushing to Try
> I'm getting the following weird failure on various platforms:
> 
> TEST-UNEXPECTED-FAIL | check-sync-dirs.py | build file copies are not in sync
> TEST-INFO | check-sync-dirs.py | file(s) found in:              
> /builds/slave/try-lnx/build/js/src/config
> TEST-INFO | check-sync-dirs.py | differ from their originals in:
> /builds/slave/try-lnx/build/config
> TEST-INFO | check-sync-dirs.py | differing file:                 ./rules.mk
> 
> http://tbpl.mozilla.org/?tree=MozillaTry&rev=7370688e6023

You need to apply the patch to js/src/config/rules.mk as well.
Comment 5 Jonathan Watt [:jwatt] (catching up after vacation) 2011-04-20 02:27:16 PDT
Oh, it's as simple as that? Thanks. (I'm a bit curious why we require to have two copies of files that have to be kept exactly in sync.)

I pushed to Try with that change twice, but I'm getting a weird orange on the OS X 64 Opt "B" that doesn't seem to be happening to other Try pushes without this change:

http://tbpl.mozilla.org/?tree=MozillaTry&rev=a42ba24980e9

MAR=/builds/slave/try-osx64/build/obj-firefox/i386/dist/host/bin/mar \
	  /builds/slave/try-osx64/build/tools/update-packaging/make_full_update.sh \
	  "../../dist/update/mac/en-US//nightly-6.0a1.complete.mar" \
	  "../../dist/universal/firefox/Nightly.app"
/builds/slave/try-osx64/build/obj-firefox/i386/dist/universal/firefox/Nightly.app /builds/slave/try-osx64/build/obj-firefox/i386/tools/update-packaging
precomplete file is missing!
make: *** [complete-patch] Error 1

Any ideas if that's being caused by me, and if so why?
Comment 6 Ted Mielczarek [:ted.mielczarek] 2011-04-20 05:09:56 PDT
I think that's just fallout from bug 386760, it was fixed in http://hg.mozilla.org/mozilla-central/rev/b1592bb02a93 (do you have that revision in your tree?)
Comment 7 Jonathan Watt [:jwatt] (catching up after vacation) 2011-04-20 05:21:13 PDT
Thanks, glandium pinged me on IRC and suggested I might be out of date too, so I updated to tip and pushed a new try which I'm waiting on:

http://tbpl.mozilla.org/?tree=MozillaTry&rev=c2cb4eba8efa

He also pointed me to that bug as the possible problem, but by then I'd already updated and pushed to Try so I'm not sure if I had that bug's fix in my previous Try runs.
Comment 8 Jonathan Watt [:jwatt] (catching up after vacation) 2011-04-20 10:20:23 PDT
Pushed http://hg.mozilla.org/mozilla-central/rev/60306d26eed4
Comment 9 Jonathan Watt [:jwatt] (catching up after vacation) 2011-04-27 06:29:46 PDT
I was actually leaving this open for the stuff mentioned in comment 1.

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