Date : Nov 23, 2008
People : James Boston, David Humphrey, Gijs Kruitbosch, Mark Finkle, Ted Mielczarek
Topic : Pathnames and starting binaries from xpcshell
Note:
I've discovered that this bit of code will return the full directory path that contains xpcshell:
var file = Components.classes["@mozilla.org/file/directory_service;1"]
.getService(Components.interfaces.nsIProperties)
.get("CurProcD", Components.interfaces.nsIFile);
ie. print(file.path) will return /home/james/mozilla/obj-ff/dist/bin
However, I have not yet determined how reliable this is. According to devmo, this "usually" works.
15:58 < jboston> I'm trying to interpret this: https://bugzilla.mozilla.org/show_bug.cgi?id=442393#c12
15:58 < firebot> jboston: Bug 442393 nor, --, ---, nobody@mozilla.org, NEW, nsIProcess.kill() does not work on Win32
15:58 * humph reads
15:58 < jboston> I don't know what "You should be able to use xpcshell itself" means.
15:59 <@humph> I wonder if he means similar to how the httpd is done
15:59 <@humph> http://mxr.mozilla.org/mozilla-central/source/netwerk/test/httpserver/ is what I mean, used for testing only
16:00 <@humph> I don't know what he means exactly
16:01 <@humph> why not just add a .zip with the bins to the bug?
16:01 <@humph> in a new attachment?
16:01 <@humph> that's what I'd do
16:02 < jboston> I thought that some sort of automated test for inclusion in the tree is required.
16:03 <@humph> it is, yeah
16:03 <@humph> I think you want to get mfinkle to comment.
16:07 <@humph> jboston: ted would be another good resource here
16:08 <@humph> who is also unlikely to surface on a sunday afternoon.
16:27 < Gijs> humph, jboston: perhaps he means that you could run another instance of xpcshell from the unit test?
16:27 <@humph> Gijs: if you can shed light, please do so
16:27 < Gijs> you could make it load a different test files so as to get different error codes or whatever
16:28 < Gijs> well, I am not sure if I understand his comment correctly
16:28 < Gijs> I'm not at all knowledgeable in this area
16:28 < Gijs> all I'm saying is that, if you need a process to run and kill, to see if the API works, instead of writing a separate program specifically for this purpose, you can get away with just running xpcshell itself
16:29 < Gijs> and perhaps that's what he means
16:29 <@humph> Gijs: can you give jboston some tips on doing this, or point at something that's doing it now?
16:29 <@humph> I think you're right
16:29 < Gijs> ehm
16:29 < Gijs> I don't know of any test that does that right now, nor exactly how it would be done
16:30 < Gijs> I believe there is some MDC docs on the functionality xpcshell provides itself (load etc.) - which may include
documentation for exiting with a specific return code
16:31 < Gijs> actually, I was confused - I was thinking of the spidermonkey executable ( |js| - the plain JavaScript shell)
16:32 < Gijs> for xpcshell, presumably you should be able to use the "normal" Mozilla Platform interfaces to pick an exit code
16:32 * humph didn't know you could start another xpcshell from inside xpcshell
16:32 < Gijs> well
16:32 < Gijs> I was under the impression we're dealing with a patch for nsIProcess.run/kill
16:32 < Gijs> you could just use that to run xpcshell, right?
16:32 < Gijs> it's just another executable...
16:32 < Gijs> I'm not saying it's an xpcshell feature to clone itself or anything...
16:33 * humph strokes his whiskers
16:33 <@humph> that's very interesting
16:33 <@humph> very interesting indeed
16:34 * Gijs tries to find an interface that lets you specify an exit code
16:38 * Gijs fails :(
16:38 < Gijs> my build env sucks at the moment, however
16:41 < Gijs> hmm
16:41 < Gijs> what's an easy way to check rv values?
16:41 < Gijs> from an exiting app, I mean?
16:42 < Gijs> (on Linux)
16:42 <@humph> echo $?
16:44 < Gijs> excellent
16:44 < Gijs> so, from within xpcshell, just call quit(n);
16:44 <@humph> hot
16:44 < Gijs> (I suspected that'd work, but wanted to be sure before suggesting it)
16:44 < Gijs> jboston: so presumably, on linux for instance, you'd want to run something like: run-mozilla.sh xpcshell foo.js
16:45 < Gijs> for various foo.js
16:45 < Gijs> each of which does something different
16:45 < Gijs> not sure how you should crash xpcshell explicitly
16:45 <@humph> timeless will know
16:45 < jboston> Gijs: Thank-you.
16:45 < Gijs> yeah, was just about to suggest that
16:45 < Gijs> jboston: the most sucky thing is going to be figuring all the paths out, though!
16:46 * Gijs doesn't know enough about xpcshell unit tests to be able to help with that
16:46 <@humph> shouldn't be that bad. ted will know
16:46 < Gijs> anyway, this should get you into the realm of the last 20% taking up 80% of the time ;)
16:46 <@humph> :)
16:46 < Gijs> humph: meh, xpcshell (and mozilla in general) are picky about environment variables, working dirs and so on
16:47 < Gijs> that's why you're calling that run-mozilla.sh script
16:47 <@humph> yes
16:47 < Gijs> so yeah, it'd scare me :)
16:47 * Gijs goes back to refactoring his app (much more boring, but oh well)
17:03 < mfinkle> jboston: brief pong
17:03 < mfinkle> I meant, xpcshell is already a binary
17:03 < mfinkle> launch it with a JS script
17:03 < mfinkle> should work, right?
17:04 < mfinkle> why would the binaries need to be special?
17:04 < jboston> mfinkle: Ok. I'll try that approach. Thank-you.
17:04 <@humph> mfinkle: ideas about paths for him?
17:04 <@humph> Gijs thinks that will be pain
17:08 < mfinkle> humph, jboston: I have no idea about path issues
17:08 < mfinkle> I'd just try it and see what happens
17:09 < mfinkle> bbl
17:09 < jboston> mfinkle: Ok. I'll experiment with that.
17:10 < ted> also, FWIW, $(RUN_TEST_PROGRAM) == run-mozilla.sh
17:10 < ted> where it matters
17:11 < ted> also, you can very easily build custom binaries
17:11 < ted> just make TestProgram.cpp, and set SIMPLE_PROGRAMS = TestProgram
17:11 < ted> in the makefile
17:12 < ted> then you'll wind up with TestProgram.exe in $(DIST)/bin
17:14 < jboston> ted: Thanks. That was what I was looking for. I get stuck on makefiles.
|
