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).
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 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?
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
(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.
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?
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?)
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.
I was actually leaving this open for the stuff mentioned in comment 1.