Index: third_party/yasm/README.skia |
diff --git a/third_party/yasm/README.skia b/third_party/yasm/README.skia |
deleted file mode 100644 |
index 19a259ccf149cc4bdfc7e2f60bece816b6bf96cc..0000000000000000000000000000000000000000 |
--- a/third_party/yasm/README.skia |
+++ /dev/null |
@@ -1,138 +0,0 @@ |
-# 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. |
- |
-NOTE: We were are currently unable to build yasm for Android on x86 and x86_64. Instead we are |
-using a precompiled binary in the config/android directory. |
-TODO (msarett): Fix this! |
- |
-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. |