If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

JarMaker fails when using ../configure directly

RESOLVED FIXED in mozilla1.9.2a1

Status

()

Core
Build Config
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: gal, Assigned: Pike)

Tracking

({verified1.9.1})

Trunk
mozilla1.9.2a1
verified1.9.1
Points:
---

Firefox Tracking Flags

(blocking1.9.1 -, status1.9.1 .2-fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
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[2]: *** [check-symlink] Error 1
make[1]: *** [check-jar-mn] Error 2
make: *** [check] Error 2
(Reporter)

Updated

9 years ago
Summary: test_jar_mn → test_jar_mn test fails when using ../configure directly
(Reporter)

Comment 1

9 years ago
This is really more a test/build issue, but I don't know what component to use here.

Updated

9 years ago
Assignee: general → nobody
Component: JavaScript Engine → Build Config
QA Contact: general → build-config
Pike wrote these tests.
(Assignee)

Comment 3

9 years ago
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.
Duplicate of this bug: 494486
(Reporter)

Comment 5

8 years ago
This bug is really annoying. Could we please disable the test until its fixed?

Comment 6

8 years ago
no. use a mozconfig (... :)
(Reporter)

Comment 7

8 years ago
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
(Assignee)

Comment 9

8 years ago
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.
(Assignee)

Comment 10

8 years ago
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
(Assignee)

Comment 11

8 years ago
Created attachment 380160 [details] [diff] [review]
convert the various source dirs to absolute paths

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+
(Assignee)

Comment 12

8 years ago
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
Last Resolved: 8 years ago
Flags: wanted1.9.1.x?
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
(Assignee)

Updated

8 years ago
Attachment #380160 - Flags: approval1.9.1?
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.
Attachment #380160 - Flags: approval1.9.1?
(Assignee)

Comment 14

8 years ago
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?
(Assignee)

Comment 16

8 years ago
We do have active new projects, so yes.
Not blocking, but wanted. Does this patch apply to 1.9.1?
blocking1.9.1: ? → -
status1.9.1: --- → wanted
Flags: wanted1.9.1.x?
(Assignee)

Comment 18

8 years ago
Yes, applies fine.
Comment on attachment 380160 [details] [diff] [review]
convert the various source dirs to absolute paths

Approved for 1.9.1.2. 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: approval1.9.1.2+
(Assignee)

Comment 20

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/957cf306a223, fixed1.9.1.2
status1.9.1: wanted → .2-fixed
Using the latest mozilla-1.9.1 (pulled an hour ago), I cannot reproduce this bug.  Verified1.9.1
Keywords: verified1.9.1
You need to log in before you can comment on or make changes to this bug.