Closed Bug 368725 Opened 17 years ago Closed 17 years ago

$topsrcdir is wrong in mochitest runtests.pl

Categories

(Testing :: Mochitest, defect)

x86
macOS
defect
Not set
blocker

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bzbarsky, Assigned: sayrer)

Details

Attachments

(1 file, 1 obsolete file)

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?
With the path fixed, the tests run fine, btw.
Where is your objdir relative to your srcdir?
actually, this is silly. we should be pointing at objdir, not topsrcdir.
this copies httpd.js next to us, because that can depend on different build defines
Assignee: nobody → sayrer
Status: NEW → ASSIGNED
(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).
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)?
(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.
(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
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
(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.
(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?


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).
bsmedberg says it will change based on many other factors
so. underscores in the profile name cause problems.
Attachment #253419 - Attachment is obsolete: true
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)
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+
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
Closed: 17 years ago
Resolution: --- → FIXED
(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.
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.