diff options
author | 2015-07-02 10:40:24 -0700 | |
---|---|---|
committer | 2015-07-02 10:40:24 -0700 | |
commit | 94a2fbc6cf7cc14d7e6149eb22455db6aca06b8f (patch) | |
tree | bfe574845dc33bc8b8700c74ff3a3b613fc48ec7 /third_party/yasm/README.skia | |
parent | 6c90e09575c1a77aee060aa475fdb3d25a17d6a0 (diff) |
Revert of Switch SkJpegCode to libjpeg-turbo (patchset #29 id:750001 of https://codereview.chromium.org/1180983002/)
Reason for revert:
DEPS roll failing
Original issue's description:
> Add libjpeg-turbo library (depends on yasm)
> 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:
>
> Committed: https://skia.googlesource.com/skia/+/b60c3f8291529303299262dba19b1a896060bd2d
>
> Committed: https://skia.googlesource.com/skia/+/f8bf9181d7b0463c8e371755cfbb9ece90b34fc5
>
> Committed: https://skia.googlesource.com/skia/+/e9e3ee33f30c14c31afd5fc3fe4dda7f15783c75
>
> Committed: https://skia.googlesource.com/skia/+/40141b57f061fbfcc2fa38da942d9efe25aca4d0
TBR=scroggo@google.com,djsollen@google.com,emmaleer@google.com,msarett@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1226543003
Diffstat (limited to 'third_party/yasm/README.skia')
-rw-r--r-- | third_party/yasm/README.skia | 138 |
1 files changed, 0 insertions, 138 deletions
diff --git a/third_party/yasm/README.skia b/third_party/yasm/README.skia deleted file mode 100644 index 19a259ccf1..0000000000 --- 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. |