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