skia2/third_party/yasm/README.skia
msarett cf2a6a47e4 Reenable yasm for Android x86 and x86-64 on Linux host
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
2015-07-21 12:01:48 -07:00

135 lines
5.5 KiB
Plaintext

# Copyright (c) 2012 The Chromium Authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
These platform specific Makefiles are necesary to build yasm on different platforms. The rest of
the yasm code is pulled into externals via the DEPS file.
Chromium builds yasm using the below procedure. We take a few shortcuts. We mirror Chromium's
yasm repositories in our DEPS file, and we copy these config files directly from Chromium.
Excerpt from [chromium] //src/third_party/yasm/README.chromium:
Instructions for recreating the yasm.gyp file.
1) Get a clean version of the yasm source tree. The clean tree can be found
at:
src/third_party/yasm/source/yasm
2) Run configure on the pristine source from a different directory (eg.,
/tmp/yasm_build). Running configure from another directory will keep
the source tree clean.
3) Next, capture all the output from a build of yasm. We will use the build
log as a reference for making the yasm.gyp file.
make yasm > yasm_build_log 2> yasm_build_err
4) Check yasm_build_err to see if there are any anomalies beyond yasm's
compiler warnings.
5) Grab the generated Makefile, libyasm-stdint.h, config.h, and put into
the correct platform location. For android platform, copy the files
generated for linux, but make sure that ENABLE_NLS is not defined to
allow mac host compiles to work. For ios, copy the files from mac.
src/third_party/yasm/source/config/[platform]
While we do not directly use the "Makefile" to build, it is needed by
the "genmodule" subprogram as input for creating the available modules
list.
6) Make sure all the subprograms are represented in yasm.gyp.
grep '^gcc' yasm_build_log |
grep -v ' -DHAVE_CONFIG_H '
The yasm build creates a bunch of subprograms that in-turn generate
more .c files in the build. Luckily the commands to generate the
subprogram do not have -DHAVE_CONFIG_H as a cflag.
From this list, make sure all the subprograms that are build have
appropriate targets in the yasm.gyp.
You will notice, when you get to the next step, that there are some
.c source files that are compiled both for yasm, and for genperf.
Those should go into the genperf_libs target so that they can be
shared by the genperf and yasm targets. Find those files by appending
| grep 'gp-'
to the command above.
7) Find all the source files used to build yasm proper.
grep -E '^gcc' yasm_build_log |
grep ' -DHAVE_CONFIG_H ' |
awk '{print $NF }' |
sed -e "s/'\.\/'\`//" | # Removes some garbage from the build line.
sort -u |
sed -e "s/\(.*\)/'\1',/" # Add quotes to each line.
Reversing the -DHAVE_CONFIG_H filter from the command above should
list the compile lines for yasm proper.
This should get you close, but you will need to manually examine this
list. However, some of the built products are still included in the
command above. Generally, if the source file is in the root directory,
it's a generated file.
Inspect the current yasm.gyp for a list of the subprograms and their
outputs.
Update the sources list in the yasm target accordingly. Read step #9
as well if you update the source list to avoid problems.
8) Update the actions for each of the subprograms.
Here is the real fun. For each subprogram created, you will need to
update the actions and rules in yasm.gyp that invoke the subprogram to
generate the files needed by the rest of the build.
I don't have any good succinct instructions for this. Grep the build
log for each subprogram invocation (eg., "./genversion"), look at
its command inputs and output, then verify our yasm.gyp does something
similar.
The good news is things likely only link or compile if this is done
right so you'll know if there is a problem.
Again, refer to the existing yasm.gyp for a guide to how the generated
files are used.
Here are a few gotchas:
1) genmodule, by default, writes module.c into the current
directory. This does not play nicely with gyp. We patch the
source during build to allow specifying a specific output file.
2) Most of the generated files, even though they are .c files, are
#included by other files in the build. Make sure they end up
in a directory that is in the include path for the build.
One of <(shared_generated_dir) or <(generated_dir) should work.
3) Some of the genperf output is #included while others need to be
compiled directly. That is why there are 2 different rules for
.gperf files in two targets.
9) Check for python scripts that are run.
grep python yasm_build_log
Yasm uses python scripts to generate the assembly code description
files in C++. Make sure to get these put into the gyp file properly as
well. An example is gen_x86_insn.py for x86 assembly.
Note that at least the gen_x86_insn.py script suffers from the same
problem as genmacro in that it outputs to the current directory by
default. The yasm.gyp build patches this file before invoking it to
allow specifying an output directory.
10) Recreate the 'AdditionalOptions!': [ '/analyze' ] block so that VC++
/analyze builds won't fail.
11) If all that's is finished, attempt to build....and cross your fingers.