Loading...
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 | ====================== Kconfig macro language ====================== Concept ------- The basic idea was inspired by Make. When we look at Make, we notice sort of two languages in one. One language describes dependency graphs consisting of targets and prerequisites. The other is a macro language for performing textual substitution. There is clear distinction between the two language stages. For example, you can write a makefile like follows:: APP := foo SRC := foo.c CC := gcc $(APP): $(SRC) $(CC) -o $(APP) $(SRC) The macro language replaces the variable references with their expanded form, and handles as if the source file were input like follows:: foo: foo.c gcc -o foo foo.c Then, Make analyzes the dependency graph and determines the targets to be updated. The idea is quite similar in Kconfig - it is possible to describe a Kconfig file like this:: CC := gcc config CC_HAS_FOO def_bool $(shell, $(srctree)/scripts/gcc-check-foo.sh $(CC)) The macro language in Kconfig processes the source file into the following intermediate:: config CC_HAS_FOO def_bool y Then, Kconfig moves onto the evaluation stage to resolve inter-symbol dependency as explained in kconfig-language.rst. Variables --------- Like in Make, a variable in Kconfig works as a macro variable. A macro variable is expanded "in place" to yield a text string that may then be expanded further. To get the value of a variable, enclose the variable name in $( ). The parentheses are required even for single-letter variable names; $X is a syntax error. The curly brace form as in ${CC} is not supported either. There are two types of variables: simply expanded variables and recursively expanded variables. A simply expanded variable is defined using the := assignment operator. Its righthand side is expanded immediately upon reading the line from the Kconfig file. A recursively expanded variable is defined using the = assignment operator. Its righthand side is simply stored as the value of the variable without expanding it in any way. Instead, the expansion is performed when the variable is used. There is another type of assignment operator; += is used to append text to a variable. The righthand side of += is expanded immediately if the lefthand side was originally defined as a simple variable. Otherwise, its evaluation is deferred. The variable reference can take parameters, in the following form:: $(name,arg1,arg2,arg3) You can consider the parameterized reference as a function. (more precisely, "user-defined function" in contrast to "built-in function" listed below). Useful functions must be expanded when they are used since the same function is expanded differently if different parameters are passed. Hence, a user-defined function is defined using the = assignment operator. The parameters are referenced within the body definition with $(1), $(2), etc. In fact, recursively expanded variables and user-defined functions are the same internally. (In other words, "variable" is "function with zero argument".) When we say "variable" in a broad sense, it includes "user-defined function". Built-in functions ------------------ Like Make, Kconfig provides several built-in functions. Every function takes a particular number of arguments. In Make, every built-in function takes at least one argument. Kconfig allows zero argument for built-in functions, such as $(filename), $(lineno). You could consider those as "built-in variable", but it is just a matter of how we call it after all. Let's say "built-in function" here to refer to natively supported functionality. Kconfig currently supports the following built-in functions. - $(shell,command) The "shell" function accepts a single argument that is expanded and passed to a subshell for execution. The standard output of the command is then read and returned as the value of the function. Every newline in the output is replaced with a space. Any trailing newlines are deleted. The standard error is not returned, nor is any program exit status. - $(info,text) The "info" function takes a single argument and prints it to stdout. It evaluates to an empty string. - $(warning-if,condition,text) The "warning-if" function takes two arguments. If the condition part is "y", the text part is sent to stderr. The text is prefixed with the name of the current Kconfig file and the current line number. - $(error-if,condition,text) The "error-if" function is similar to "warning-if", but it terminates the parsing immediately if the condition part is "y". - $(filename) The 'filename' takes no argument, and $(filename) is expanded to the file name being parsed. - $(lineno) The 'lineno' takes no argument, and $(lineno) is expanded to the line number being parsed. Make vs Kconfig --------------- Kconfig adopts Make-like macro language, but the function call syntax is slightly different. A function call in Make looks like this:: $(func-name arg1,arg2,arg3) The function name and the first argument are separated by at least one whitespace. Then, leading whitespaces are trimmed from the first argument, while whitespaces in the other arguments are kept. You need to use a kind of trick to start the first parameter with spaces. For example, if you want to make "info" function print " hello", you can write like follows:: empty := space := $(empty) $(empty) $(info $(space)$(space)hello) Kconfig uses only commas for delimiters, and keeps all whitespaces in the function call. Some people prefer putting a space after each comma delimiter:: $(func-name, arg1, arg2, arg3) In this case, "func-name" will receive " arg1", " arg2", " arg3". The presence of leading spaces may matter depending on the function. The same applies to Make - for example, $(subst .c, .o, $(sources)) is a typical mistake; it replaces ".c" with " .o". In Make, a user-defined function is referenced by using a built-in function, 'call', like this:: $(call my-func,arg1,arg2,arg3) Kconfig invokes user-defined functions and built-in functions in the same way. The omission of 'call' makes the syntax shorter. In Make, some functions treat commas verbatim instead of argument separators. For example, $(shell echo hello, world) runs the command "echo hello, world". Likewise, $(info hello, world) prints "hello, world" to stdout. You could say this is _useful_ inconsistency. In Kconfig, for simpler implementation and grammatical consistency, commas that appear in the $( ) context are always delimiters. It means:: $(shell, echo hello, world) is an error because it is passing two parameters where the 'shell' function accepts only one. To pass commas in arguments, you can use the following trick:: comma := , $(shell, echo hello$(comma) world) Caveats ------- A variable (or function) cannot be expanded across tokens. So, you cannot use a variable as a shorthand for an expression that consists of multiple tokens. The following works:: RANGE_MIN := 1 RANGE_MAX := 3 config FOO int "foo" range $(RANGE_MIN) $(RANGE_MAX) But, the following does not work:: RANGES := 1 3 config FOO int "foo" range $(RANGES) A variable cannot be expanded to any keyword in Kconfig. The following does not work:: MY_TYPE := tristate config FOO $(MY_TYPE) "foo" default y Obviously from the design, $(shell command) is expanded in the textual substitution phase. You cannot pass symbols to the 'shell' function. The following does not work as expected:: config ENDIAN_FLAG string default "-mbig-endian" if CPU_BIG_ENDIAN default "-mlittle-endian" if CPU_LITTLE_ENDIAN config CC_HAS_ENDIAN_FLAG def_bool $(shell $(srctree)/scripts/gcc-check-flag ENDIAN_FLAG) Instead, you can do like follows so that any function call is statically expanded:: config CC_HAS_ENDIAN_FLAG bool default $(shell $(srctree)/scripts/gcc-check-flag -mbig-endian) if CPU_BIG_ENDIAN default $(shell $(srctree)/scripts/gcc-check-flag -mlittle-endian) if CPU_LITTLE_ENDIAN |