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

Status: RESOLVED FIXED

(Toolkit Graveyard :: Build Config, defect)

Description

[Peter Van der Beken [:peterv]]

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.

Comment 1

[Peter Van der Beken [:peterv]]

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

Comment 2

[Axel Hecht [:Pike]]

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.

Comment 3

[Benjamin Smedberg]

topsrcdir should be a relative path on linux for various reasons. We need to support that usecase.

Comment 4

[Axel Hecht [:Pike]]

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?

Comment 5

[Benjamin Smedberg]

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.

Comment 6

[Axel Hecht [:Pike]]

Attachment: use absolute path for including LOCALE_SRCDIR

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.

Comment 7

[Mats Palmgren (inactive)]

Did this checkin cause the 'qm-winxp01' orange?
make[3]: *** [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

Comment 8

[Axel Hecht [:Pike]]

qm-winxp01 is happy by now, must have been a solar storm or something.

Comment 9

[Axel Hecht [:Pike]]

This is apparently FIXED, marking as such.