Bug 939571 is an example of where we need this.

This is necessary for places where we have a UNIFIED_SOURCES variable pointing to a file such as Foo.cpp, and we also have a LOCAL_INCLUDES variable pointing to another directory containing another version of Foo.cpp. Without this patch, we end up #including the second file instead of the first one.

Comment on attachment 8333536 [details] [diff] [review] Create unified files based on the absolute path of the original source files I think I'd rather see LOCAL_INCLUDES go after -I$(srcdir) and -I. in config/config.mk. Could you try that instead?

The dom/base and dom/worker hunks are needed because that code was basically relying on the existing order of LOCAL_INCLUDES to pick the Navigator.h in dom/base.

Comment on attachment 8334473 [details] [diff] [review] #include LOCAL_INCLUDES after the source dir and current dir includes; r=glandium Review of attachment 8334473 [details] [diff] [review]: ----------------------------------------------------------------- This seems fine. As long as LOCAL_INCLUDES are early enough to intercept most includes (I think some people rely on this to inject wrappers), I think we'll be fine. I can't imagine someone wanting to override files defined in the current directory. I don't think you need glandium's additional review here. But I'll defer to you.

Comment on attachment 8334473 [details] [diff] [review] #include LOCAL_INCLUDES after the source dir and current dir includes; r=glandium Thanks for the review!