| 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.
|
|
|