1 # Copyright (c) 2012 The Chromium Authors. All rights reserved. 2 # Use of this source code is governed by a BSD-style license that can be 3 # found in the LICENSE file. 4 5 These platform specific Makefiles are necesary to build yasm on different platforms. The rest of 6 the yasm code is pulled into externals via the DEPS file. 7 8 Chromium builds yasm using the below procedure. We take a few shortcuts. We mirror Chromium's 9 yasm repositories in our DEPS file, and we copy these config files directly from Chromium. 10 11 Excerpt from [chromium] //src/third_party/yasm/README.chromium: 12 13 Instructions for recreating the yasm.gyp file. 14 1) Get a clean version of the yasm source tree. The clean tree can be found 15 at: 16 17 src/third_party/yasm/source/yasm 18 19 2) Run configure on the pristine source from a different directory (eg., 20 /tmp/yasm_build). Running configure from another directory will keep 21 the source tree clean. 22 23 3) Next, capture all the output from a build of yasm. We will use the build 24 log as a reference for making the yasm.gyp file. 25 26 make yasm > yasm_build_log 2> yasm_build_err 27 28 4) Check yasm_build_err to see if there are any anomalies beyond yasm's 29 compiler warnings. 30 31 5) Grab the generated Makefile, libyasm-stdint.h, config.h, and put into 32 the correct platform location. For android platform, copy the files 33 generated for linux, but make sure that ENABLE_NLS is not defined to 34 allow mac host compiles to work. For ios, copy the files from mac. 35 36 src/third_party/yasm/source/config/[platform] 37 38 While we do not directly use the "Makefile" to build, it is needed by 39 the "genmodule" subprogram as input for creating the available modules 40 list. 41 42 6) Make sure all the subprograms are represented in yasm.gyp. 43 44 grep '^gcc' yasm_build_log | 45 grep -v ' -DHAVE_CONFIG_H ' 46 47 The yasm build creates a bunch of subprograms that in-turn generate 48 more .c files in the build. Luckily the commands to generate the 49 subprogram do not have -DHAVE_CONFIG_H as a cflag. 50 51 From this list, make sure all the subprograms that are build have 52 appropriate targets in the yasm.gyp. 53 54 You will notice, when you get to the next step, that there are some 55 .c source files that are compiled both for yasm, and for genperf. 56 57 Those should go into the genperf_libs target so that they can be 58 shared by the genperf and yasm targets. Find those files by appending 59 60 | grep 'gp-' 61 62 to the command above. 63 64 7) Find all the source files used to build yasm proper. 65 66 grep -E '^gcc' yasm_build_log | 67 grep ' -DHAVE_CONFIG_H ' | 68 awk '{print $NF }' | 69 sed -e "s/'\.\/'\`//" | # Removes some garbage from the build line. 70 sort -u | 71 sed -e "s/\(.*\)/'\1',/" # Add quotes to each line. 72 73 Reversing the -DHAVE_CONFIG_H filter from the command above should 74 list the compile lines for yasm proper. 75 76 This should get you close, but you will need to manually examine this 77 list. However, some of the built products are still included in the 78 command above. Generally, if the source file is in the root directory, 79 it's a generated file. 80 81 Inspect the current yasm.gyp for a list of the subprograms and their 82 outputs. 83 84 Update the sources list in the yasm target accordingly. Read step #9 85 as well if you update the source list to avoid problems. 86 87 8) Update the actions for each of the subprograms. 88 89 Here is the real fun. For each subprogram created, you will need to 90 update the actions and rules in yasm.gyp that invoke the subprogram to 91 generate the files needed by the rest of the build. 92 93 I don't have any good succinct instructions for this. Grep the build 94 log for each subprogram invocation (eg., "./genversion"), look at 95 its command inputs and output, then verify our yasm.gyp does something 96 similar. 97 98 The good news is things likely only link or compile if this is done 99 right so you'll know if there is a problem. 100 101 Again, refer to the existing yasm.gyp for a guide to how the generated 102 files are used. 103 104 Here are a few gotchas: 105 1) genmodule, by default, writes module.c into the current 106 directory. This does not play nicely with gyp. We patch the 107 source during build to allow specifying a specific output file. 108 109 2) Most of the generated files, even though they are .c files, are 110 #included by other files in the build. Make sure they end up 111 in a directory that is in the include path for the build. 112 One of <(shared_generated_dir) or <(generated_dir) should work. 113 114 3) Some of the genperf output is #included while others need to be 115 compiled directly. That is why there are 2 different rules for 116 .gperf files in two targets. 117 118 9) Check for python scripts that are run. 119 120 grep python yasm_build_log 121 122 Yasm uses python scripts to generate the assembly code description 123 files in C++. Make sure to get these put into the gyp file properly as 124 well. An example is gen_x86_insn.py for x86 assembly. 125 126 Note that at least the gen_x86_insn.py script suffers from the same 127 problem as genmacro in that it outputs to the current directory by 128 default. The yasm.gyp build patches this file before invoking it to 129 allow specifying an output directory. 130 131 10) Recreate the 'AdditionalOptions!': [ '/analyze' ] block so that VC++ 132 /analyze builds won't fail. 133 134 11) If all that's is finished, attempt to build....and cross your fingers. 135
