Closed Bug 379002 Opened 15 years ago Closed 14 years ago confused by output dir at different level of source dir


(Toolkit Graveyard :: Build Config, defect)

Not set


(Not tracked)



(Reporter: peterv, Assigned: Pike)



(1 file)

Here's the error I get in mozilla/browser/locales:

Traceback (most recent call last):
  File "../../../source/mozilla/config/", line 469, in ?
  File "../../../source/mozilla/config/", line 454, in main
    pp.handleCommandLine(None, True)
  File "../../../source/mozilla/config/", line 200, in handleCommandLine
  File "../../../source/mozilla/config/", line 439, in do_include
  File "../../../source/mozilla/config/", line 219, in handleLine
  File "../../../source/mozilla/config/", line 448, in do_includesubst
  File "../../../source/mozilla/config/", 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/', 102, 'FILE_NOT_FOUND', '/Users/peterv/source/mozilla/output/368774/source/mozilla/browser/locales/../../../source/mozilla/browser/locales/en-US/')

../../../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:


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

The question I'd have for Benjamin is, should the core_abspath definition go into the makefile or should we put that in like nspr does?
Let's not put it in 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 only.

I'll provide a patch for calendar/locales/, too, if this sticks.

I tested this against en-US and pl (which has an entry in 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.
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.