Closed Bug 493837 Opened 11 years ago Closed 11 years ago
Maker fails when using ../configure directly
The test_jar_mn test in the xpcshell tests fails if configure is used directly to create a build directory. Steps to reproduce: make a directory "debug-build" in srcdir and then use ../configure. Run make and then make check. I understand this is not the recommended way of running tests, but this is the only test that fails and its really super annoying. I would greatly appreciate if someone could fix this. Comparing manifests... Comparing packages... diff: ../../../dist/xpi-stage/test_jar_mn/chrome/test/three/l10nfile.txt: No such file or directory diff: ../../../dist/xpi-stage/test_jar_mn/chrome/test/two/otherfile.xml: No such file or directory TEST-UNEXPECTED-FAIL | config/tests/ref-simple | different content in jar make: *** [check-symlink] Error 1 make: *** [check-jar-mn] Error 2 make: *** [check] Error 2
Summary: test_jar_mn → test_jar_mn test fails when using ../configure directly
This is really more a test/build issue, but I don't know what component to use here.
Assignee: general → nobody
QA Contact: general → build-config
Pike wrote these tests.
The problem is that the symlink for dist/xpi-stage/test_jar_mn/chrome/test/two/otherfile.xml ends up being relative to config/tests/src-simple instead of relative to the directory the link is in.
This bug is really annoying. Could we please disable the test until its fixed?
no. use a mozconfig (... :)
I doubt I am the only person who prefers direct configure over some obscure custom mozconfig thing. Think of the users =)
(In reply to comment #3) > The problem is that the symlink for > dist/xpi-stage/test_jar_mn/chrome/test/two/otherfile.xml ends up being relative > to config/tests/src-simple instead of relative to the directory the link is in. So what's the fix?
Assignee: nobody → l10n
So, the failing tests actually indicate a real failure of JarMaker for symlinks with relative srcdir. The fix depends a bit on what we actually want it to do. The easiest way to fix it is to make all symlinks point to absolute paths to the sourcedir. Not sure if it's vital to be able to move the parent of both src and obj dir and have the links still work.
Ted said on irc that he doesn't really care if we use relative or absolute links, and I can see them failing unexpectedly in both ways (either move the build dir, or the parent of both build and src), thus I'm going for the easier solution.
Summary: test_jar_mn test fails when using ../configure directly → JarMaker fails when using ../configure directly
Using absolute paths for the various breeds of source dirs. That fixes the tests, and doesn't regress the regular jar build, which I tested on mac.
Attachment #380160 - Flags: review?(ted.mielczarek)
Attachment #380160 - Flags: review?(ted.mielczarek) → review+
http://hg.mozilla.org/mozilla-central/rev/31c75e871924, FIXED. This is a low-risk symlink only fix that we should take on the branch, too, IMHO. Nothing 3.5.0, but IMHO definitely wanted.
Status: NEW → RESOLVED
Closed: 11 years ago
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Comment on attachment 380160 [details] [diff] [review] convert the various source dirs to absolute paths Removing dead flag; if you want it, please use one of the current flags.
I still think we should take this on the branch. This will make further patches to JarMaker.py like in bug 505713 easier to take on the stable branch, and help us help localizers to start new locales on that branch.
blocking1.9.1: --- → ?
Do we expect many localizers will start on that branch given our anticipated ship dates for 3.6 and 3.7?
We do have active new projects, so yes.
Not blocking, but wanted. Does this patch apply to 1.9.1?
Yes, applies fine.
Comment on attachment 380160 [details] [diff] [review] convert the various source dirs to absolute paths Approved for 184.108.40.206. a=ss for release-drivers Please land on mozilla-1.9.1 and use the ".2-fixed" option of the "status1.9.1" flag.
Attachment #380160 - Flags: approval220.127.116.11+
Using the latest mozilla-1.9.1 (pulled an hour ago), I cannot reproduce this bug. Verified1.9.1
You need to log in before you can comment on or make changes to this bug.