Closed Bug 379002 Opened 17 years ago Closed 16 years ago
.py confused by output dir at different level of source dir
Here's the error I get in mozilla/browser/locales: Traceback (most recent call last): File "../../../source/mozilla/config/Preprocessor.py", line 469, in ? main() File "../../../source/mozilla/config/Preprocessor.py", line 454, in main pp.handleCommandLine(None, True) File "../../../source/mozilla/config/Preprocessor.py", line 200, in handleCommandLine self.do_include(f) File "../../../source/mozilla/config/Preprocessor.py", line 439, in do_include self.handleLine(l) File "../../../source/mozilla/config/Preprocessor.py", line 219, in handleLine cmd(args) File "../../../source/mozilla/config/Preprocessor.py", line 448, in do_includesubst self.do_include(args) File "../../../source/mozilla/config/Preprocessor.py", line 422, in do_include raise Preprocessor.Error(self, 'FILE_NOT_FOUND', str(args)) __main__.Error: ('/Users/peterv/source/mozilla/output/368774/source/mozilla/browser/locales/jar.mn', 102, 'FILE_NOT_FOUND', '/Users/peterv/source/mozilla/output/368774/source/mozilla/browser/locales/../../../source/mozilla/browser/locales/en-US/extra-jar.mn') ../../../source/mozilla/browser/locales is correct to go from the browser/locales objdir to the srcdir, but the preprocessor seems to use it relative to the browser/locales srcdir.
BTW, my setup is a bit complicated: ac_given_srcdir=../source/mozilla mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../output/DBG foo/mozilla is the source foo/output symlinks to ../output/foo output/foo/DBG is the output output/foo/source symlinks to ../../foo
OK, I have reproduced this scenario on my mac, peterv is on osx, too. Everything works fine as long as I make -f client.mk configure but if I ../source/mozilla/configure --enable-application=browser it busts, as topsrcdir ends up to be a relative path in the latter case. Benjamin, topsrcdir being relative sounds like major pain, I wonder if we should make configure not do that in the first place. Not sure how, though, we get that from dirname $0, no idea how to ensure that that's an absolute path.
Assignee: axel → l10n
topsrcdir should be a relative path on linux for various reasons. We need to support that usecase.
I still think that the #includesubst line should be relative to the jar.mn file and not the working directory, so the right solution would be to just feed an absolute path to -DLOCALE_SRCDIR. As make doesn't have $(abspath ) for all the versions we support, we need to hack around this, just like nsprpub does. PWD := $(shell pwd) core_abspath = $(if $(findstring :,$(1)),$(1),$(if $(filter /%,$(1)),$(1),$(PWD)/$(1))) does it, and then I can -DLOCALE_SRCDIR=$(call core_abspath,$(LOCALE_SRCDIR)) \ in browser/locales/Makefile.in. The question I'd have for Benjamin is, should the core_abspath definition go into the makefile or should we put that in rules.mk like nspr does?
Let's not put it in rules.mk for now, because that involves an extra invocation of $(shell) for each make in the tree, which isn't necessary.
Using a macro, as our make requirements don't provide $(abspath ), inside Makefile.in only. I'll provide a patch for calendar/locales/Makefile.in, too, if this sticks. I tested this against en-US and pl (which has an entry in extra-jars.mn) on mac, windows cygwin and windows msys.
Attachment #263355 - Flags: review?(benjamin)
Did this checkin cause the 'qm-winxp01' orange? make: *** [check] Error 1 http://tinderbox.mozilla.org/showlog.cgi?tree=Firefox&errorparser=unix&logfile=1178116058.18113.gz&buildtime=1178116058&buildname=WINNT%205.1%20qm-winxp01%20dep%20unit%20test&fulltext=1
qm-winxp01 is happy by now, must have been a solar storm or something.
This is apparently FIXED, marking as such.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.