The default bug view has changed. See this FAQ.

Running any kind of mochitest in comm-central builds is not possible anymore (mozbuild.base.ObjdirMismatchException)

RESOLVED WORKSFORME

Status

()

Core
Build Config
RESOLVED WORKSFORME
4 years ago
3 years ago

People

(Reporter: mcsmurf, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
I'm currently struggling a bit to get any mochitests running when building SeaMonkey on comm-central. Is there maybe a nice workaround or does this need a patch? The problem is I get a mozbuild.base.ObjdirMismatchException when trying to run tests:
[cd to objdir]
TEST_PATH=suite/common/tests/browser/ pymake mochitest-browser-chrome
[...]
mozbuild.base.ObjdirMismatchException: Objdir mismatch: c:\mozilla\tree-hg\objdirs\seamonkey-objdir\mozilla != c:\mozilla\tree-hg\comm-central\objdirs\seamonkey-objdir
(note that the second path is a bit misleading here, it does not correctly display the relative path from my mozconfig file)

The issue is that it sees ...\mozilla as topobjdir, but in reality (.mozconfig) the objdir one level higher is my topobjdir.
I've also tried to run it in another way like this:
[cd to objdir]
$ mozilla/_virtualenv/Scripts/python.exe mozilla/_tests/testing/mochitest/runtests.py --test-path=suite/common/tests/browser/

but this also gives me a ObjdirMismatchException.
I don't need any super-simple ./mach command or similar to run tests, but it would be very good if it's possible to run any mochitest at all inside comm-central.
(Reporter)

Comment 1

4 years ago
Note to self/others: What might be possible as (extremely) complicated workaround is to package all tests with "make package-tests", package SeaMonkey with "make package" and then extract both new .zip/.tar.gz(?) files in a new folder to run tests there (that's basically the way buildbot runs tests).
(Reporter)

Comment 2

4 years ago
So what does seem to work better as workaround: Don't specify an objdir inside the mozconfig file. Not the ideal workaround as I want my objdir on another hard drive/folder. I suspect this works as the check before ObjdirMismatchException only happens when MOZ_OBJDIR has been defined inside .mozconfig
(Reporter)

Comment 3

4 years ago
As an addition to the workaround in Comment 2: You can create a NTFS symbolic link or Windows (or a symbol link on Linux) to move the objdir to another hard drive/folder without specifying MOZ_OBJDIR, as an example in my case (needs Windows admin privs once):
[cd to comm-central source folder]
mklink /D obj-i686-pc-mingw32 F:\mozilla\seamonkey-objdir

and then all objdir files will go to F:\mozilla\seamonkey-objdir

Updated

4 years ago
Blocks: 912114
(Reporter)

Comment 4

4 years ago
BTW: The landed patch from Bug 909147 does not seem to help here, it looks like resolving NTFS symbolic links inside comm-central builds does not seem to work properly (within a mozilla-central build it seems to work, at least running mochitest within a FF build with a similar MOZ_OBJDIR option does work). I still get the problem from Comment 0:
"(note that the second path is a bit misleading here, it does not correctly display the relative path from my mozconfig file)"
even though it tries to append "mozilla" now these days to compare topobjdir against the "correct" objdir:
"168             and not samepath(topobjdir, os.path.join(config_topobjdir, "mozilla")):"
(from the patch from Bug 909147).
Depends on: 909147
(Reporter)

Comment 5

4 years ago
To clarify comment 1, comment 4:
I use this option to specify the objdir inside mozconfig:
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdirs/seamonkey-objdir
(Reporter)

Comment 6

3 years ago
I don't know what changed, but this now seems to work again. Possibly because I now build with mozmake (see https://mail.mozilla.org/pipermail/firefox-dev/2013-October/001027.html), but I used pymake to run the mochitests (as I wanted to check if this bug here still happens). I'll try a complete new build with pymake (if it works; a few days ago my pymake build was broken, so I used mozmake).
(Reporter)

Comment 7

3 years ago
Still seems to work with a pymake build, so
=> wfm
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME

Comment 8

3 years ago
(In reply to Frank Wein [:mcsmurf] from comment #5)
> To clarify comment 1, comment 4:
> I use this option to specify the objdir inside mozconfig:
> mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdirs/seamonkey-objdir

At one point in time, I found using relative path for OBJ directory
did not work well any more with C-C thunderbird compilation,
and a few retries, forced to use absolute path.
But I could not find exactly when I had to switch to absolute path. Maybe in the last 2 years or so.
(Reporter)

Comment 9

3 years ago
I think using a relative path now stopped working with the latest build system changes (certainly less than two years ago). But for now it looks like an absolute path is required.
You need to log in before you can comment on or make changes to this bug.