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
Mangle external function names to avoid conflict with libjpeg
Take advantage of direct color conversion (RGBA, BGRA, 565)
Prepare to use jpeg_skip_scanlines (when it is upstreamed)
BUG=skia:
Review URL: https://codereview.chromium.org/1180983002
All platforms except android are configured to use the statically linked copy
of libpng. Android uses the system provided dynamic copy for SkImageDecoder
and the static copy for SkCodec. The exception being android framework builds
that currently use the dynamic copy everywhere.
This CL also enables NEON optimizations for libpng.
Review URL: https://codereview.chromium.org/1058823002
Reason for revert:
breaking the nexus_9 and ios builds.
Original issue's description:
> Enable both static and dynamically linked libpng
>
> All platforms except android are configured to use the statically linked copy of libpng. Android uses the system provided dynamic copy for SkImageDecoder and the static copy for SkCodec. The exception being android framework builds that currently use the dynamic copy everywhere.
>
> This CL also enables NEON optimizations for libpng.
>
> Committed: https://skia.googlesource.com/skia/+/2469c999518e7b0063d35e9e2eb074a0477c21acTBR=scroggo@google.com,msarett@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1050183002
All platforms except android are configured to use the statically linked copy of libpng. Android uses the system provided dynamic copy for SkImageDecoder and the static copy for SkCodec. The exception being android framework builds that currently use the dynamic copy everywhere.
This CL also enables NEON optimizations for libpng.
Review URL: https://codereview.chromium.org/1032253003
DM:
Add a flag to use SkCodec instead of SkImageDecoder.
SkCodec:
Base class for codecs, allowing creation from an SkStream or an SkData.
An SkCodec, on creation, knows properties of the data like its width and height. Further calls can be used to generate the image.
TODO: Add scanline iterator
SkPngCodec:
New decoder for png. Wraps libpng. The code has been repurposed from SkImageDecoder_libpng.
TODO: Handle other destination colortypes
TODO: Substitute the transpose color
TODO: Allow silencing warnings
TODO: Use RGB instead of filler?
TODO: sRGB
SkSwizzler:
Simplified version of SkScaledSampler. Unlike the sampler, this object does no sampling.
TODO: Implement other swizzles.
Requires a gclient sync to pull down libpng.
BUG=skia:3257
Committed: https://skia.googlesource.com/skia/+/ca358852b4fed656d11107b2aaf28318a4518b49
(and then reverted)
Review URL: https://codereview.chromium.org/930283002
Partially in preparation for building libpng on Windows.
Also, this makes us consistent across platforms for PDF.
Uses the version of zlib checked into the Chromium tree.
Remove miniz, which is replaced by zlib.
Review URL: https://codereview.chromium.org/966963002
- Adds miniz.c v115_r4 (latest release) to third_party.
- Merges SkDeflateWStream into SkFlate so including "miniz.c" links
without duplicating symbols.
The only interesting code change I've made is to remove the line
fImpl->fZStream.data_type = Z_BINARY;
from SkDeflateWStream::SkDeflateWStream(). miniz doesn't have Z_BINARY
defined, and as far as I can tell, both zlib and miniz ignore data_type.
We should be able to swap skflate.gyp's dependency between zlib.gyp:zlib and
zlib.gyp:miniz at will (except of course on Windows) if we're interested in
zlib itself. I've left android framework on its own zlib. I think this all
means we can stop defining SK_NO_FLATE on Windows.
I'll leave the possible cleanup of SK_NO_FLATE itself for another time. Might
be we always want to keep this dependency optional.
CQ_EXTRA_TRYBOTS=client.skia:Test-Win8-ShuttleA-HD7770-x86-Debug-Trybot
BUG=skia:
Review URL: https://codereview.chromium.org/957323003
The Mac fontconfig just #defines the cache directory, which works fine if fontconfig never has to look up any fonts (the case until now). If it has to actually find fonts from the disk, the cache directory and config directory need to be properly defined as well as running fc-cache to populate the cache directory.
Populating the cache directory can take some time, but should only happen on a clean build. To remove this extra time, we have to not build poppler on Mac, which can now be accomplished with GYP_DEFINES="skia_mac_poppler=0"
R=epoger@google.com
Author: vandebo@chromium.org
Review URL: https://codereview.chromium.org/132333002
git-svn-id: http://skia.googlecode.com/svn/trunk@13007 2bbb7eff-a529-9590-31e7-b0007b416f81
The Mac fontconfig just #defines the cache directory, which works fine if fontconfig never has to look up any fonts (the case until now). If it has to actually find fonts from the disk, the cache directory and config directory need to be properly defined as well as running fc-cache to populate the cache directory.
Populating the cache directory can take some time, but should only happen on a clean build. To remove this extra time, we have to not build poppler on Mac, which can now be accomplished with GYP_DEFINES="skia_mac_poppler=0"
R=bungeman@google.com, epoger@google.com
Author: vandebo@chromium.org
Review URL: https://codereview.chromium.org/113203003
git-svn-id: http://skia.googlecode.com/svn/trunk@12994 2bbb7eff-a529-9590-31e7-b0007b416f81
