Closed Bug 379002 Opened 15 years ago Closed 14 years ago

Preprocessor.py confused by output dir at different level of source dir

Categories

(Toolkit Graveyard :: Build Config, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: peterv, Assigned: Pike)

Details

Attachments

(1 file)

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)
Attachment #263355 - Flags: review?(benjamin) → review+
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: 14 years ago
Resolution: --- → FIXED
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.