648053 - Always use absolute paths when specifying the source file to the compiler

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Jonathan Watt [:jwatt]]

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]]

Attachment: [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

[(not currently active) Ted Mielczarek]

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]]

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]]

(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]]

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

[(not currently active) Ted Mielczarek]

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]]

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]]

Pushed http://hg.mozilla.org/mozilla-central/rev/60306d26eed4

Comment 9

[Jonathan Watt [:jwatt]]

I was actually leaving this open for the stuff mentioned in comment 1.