474703 - mochitest broken when TOPSRCDIR is relative

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Dave Camp (:dcamp)]

I don't use client.mk (preferring to manually configure and make), which ends up leaving SRCDIR a relative path.

The patch for bug 470963 changes automation.py to point at $(SRCDIR)/certs/, with SRCDIR = $(TOPSRCDIR)/build/pgo.  But mochitest runs automation.py at a different depth (/_tests/testing/mochitest), so when TOPSRCDIR is a relative path, it's at the wrong depth.

Comment 1

[Dave Camp (:dcamp)]

Attachment: workaround

This slightly ugly patch makes the pointer to the cert dir absolute if it isn't already.

Comment 2

[(not currently active) Ted Mielczarek]

Comment on attachment 358090 [details] [diff] [review]
workaround

+ifeq (,$(patsubst /%,,$(srcdir)))

$(filter /%,$(srcdir)) is somewhat simpler. (And we use it elsewhere.)

+PWD = $(shell pwd)
+ABSOLUTE_SRCDIR = $(PWD)/$(srcdir)

You can just use $(CURDIR) here instead of the PWD stuff. (Unfortunately we haven't fixed that in other places in the tree yet.)

Isn't it awesome how you have to fix this crap in three places?

r=me with those changes

Comment 3

[Johnny Stenback (:jst)]

With neither the patch attched here as written, or with the patch including Ted's suggested changes, do I get a runnable mochitest locally here. The error does change, so now it complains about:

WARNING: failed to bind socket: file ../../../../mozilla/netwerk/base/src/nsServerSocket.cpp, line 317
uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIServerSocket.init]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: ./httpd.js :: anonymous :: line 425"  data: no]

instead. Different bug presumably, or is that related to this?

Comment 4

[Honza Bambas (:mayhemer)]

I'd say you experience bug 464191.

Comment 5

[Johnny Stenback (:jst)]

"ps auxw | grep ssl" doesn't show any such processes running :(

Comment 6

[(not currently active) Ted Mielczarek]

Actually that output sounds like you have a lingering xpcshell process (running httpd.js).

Comment 7

[Honza Bambas (:mayhemer)]

Confirming this patch builds on win,mac and linux. Mochitest and leaktest work. I could not compile PGO build on mac but definitely not because of this patch.

Comment 8

[Dave Camp (:dcamp)]

Attachment: updated patch

Comment 9

[(not currently active) Ted Mielczarek]

Are you going to push this?

Comment 11

[Dave Camp (:dcamp)]

Attachment: updated to trunk [Checkin: Comment 12 & 17]

Will land this one shortly.

Comment 12

[Dave Camp (:dcamp)]

http://hg.mozilla.org/mozilla-central/rev/9f3f8b980b7a

Comment 13

[(not currently active) Ted Mielczarek]

Does this need to land on 1.9.1? Did we take the patch that broke this there? Serge: do you know?

Comment 14

[Serge Gautherie (:sgautherie)]

(In reply to comment #13)
> Does this need to land on 1.9.1?

I don't know but I assume it would.

> Did we take the patch that broke this there?

It looks like so: bug 470963 comment 10.

Comment 15

[(not currently active) Ted Mielczarek]

Ok, let's get this onto 1.9.1 then. Mano mentioned that he can't run mochitests on 1.9.1 currently because of this.

Comment 16

[(not currently active) Ted Mielczarek]

I have bug 476163 queued up for a branch landing, I'll just land this along with it. I was planning on landing it today anyway.

Comment 17

[(not currently active) Ted Mielczarek]

Pushed to 1.9.1:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/c4a1a1d2e56a

Comment 18

[Serge Gautherie (:sgautherie)]

http://hg.mozilla.org/mozilla-central/rev/6eb615f284e0
Followup to bug 474703 for pymake: use core_abspath to get Windows-style absolute paths correct

***

Any reason not to land this bug on m-1.9.1, if/when bug 483856 lands there?