Another use case here is we want to write GTests to test Gecko Media Plugins. These are the plugins we're using for EME and OpenH264 plugins. To load them we need to set an environment variable to the path of the directory in which the plugin dll resides, or pass that path to the plugin to a function. Currently we haven't figured out how to do this, for all reasons you outlined already.

Chris P.



On 7/11/2014 12:06 AM, Ted Mielczarek wrote:
On Thu, Jul 10, 2014, at 12:17 AM, Anthony Jones wrote:
I've recently been using gtest for media code. However I've come across
the issue of fopen() working locally but not on the try servers.

https://tbpl.mozilla.org/?tree=Try&rev=11d9f94c54bd

Any suggestions on how I should do this differently?
I'm guessing this is a working directory issue. On Try gtest will be
running as part of make check, so the cwd will be $objdir/testing/gtest:
http://hg.mozilla.org/mozilla-central/annotate/cb75d6cfb004/testing/gtest/Makefile.in#l24

Whereas if you're doing "mach gtest" it looks like it doesn't change the
cwd so it'll be $topsrcdir:
http://hg.mozilla.org/mozilla-central/annotate/cb75d6cfb004/python/mozbuild/mozbuild/mach_commands.py#l616

If you run "./mach build testing/gtest/check" do you get the same
failures locally?

We should make these consistent to avoid this problem. However, note
that relying on external files is going to cause issues in the future,
we should figure out exactly what we want here--we're going to
eventually move gtest out of make check and into the test package, which
means that we'd have to explicitly copy files that tests want to
reference.

-Ted

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to