465823 - Allow XULRunner apps to use Mochitest framework in 1.9.1

Status: RESOLVED FIXED

(Testing :: Mochitest, defect)

Description

[Mark Finkle (:mfinkle) (use needinfo?)]

Using 1.9.0.x, XULRunner apps can easily use the mochitest framework. In 1.9.1, we added code that assumes certain files are in the DIST/bin folder, but don't exist for XULRunner apps. XULRunner apps build xulrunner in a separate objdir and that objdir is referenced using LIBXUL_DIST.

I have a patch coming up that switches from DIST to LIBXUL_DIST in a few places and allows the code to work for Firefox and XULRunner apps.

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

Attachment: patch

This patch just changes $(DIST) to $(LIBXUL_DIST) in a few places. It works in Firefox because LIBXUL_DIST points to the dist folder. LIBXUL_DIST is an absolute path, so I had to change places that expected a relative path.

Comment 2

[Honza Bambas (:mayhemer)]

For me this patch works on mac and win.

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #2)
> For me this patch works on mac and win.

Is it broken on linux? or just not tested?

Comment 4

[Honza Bambas (:mayhemer)]

(In reply to comment #3)
> (In reply to comment #2)
> > For me this patch works on mac and win.
> 
> Is it broken on linux? or just not tested?

Just not tested :)

Comment 5

[cmtalbert]

Ok, I ran this patch on a fennec build from this morning (pulled at 10:15).  The build works to run (linux desktop) fennec's mochitests, which is very good :-)

I have a couple of issues, not sure how important they are though:

1. We don't put the entire build tree on the devices.  So, having full paths in places like automation.py makes life difficult.  The reason we do this is because it takes so much space to put the build tree in place. Is there any way we can get a relative path there?  Also, in the future, I'd like to envision a way that people can run tests without building, and full paths will complicate that effort.

2. How will we address the fact that we now have <objdir>/mobile/_tests as well?  Is this the second half of your patch that you alluded to? :-)

Thanks!

Comment 6

[cmtalbert]

(In reply to comment #5)
> Ok, I ran this patch on a fennec build from this morning (pulled at 10:15). 
> The build works to run (linux desktop) fennec's mochitests, which is very good
> :-)
> 
> I have a couple of issues, not sure how important they are though:
> 
> 1. We don't put the entire build tree on the devices.  So, having full paths in
> places like automation.py makes life difficult.  The reason we do this is
> because it takes so much space to put the build tree in place. Is there any way
> we can get a relative path there?  Also, in the future, I'd like to envision a
> way that people can run tests without building, and full paths will complicate
> that effort.

Just found out from RelEng that they plan to just buy more space for their devices and so be able to put the entire objdir on the device.  That solves the problem for now, but I still maintain that someday we'd like to not require testers to build the product.  We can choose whether to cross that bridge now or later and decide whether or not that matters in this context.

Comment 7

[(not currently active) Ted Mielczarek]

Comment on attachment 349060 [details] [diff] [review]
patch

Looks fine. To answer Clint's concerns, there are other problems we'll have to fix to run tests without a full objdir. We can file those separately. Notably, we'll need to run Mochitests directly from the srcdir, and runtests.py should take another argument to specify where the other binaries it uses are (like xpcshell, ssltunnel, certutil).

Comment 8

[cmtalbert]

(In reply to comment #7)
> (From update of attachment 349060 [details] [diff] [review])
> Looks fine. To answer Clint's concerns, there are other problems we'll have to
> fix to run tests without a full objdir. We can file those separately. Notably,
> we'll need to run Mochitests directly from the srcdir, and runtests.py should
> take another argument to specify where the other binaries it uses are (like
> xpcshell, ssltunnel, certutil).
I filed bug 460515 for this issue last week or so.  I'll see if I can get a patch for it next week.

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

http://hg.mozilla.org/mozilla-central/rev/8e208933f510

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

landed in mozilla 1.9.1
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/1c0989beb086