Last Comment Bug 907434 - Running any kind of mochitest in comm-central builds is not possible anymore (mozbuild.base.ObjdirMismatchException)
: Running any kind of mochitest in comm-central builds is not possible anymore ...
Status: RESOLVED WORKSFORME
:
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on: 909147
Blocks: 912114 901811
  Show dependency treegraph
 
Reported: 2013-08-20 15:16 PDT by Frank Wein [:mcsmurf]
Modified: 2014-10-16 14:01 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Frank Wein [:mcsmurf] 2013-08-20 15:16:55 PDT
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.
Comment 1 Frank Wein [:mcsmurf] 2013-08-20 15:32:03 PDT
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).
Comment 2 Frank Wein [:mcsmurf] 2013-08-21 05:50:42 PDT
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
Comment 3 Frank Wein [:mcsmurf] 2013-08-21 06:13:25 PDT
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
Comment 4 Frank Wein [:mcsmurf] 2013-09-14 13:30:51 PDT
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).
Comment 5 Frank Wein [:mcsmurf] 2013-09-15 03:03:59 PDT
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
Comment 6 Frank Wein [:mcsmurf] 2013-11-15 03:14:22 PST
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).
Comment 7 Frank Wein [:mcsmurf] 2013-11-15 07:59:12 PST
Still seems to work with a pymake build, so
=> wfm
Comment 8 ISHIKAWA, Chiaki 2014-10-16 08:53:04 PDT
(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.
Comment 9 Frank Wein [:mcsmurf] 2014-10-16 14:01:57 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.