This should still wait for the device to be attached and finished
booting, but will prevent no-output timeouts due to
`adb wait-for-device` never finishing.
The effect should be that, when an Android device is disconnected, the
"wait for device" step will run forever, or until the device
reconnects. This should prevent a disconnected device from spreading
purple all over the status page.
BUG=skia:
Review URL: https://codereview.chromium.org/1315753010
It turns out that gyp (kind of) has support for cross
compiling with a different host and target. We simply
need to specify CC_host and CC_target instead of CC.
Making this change allows us to compile yasm on a Linux
host for Android.
We run into problems on Mac because
the linker on a Mac host requires different command line
arguments than the linker on the Android target. In
looking through the code for gyp itself and speaking to
Ben, it doesn't appear to me that gyp supports passing
different arguments to host and target linkers.
I would imagine that we would have similar problems on
Windows.
Below is a link to a CL that would fix this issue in gyp.
It looks like it has been dropped for a long time.
Thanks to Ben for this link!
https://chromiumcodereview.appspot.com/10795044/
Also I'm adding a link to the build instructions for Chrome
(thanks again Ben). It looks like they only support
building for Android from Linux.
https://code.google.com/p/chromium/wiki/AndroidBuildInstructions
My next steps are:
1) Getting in touch with Torne or someone else with gyp to
see if people are aware of this issue or interested in
fixing it.
2) Deciding if skia should care about this issue.
3) Deciding if skia should work around this issue.
It'd be really great to hear your thoughts on (2) and (3).
My first thought is that we shouldn't care because, as
long as we always compile the production copy of skia for
Android on Linux, we will get the fast code. Is this
a valid conclusion? Is there a way to write Android apps
on Mac that accidentally use the slower code?
If we do care, there are workarounds:
For Mac, we can check in a yasm binary - it's a little
smaller than the one I am deleting in this CL :-/
For Windows, we *might* be able to use the yasm.exe binary
already in externals (we get this from DEPS because this is
how chromium uses yasm on Windows).
Are there other platforms that we care about?
Let me know what you think!
BUG=skia:4028
DOCS_PREVIEW= https://skia.org/?cl=1239333002
Review URL: https://codereview.chromium.org/1239333002
When checking the skia_arch_type for "x86", instead of doing an
== compare, check if "x86" in skia_arch_type, so it will cover
both x86 and x86_64.
Except when we specifically want x86.
Set skia_arch_width based on "64" in skia_arch_type. No need to specify
in scripts.
In gyp_to_android.py, create a separate var_dict for x86_64.
BUG=skia:3419
Review URL: https://codereview.chromium.org/916113002
Rename a few files to make their function clearer.
Update other files to remove dead code or improve function.
Review URL: https://codereview.chromium.org/865943007
When running gyp_to_android inside a Skia tree, it uses the gyp program
in third_party/externals. Inside an Android tree, we need to use a
different location for gyp (the Android copy of Skia, in external/skia,
does not contain third_party/externals).
The bot handles this by importing gyp_to_android and running its main
function directly.
Add command line arguments so a human can directly run gyp_to_android.
Review URL: https://codereview.chromium.org/864503002
When generating the tool makefiles, which also calls
android_framework_gyp, we also need to pass the gyp directory.
TBR=borenet
NOTRY=True
NOTREECHECKS=True
BUG=skia:3233
Review URL: https://codereview.chromium.org/804473005
This removes ADB from the Skia checkout and also does some quick
checks to make sure the version of ADB used meets a minimum threshold
Review URL: https://codereview.chromium.org/692513003
