$topsrcdir is wrong in mochitest runtests.pl

RESOLVED FIXED

Status

--
blocker
RESOLVED FIXED
12 years ago
10 years ago

People

(Reporter: bzbarsky, Assigned: sayrer)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

12 years ago
In my runtests.pl, I have:

  my $topsrcdir = "../../../mozilla";

which is incorrect.  Going ../../.. from _tests/testing/mochitest lands you in the root of the objdir.  You need another .. to get to the srcdir.

Not that the ../../../mozilla _is_ correct as the relative path to the srcdir that runtests.pl.in is in.

Does this perhaps depend on how the objdir and srcdir are positioned wrt each other or something, if it works for you?
(Reporter)

Comment 1

12 years ago
With the path fixed, the tests run fine, btw.
(Assignee)

Comment 2

12 years ago
Where is your objdir relative to your srcdir?
(Assignee)

Comment 3

12 years ago
actually, this is silly. we should be pointing at objdir, not topsrcdir.
(Assignee)

Comment 4

12 years ago
Created attachment 253419 [details] [diff] [review]
copy our server files where we need them

this copies httpd.js next to us, because that can depend on different build defines
Assignee: nobody → sayrer
Status: NEW → ASSIGNED

Comment 5

12 years ago
(In reply to comment #4)
> this copies httpd.js next to us, because that can depend on different build
> defines

In what way?  httpd.js should be entirely location-agnostic, especially since it's both inlinable and "component-able".  If it's not, I'd consider that a bug.  server.js isn't, of course, because of the CurProcD stuff in it, but that could be solved by passing in an environment variable -- which is how do_import_script works in the current xpcshell test harness (and also in the modifications to it in bug 351968).

Comment 6

12 years ago
Also, why not just fill runtests.pl.in with all absolute paths, so it wouldn't matter where you are when you run it (particularly given that runtests.pl is created in both objdir/testing/mochitest and objdir/_tests/testing/mochitest)?
(Assignee)

Comment 7

12 years ago
(In reply to comment #6)
> Also, why not just fill runtests.pl.in with all absolute paths

I am not sure what you mean by this.
(Assignee)

Comment 8

12 years ago
(In reply to comment #5)
> (In reply to comment #4)
> > this copies httpd.js next to us, because that can depend on different build
> > defines
> 
> In what way?

I just didn't know if I could always count on finding it somewhere inside the objdir, since it doesn't show up in objdir/netwerk/test/httpserver
(Reporter)

Comment 9

12 years ago
Weird.  I'm only getting about half the bugmail for this bug....

> Where is your objdir relative to your srcdir?

They're siblings.  /home/bzbarsky/mozilla/debug/mozilla and /home/bzbarsky/mozilla/debug/obj-firefox

Comment 10

12 years ago
(In reply to comment #7)
> > Also, why not just fill runtests.pl.in with all absolute paths
> 
> I am not sure what you mean by this.

From a generated runtests.pl:

> my $app = "$FindBin::Bin/" . "../../../dist/bin/firefox";
> my $topsrcdir = "/tmp/jwalden-moz/cleanup-tests/mozilla";
> my $dist_bin = "$FindBin::Bin/" . "../../../dist/bin";

The middle path is absolute -- it'll work no matter what directory I'm in when I run the script.  The first and third, however, require that FindBin be able to determine the script's location accurately, and if you run the wrong runtests.pl or FindBin doesn't work right, it'll fail.  The problem wouldn't exist if these two paths were absolute, and I don't see a reason they couldn't be absolute.


(In reply to comment #8)
> I just didn't know if I could always count on finding it somewhere inside the
> objdir, since it doesn't show up in objdir/netwerk/test/httpserver

No, it wouldn't show up there -- the xpcshell test harness allows you to import scripts when given the script's tree location (as of about five minutes ago -- before that it was based on location within $(DIST)/bin).  If you can use the tree location, there's no reason to copy it anywhere.


(In reply to comment #9)
> Weird.  I'm only getting about half the bugmail for this bug....

Weird, same here.  How much do you want to bet it's MIT's spam-filtering software sucking?  (I've gotten comments 0, 1, 2, 4, 5, 8 so far.)  I don't have spamscreen turned on, for what it's worth.
(Assignee)

Comment 11

12 years ago
(In reply to comment #10)
> 
> The middle path is absolute -- it'll work no matter what directory I'm in when
> I run the script.  The first and third, however, require that FindBin be able
> to determine the script's location accurately, and if you run the wrong
> runtests.pl or FindBin doesn't work right, it'll fail.  The problem wouldn't
> exist if these two paths were absolute, and I don't see a reason they couldn't
> be absolute.

The absoluteness of topsrcdir is not guaranteed. bz's isn't. that's why this bug is breaking him. Does that make sense?


(Reporter)

Comment 12

12 years ago
I don't get my own comments, so I got everything other than 2 and 4.  I do have spamscreen on, but the mails weren't in that folder...  ;)

Hmm... maybe my topsrcdir is not absolute because I have

   ac_add_options --srcdir=../mozilla

in my .mozconfig.  That's the correct path to the srcdir from the objdir (and having it there helps with ccache).
(Assignee)

Comment 13

12 years ago
bsmedberg says it will change based on many other factors
(Assignee)

Comment 14

12 years ago
Created attachment 253444 [details] [diff] [review]
also remove underscores from profile name

so. underscores in the profile name cause problems.
Attachment #253419 - Attachment is obsolete: true
(Assignee)

Comment 15

12 years ago
Comment on attachment 253444 [details] [diff] [review]
also remove underscores from profile name

Let me know if this works for you. All passing on my linux with this.
Attachment #253444 - Flags: review?(bzbarsky)
(Reporter)

Comment 16

12 years ago
Comment on attachment 253444 [details] [diff] [review]
also remove underscores from profile name

With this patch things run.  I still fail the todo() in the bug172261.html test, but I just realized that's the tree I have the relevant bug fixed in.  So all looks good.  ;)
Attachment #253444 - Flags: review?(bzbarsky) → review+
(Assignee)

Comment 17

12 years ago
Checking in Makefile.in;
/cvsroot/mozilla/testing/mochitest/Makefile.in,v  <--  Makefile.in
new revision: 1.4; previous revision: 1.3
done
Checking in runtests.pl.in;
/cvsroot/mozilla/testing/mochitest/runtests.pl.in,v  <--  runtests.pl.in
new revision: 1.5; previous revision: 1.4
done
Checking in server.js;
/cvsroot/mozilla/testing/mochitest/server.js,v  <--  server.js
new revision: 1.3; previous revision: 1.2
done
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 18

12 years ago
(In reply to comment #11)
> The absoluteness of topsrcdir is not guaranteed. bz's isn't. that's why this
> bug is breaking him. Does that make sense?

Okay -- I think we can do some hacks to fix that.  I'll look into it and file a bug with a patch if I can make it work.

Comment 19

10 years ago
Moving a bunch of Core :: Testing bugs to Testing :: Mochitest to clear out the former, which is obsolete now that we have more specialized categories for such bugs; filter on the string "MochitestMmMm" to delete all these notifications.
Component: Testing → Mochitest
Product: Core → Testing
QA Contact: testing → mochitest
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.