Closed Bug 907434 Opened 8 years ago Closed 7 years ago
Running any kind of mochitest in comm-central builds is not possible anymore (mozbuild
.base .Objdir Mismatch Exception)
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.
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).
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
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
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
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).
Still seems to work with a pymake build, so => wfm
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
(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.
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.