Lines Matching refs:of

4 This is an informal document about internals of kati. This document is not meant
5 to be a comprehensive document of kati or GNU make. This explains some random
11 The motivation of kati was to speed up Android platform build. Especially, its
13 very unique system. It provides a DSL, (ab)using Turing-completeness of GNU
37 was to hack GNU make instead of developing a clone. We didn't take this option
38 because we thought the source code of GNU make is somewhat complicated due to
39 historical reason. It's written in old-style C, has a lot of ifdefs for some
42 Currently, kati's main mode is --ninja mode. Instead of executing build commands
48 with Go. I guessed at least one of the following statements are true: 1. GNU
51 build system. As for 3, some of such optimization succeeded but it's performance
52 gain didn't cancel the slowness of Go.
55 performance difference in detail, but it seemed both our use of Go and Go
56 language itself were making the Go version of kati slower. As for our fault, I
60 them will be never freed. IIRC, this kind of allocation pattern isn't good for
64 mostly by me. The rest of this document is mostly about the C++ version.
69 Kati consists of the following components:
77 A Makefile has some statements which consist of zero or more expressions. There
81 Most of users of GNU make may not care about the evaluator much. However, GNU
86 build system uses a lot of GNU make black magics.
88 The evaluator outputs a list of build rules and a variable table. The dependency
89 builder creates a dependency graph from the list of build rules. Note this step
104 of this design is for performance. For Android build, kati (or GNU make) needs
106 times. It's waste of time to parse such files again and again. Kati can re-use
111 The statement parser is defined in *parser.cc*. In kati, there are four kinds of
119 Data structures for them are defined in *stmt.h*. Here are examples of these
134 A tricky point of parsing make statements is that the parsing depends on the
135 context of the evaluation. See the following Makefile chunk for example:
148 For some reason, GNU make expands expressions before it decides the type of
158 or other statements depending on the evaluation result of the previous line,
159 sometimes kati's parser cannot tell the statement type of a line. In this case,
167 comments are handled at a very early stage of a language
185 We have a bunch of comment/backslash related testcases in the testcase directory
186 of kati's repository.
191 A statement may have one or more expressions. The number of expressions in a
197 *$(X)*. Types of expressions and their parser are defined in *expr.cc*. Like
198 other programming languages, an expression is a tree of expressions. The type of
207 As a nature of old systems, GNU make is very permissive. For some reason, it
208 allows some kind of unmatched pairs of parentheses. For example, GNU make
220 GNU make has a bunch of functions. Most users would use only simple ones such as
233 kinds of statements:
244 Assignments in GNU make is tricky a bit. There are two kinds of variables in GNU
252 This code outputs "Hello," and "world!", in this order. The evaluation of
254 line, which is an assignment of a recursive variable, outputs nothing. The
255 content of the variable *$(A)* will be *$(info world!)* after the first
258 immediately. So "Hello," will be output and the value of *$(B)* will be an empty
263 There are two more kinds of assignments (i.e., *+=* and *?=*). These assignments
264 keep the type of the original variable. Evaluation of them will be done
265 immediately only when the left hand side of the assignment is already defined
284 are several kinds of rules such as pattern rules, double colon rules, and order
299 the result of expression evaluation, there are some corner cases. A tricky
339 be used even in build commands of prerequisite targets.
363 think there is no valid usage of this feature for non-leaf targets.
366 evaluation of the right hand side of the assignment for recursive variables. Its
367 implementation is very similar to the one for semicolons, but the combination of
376 Evaluation of expressions is done in *expr.cc*, *func.cc*, and
377 *command.cc*. The amount of code for this step is fairly large especially
378 because of the number of GNU make functions. However, their implementations are
381 One tricky function is $(wildcard ...). It seems GNU make is doing some kind of
388 a lot of $(shell find ...) calls to create a list of all .java/.mk files under a
389 directory, and they are slow. For this, kati has a builtin emulator of GNU
391 directory tree. Then the find emulator returns results of find commands using
395 The implementations of some IO-related functions in commands are tricky in the
401 Now we get a list of rules and a variable table. *dep.cc* builds a dependency
402 graph using the list of rules. I think this step is what GNU make is supposed to
406 strange. There are three types of rules in GNU make:
422 In the above example, all of these three rules match the target *foo.o*. GNU
427 Android has more than one thousand implicit rules and there are ten thousands of
482 simple, *$(A)* in *test1* is a recursive variable. This means types of global
483 variables don't affect types of target specific variables. However, The result
484 of *test1* ("X bar") shows the value of a target specific variable is
485 concatenated to the value of a global variable.
490 *ninja.cc* generates a ninja file using the results of other components. This
501 won't work when the result of $(shell ...) is passed to another make
507 should output PASS, because the result of $(shell echo) is an empty string. GNU
523 Kati thinks it needs to regenerate the ninja file when one of the followings is
527 * A timestamp of a Makefile used to generate the previous ninja file
529 * A result of $(wildcard ...)
530 * A result of $(shell ...)
533 $(shell ...) in Android's build system due to the slowness of $(shell find
535 timestamps of traversed directories with the find command itself. For each find
536 commands, kati checks the timestamps of them. If they are not changed, kati
541 latter to create a file and the result of them are empty strings. We don't want
548 but nothing is ready to be used as of writing.