1 <html><body><pre>Android.mk file syntax specification 2 3 Introduction: 4 ------------- 5 6 This document describes the syntax of Android.mk build file 7 written to describe your C and C++ source files to the Android 8 NDK. To understand what follows, it is assumed that you have 9 read the docs/OVERVIEW.html file that explains their role and 10 usage. 11 12 Overview: 13 --------- 14 15 An Android.mk file is written to describe your sources to the 16 build system. More specifically: 17 18 - The file is really a tiny GNU Makefile fragment that will be 19 parsed one or more times by the build system. As such, you 20 should try to minimize the variables you declare there and 21 do not assume that anything is not defined during parsing. 22 23 - The file syntax is designed to allow you to group your 24 sources into 'modules'. A module is one of the following: 25 26 - a static library 27 - a shared library 28 29 Only shared libraries will be installed/copied to your 30 application package. Static libraries can be used to generate 31 shared libraries though. 32 33 You can define one or more modules in each Android.mk file, 34 and you can use the same source file in several modules. 35 36 - The build system handles many details for you. For example, you 37 don't need to list header files or explicit dependencies between 38 generated files in your Android.mk. The NDK build system will 39 compute these automatically for you. 40 41 This also means that, when updating to newer releases of the NDK, 42 you should be able to benefit from new toolchain/platform support 43 without having to touch your Android.mk files. 44 45 Note that the syntax is *very* close to the one used in Android.mk files 46 distributed with the full open-source Android platform sources. While 47 the build system implementation that uses them is different, this is 48 an intentional design decision made to allow reuse of 'external' libraries' 49 source code easier for application developers. 50 51 Simple example: 52 --------------- 53 54 Before describing the syntax in details, let's consider the simple 55 "hello JNI" example, i.e. the files under: 56 57 apps/hello-jni/project 58 59 Here, we can see: 60 61 - The 'src' directory containing the Java sources for the 62 sample Android project. 63 64 - The 'jni' directory containing the native source for 65 the sample, i.e. 'jni/hello-jni.c' 66 67 This source file implements a simple shared library that 68 implements a native method that returns a string to the 69 VM application. 70 71 - The 'jni/Android.mk' file that describes the shared library 72 to the NDK build system. Its content is: 73 74 ---------- cut here ------------------ 75 LOCAL_PATH := $(call my-dir) 76 77 include $(CLEAR_VARS) 78 79 LOCAL_MODULE := hello-jni 80 LOCAL_SRC_FILES := hello-jni.c 81 82 include $(BUILD_SHARED_LIBRARY) 83 ---------- cut here ------------------ 84 85 Now, let's explain these lines: 86 87 LOCAL_PATH := $(call my-dir) 88 89 An Android.mk file must begin with the definition of the LOCAL_PATH variable. 90 It is used to locate source files in the development tree. In this example, 91 the macro function 'my-dir', provided by the build system, is used to return 92 the path of the current directory (i.e. the directory containing the 93 Android.mk file itself). 94 95 include $(CLEAR_VARS) 96 97 The CLEAR_VARS variable is provided by the build system and points to a 98 special GNU Makefile that will clear many LOCAL_XXX variables for you 99 (e.g. LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES, etc...), 100 with the exception of LOCAL_PATH. This is needed because all build 101 control files are parsed in a single GNU Make execution context where 102 all variables are global. 103 104 LOCAL_MODULE := hello-jni 105 106 The LOCAL_MODULE variable must be defined to identify each module you 107 describe in your Android.mk. The name must be *unique* and not contain 108 any spaces. Note that the build system will automatically add proper 109 prefix and suffix to the corresponding generated file. In other words, 110 a shared library module named 'foo' will generate 'libfoo.so'. 111 112 IMPORTANT NOTE: 113 If you name your module 'libfoo', the build system will not 114 add another 'lib' prefix and will generate libfoo.so as well. 115 This is to support Android.mk files that originate from the 116 Android platform sources, would you need to use these. 117 118 LOCAL_SRC_FILES := hello-jni.c 119 120 The LOCAL_SRC_FILES variables must contain a list of C and/or C++ source 121 files that will be built and assembled into a module. Note that you should 122 not list header and included files here, because the build system will 123 compute dependencies automatically for you; just list the source files 124 that will be passed directly to a compiler, and you should be good. 125 126 Note that the default extension for C++ source files is '.cpp'. It is 127 however possible to specify a different one by defining the variable 128 LOCAL_CPP_EXTENSION. Don't forget the initial dot (i.e. '.cxx' will 129 work, but not 'cxx'). 130 131 include $(BUILD_SHARED_LIBRARY) 132 133 The BUILD_SHARED_LIBRARY is a variable provided by the build system that 134 points to a GNU Makefile script that is in charge of collecting all the 135 information you defined in LOCAL_XXX variables since the latest 136 'include $(CLEAR_VARS)' and determine what to build, and how to do it 137 exactly. There is also BUILD_STATIC_LIBRARY to generate a static library. 138 139 There are more complex examples in the samples directories, with commented 140 Android.mk files that you can look at. 141 142 Reference: 143 ---------- 144 145 This is the list of variables you should either rely on or define in 146 an Android.mk. You can define other variables for your own usage, but 147 the NDK build system reserves the following variable names: 148 149 - names that begin with LOCAL_ (e.g. LOCAL_MODULE) 150 - names that begin with PRIVATE_, NDK_ or APP_ (used internally) 151 - lower-case names (used internally, e.g. 'my-dir') 152 153 If you need to define your own convenience variables in an Android.mk 154 file, we recommend using the MY_ prefix, for a trivial example: 155 156 ---------- cut here ------------------ 157 MY_SOURCES := foo.c 158 ifneq ($(MY_CONFIG_BAR),) 159 MY_SOURCES += bar.c 160 endif 161 162 LOCAL_SRC_FILES += $(MY_SOURCES) 163 ---------- cut here ------------------ 164 165 So, here we go: 166 167 168 NDK-provided variables: 169 - - - - - - - - - - - - 170 171 These GNU Make variables are defined by the build system before 172 your Android.mk file is parsed. Note that under certain circumstances 173 the NDK might parse your Android.mk several times, each with different 174 definition for some of these variables. 175 176 CLEAR_VARS 177 Points to a build script that undefines nearly all LOCAL_XXX variables 178 listed in the "Module-description" section below. You must include 179 the script before starting a new module, e.g.: 180 181 include $(CLEAR_VARS) 182 183 BUILD_SHARED_LIBRARY 184 Points to a build script that collects all the information about the 185 module you provided in LOCAL_XXX variables and determines how to build 186 a target shared library from the sources you listed. Note that you 187 must have LOCAL_MODULE and LOCAL_SRC_FILES defined, at a minimum before 188 including this file. Example usage: 189 190 include $(BUILD_SHARED_LIBRARY) 191 192 note that this will generate a file named lib$(LOCAL_MODULE).so 193 194 BUILD_STATIC_LIBRARY 195 A variant of BUILD_SHARED_LIBRARY that is used to build a target static 196 library instead. Static libraries are not copied into your 197 project/packages but can be used to build shared libraries (see 198 LOCAL_STATIC_LIBRARIES and LOCAL_STATIC_WHOLE_LIBRARIES described below). 199 Example usage: 200 201 include $(BUILD_STATIC_LIBRARY) 202 203 Note that this will generate a file named lib$(LOCAL_MODULE).a 204 205 PREBUILT_SHARED_LIBRARY 206 Points to a build script used to specify a prebuilt shared library. 207 Unlike BUILD_SHARED_LIBRARY and BUILD_STATIC_LIBRARY, the value 208 of LOCAL_SRC_FILES must be a single path to a prebuilt shared 209 library (e.g. foo/libfoo.so), instead of a source file. 210 211 You can reference the prebuilt library in another module using 212 the LOCAL_PREBUILTS variable (see docs/PREBUILTS.html for more 213 information). 214 215 PREBUILT_STATIC_LIBRARY 216 This is the same as PREBUILT_SHARED_LIBRARY, but for a static library 217 file instead. See docs/PREBUILTS.html for more. 218 219 TARGET_ARCH 220 Name of the target CPU architecture as it is specified by the 221 full Android open-source build. This is 'arm' for any ARM-compatible 222 build, independent of the CPU architecture revision. 223 224 TARGET_PLATFORM 225 Name of the target Android platform when this Android.mk is parsed. 226 For example, 'android-3' correspond to Android 1.5 system images. For 227 a complete list of platform names and corresponding Android system 228 images, read docs/STABLE-APIS.html. 229 230 TARGET_ARCH_ABI 231 Name of the target CPU+ABI when this Android.mk is parsed. 232 Two values are supported at the moment: 233 234 armeabi 235 For Armv5TE 236 237 armeabi-v7a 238 239 NOTE: Up to Android NDK 1.6_r1, this variable was simply defined 240 as 'arm'. However, the value has been redefined to better 241 match what is used internally by the Android platform. 242 243 For more details about architecture ABIs and corresponding 244 compatibility issues, please read docs/CPU-ARCH-ABIS.html 245 246 Other target ABIs will be introduced in future releases of the NDK 247 and will have a different name. Note that all ARM-based ABIs will 248 have 'TARGET_ARCH' defined to 'arm', but may have different 249 'TARGET_ARCH_ABI' 250 251 TARGET_ABI 252 The concatenation of target platform and abi, it really is defined 253 as $(TARGET_PLATFORM)-$(TARGET_ARCH_ABI) and is useful when you want 254 to test against a specific target system image for a real device. 255 256 By default, this will be 'android-3-armeabi' 257 258 (Up to Android NDK 1.6_r1, this used to be 'android-3-arm' by default) 259 260 NDK-provided function macros: 261 - - - - - - - - - - - - - - - 262 263 The following are GNU Make 'function' macros, and must be evaluated 264 by using '$(call <function>)'. They return textual information. 265 266 my-dir 267 Returns the path of the last included Makefile, which typically is 268 the current Android.mk's directory. This is useful to define 269 LOCAL_PATH at the start of your Android.mk as with: 270 271 LOCAL_PATH := $(call my-dir) 272 273 IMPORTANT NOTE: Due to the way GNU Make works, this really returns 274 the path of the *last* *included* *Makefile* during the parsing of 275 build scripts. Do not call my-dir after including another file. 276 277 For example, consider the following example: 278 279 LOCAL_PATH := $(call my-dir) 280 281 ... declare one module 282 283 include $(LOCAL_PATH)/foo/Android.mk 284 285 LOCAL_PATH := $(call my-dir) 286 287 ... declare another module 288 289 The problem here is that the second call to 'my-dir' will define 290 LOCAL_PATH to $PATH/foo instead of $PATH, due to the include that 291 was performed before that. 292 293 For this reason, it's better to put additional includes after 294 everything else in an Android.mk, as in: 295 296 LOCAL_PATH := $(call my-dir) 297 298 ... declare one module 299 300 LOCAL_PATH := $(call my-dir) 301 302 ... declare another module 303 304 # extra includes at the end of the Android.mk 305 include $(LOCAL_PATH)/foo/Android.mk 306 307 If this is not convenient, save the value of the first my-dir call 308 into another variable, for example: 309 310 MY_LOCAL_PATH := $(call my-dir) 311 312 LOCAL_PATH := $(MY_LOCAL_PATH) 313 314 ... declare one module 315 316 include $(LOCAL_PATH)/foo/Android.mk 317 318 LOCAL_PATH := $(MY_LOCAL_PATH) 319 320 ... declare another module 321 322 323 324 all-subdir-makefiles 325 Returns a list of Android.mk located in all sub-directories of 326 the current 'my-dir' path. For example, consider the following 327 hierarchy: 328 329 sources/foo/Android.mk 330 sources/foo/lib1/Android.mk 331 sources/foo/lib2/Android.mk 332 333 If sources/foo/Android.mk contains the single line: 334 335 include $(call all-subdir-makefiles) 336 337 Then it will include automatically sources/foo/lib1/Android.mk and 338 sources/foo/lib2/Android.mk 339 340 This function can be used to provide deep-nested source directory 341 hierarchies to the build system. Note that by default, the NDK 342 will only look for files in sources/*/Android.mk 343 344 this-makefile 345 Returns the path of the current Makefile (i.e. where the function 346 is called). 347 348 parent-makefile 349 Returns the path of the parent Makefile in the inclusion tree, 350 i.e. the path of the Makefile that included the current one. 351 352 grand-parent-makefile 353 Guess what... 354 355 import-module 356 A function that allows you to find and include the Android.mk 357 of another module by name. A typical example is: 358 359 $(call import-module,<name>) 360 361 And this will look for the module tagged <name> in the list of 362 directories referenced by your NDK_MODULE_PATH environment 363 variable, and include its Android.mk automatically for you. 364 365 Read docs/IMPORT-MODULE.html for more details. 366 367 Module-description variables: 368 - - - - - - - - - - - - - - - 369 370 The following variables are used to describe your module to the build 371 system. You should define some of them between an 'include $(CLEAR_VARS)' 372 and an 'include $(BUILD_XXXXX)'. As written previously, $(CLEAR_VARS) is 373 a script that will undefine/clear all of these variables, unless explicitly 374 noted in their description. 375 376 LOCAL_PATH 377 This variable is used to give the path of the current file. 378 You MUST define it at the start of your Android.mk, which can 379 be done with: 380 381 LOCAL_PATH := $(call my-dir) 382 383 This variable is *not* cleared by $(CLEAR_VARS) so only one 384 definition per Android.mk is needed (in case you define several 385 modules in a single file). 386 387 LOCAL_MODULE 388 This is the name of your module. It must be unique among all 389 module names, and shall not contain any space. You MUST define 390 it before including any $(BUILD_XXXX) script. 391 392 By default, the module name determines the name of generated files, 393 e.g. lib<foo>.so for a shared library module named <foo>. However 394 you should only refer to other modules with their 'normal' 395 name (e.g. <foo>) in your NDK build files (either Android.mk 396 or Application.mk) 397 398 You can override this default with LOCAL_MODULE_FILENAME (see below) 399 400 LOCAL_MODULE_FILENAME 401 This variable is optional, and allows you to redefine the name of 402 generated files. By default, module <foo> will always generate a 403 static library named lib<foo>.a or a shared library named lib<foo>.so, 404 which are standard Unix conventions. 405 406 You can override this by defining LOCAL_MODULE_FILENAME, For example: 407 408 LOCAL_MODULE := foo-version-1 409 LOCAL_MODULE_FILENAME := libfoo 410 411 NOTE: You should not put a path or file extension in your 412 LOCAL_MODULE_FILENAME, these will be handled automatically by the 413 build system. 414 415 LOCAL_SRC_FILES 416 This is a list of source files that will be built for your module. 417 Only list the files that will be passed to a compiler, since the 418 build system automatically computes dependencies for you. 419 420 Note that source files names are all relative to LOCAL_PATH and 421 you can use path components, e.g.: 422 423 LOCAL_SRC_FILES := foo.c \ 424 toto/bar.c 425 426 NOTE: Always use Unix-style forward slashes (/) in build files. 427 Windows-style back-slashes will not be handled properly. 428 429 LOCAL_CPP_EXTENSION 430 This is an optional variable that can be defined to indicate 431 the file extension of C++ source files. The default is '.cpp' 432 but you can change it. For example: 433 434 LOCAL_CPP_EXTENSION := .cxx 435 436 LOCAL_C_INCLUDES 437 An optional list of paths, relative to the NDK *root* directory, 438 which will be appended to the include search path when compiling 439 all sources (C, C++ and Assembly). For example: 440 441 LOCAL_C_INCLUDES := sources/foo 442 443 Or even: 444 445 LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo 446 447 These are placed before any corresponding inclusion flag in 448 LOCAL_CFLAGS / LOCAL_CPPFLAGS 449 450 The LOCAL_C_INCLUDES path are also used automatically when 451 launching native debugging with ndk-gdb. 452 453 454 LOCAL_CFLAGS 455 An optional set of compiler flags that will be passed when building 456 C *and* C++ source files. 457 458 This can be useful to specify additional macro definitions or 459 compile options. 460 461 IMPORTANT: Try not to change the optimization/debugging level in 462 your Android.mk, this can be handled automatically for 463 you by specifying the appropriate information in 464 your Application.mk, and will let the NDK generate 465 useful data files used during debugging. 466 467 NOTE: In android-ndk-1.5_r1, the corresponding flags only applied 468 to C source files, not C++ ones. This has been corrected to 469 match the full Android build system behaviour. (You can use 470 LOCAL_CPPFLAGS to specify flags for C++ sources only now). 471 472 It is possible to specify additional include paths with 473 LOCAL_CFLAGS += -I<path>, however, it is better to use LOCAL_C_INCLUDES 474 for this, since the paths will then also be used during native 475 debugging with ndk-gdb. 476 477 478 LOCAL_CXXFLAGS 479 An alias for LOCAL_CPPFLAGS. Note that use of this flag is obsolete 480 as it may disappear in future releases of the NDK. 481 482 LOCAL_CPPFLAGS 483 An optional set of compiler flags that will be passed when building 484 C++ source files *only*. They will appear after the LOCAL_CFLAGS 485 on the compiler's command-line. 486 487 NOTE: In android-ndk-1.5_r1, the corresponding flags applied to 488 both C and C++ sources. This has been corrected to match the 489 full Android build system. (You can use LOCAL_CFLAGS to specify 490 flags for both C and C++ sources now). 491 492 LOCAL_STATIC_LIBRARIES 493 The list of static libraries modules (built with BUILD_STATIC_LIBRARY) 494 that should be linked to this module. This only makes sense in 495 shared library modules. 496 497 LOCAL_SHARED_LIBRARIES 498 The list of shared libraries *modules* this module depends on at runtime. 499 This is necessary at link time and to embed the corresponding information 500 in the generated file. 501 502 LOCAL_LDLIBS 503 The list of additional linker flags to be used when building your 504 module. This is useful to pass the name of specific system libraries 505 with the "-l" prefix. For example, the following will tell the linker 506 to generate a module that links to /system/lib/libz.so at load time: 507 508 LOCAL_LDLIBS := -lz 509 510 See docs/STABLE-APIS.html for the list of exposed system libraries you 511 can linked against with this NDK release. 512 513 LOCAL_ALLOW_UNDEFINED_SYMBOLS 514 By default, any undefined reference encountered when trying to build 515 a shared library will result in an "undefined symbol" error. This is a 516 great help to catch bugs in your source code. 517 518 However, if for some reason you need to disable this check, set this 519 variable to 'true'. Note that the corresponding shared library may fail 520 to load at runtime. 521 522 LOCAL_ARM_MODE 523 By default, ARM target binaries will be generated in 'thumb' mode, where 524 each instruction are 16-bit wide. You can define this variable to 'arm' 525 if you want to force the generation of the module's object files in 526 'arm' (32-bit instructions) mode. E.g.: 527 528 LOCAL_ARM_MODE := arm 529 530 Note that you can also instruct the build system to only build specific 531 sources in arm mode by appending an '.arm' suffix to its source file 532 name. For example, with: 533 534 LOCAL_SRC_FILES := foo.c bar.c.arm 535 536 Tells the build system to always compile 'bar.c' in arm mode, and to 537 build foo.c according to the value of LOCAL_ARM_MODE. 538 539 NOTE: Setting APP_OPTIM to 'debug' in your Application.mk will also force 540 the generation of ARM binaries as well. This is due to bugs in the 541 toolchain debugger that don't deal too well with thumb code. 542 543 LOCAL_ARM_NEON 544 Defining this variable to 'true' allows the use of ARM Advanced SIMD 545 (a.k.a. NEON) GCC intrinsics in your C and C++ sources, as well as 546 NEON instructions in Assembly files. 547 548 You should only define it when targetting the 'armeabi-v7a' ABI that 549 corresponds to the ARMv7 instruction set. Note that not all ARMv7 550 based CPUs support the NEON instruction set extensions and that you 551 should perform runtime detection to be able to use this code at runtime 552 safely. To lean more about this, please read the documentation at 553 docs/CPU-ARM-NEON.html and docs/CPU-FEATURES.html. 554 555 Alternatively, you can also specify that only specific source files 556 may be compiled with NEON support by using the '.neon' suffix, as 557 in: 558 559 LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon 560 561 In this example, 'foo.c' will be compiled in thumb+neon mode, 562 'bar.c' will be compiled in 'thumb' mode, and 'zoo.c' will be 563 compiled in 'arm+neon' mode. 564 565 Note that the '.neon' suffix must appear after the '.arm' suffix 566 if you use both (i.e. foo.c.arm.neon works, but not foo.c.neon.arm !) 567 568 LOCAL_DISABLE_NO_EXECUTE 569 Android NDK r4 added support for the "NX bit" security feature. 570 It is enabled by default, but you can disable it if you *really* 571 need to by setting this variable to 'true'. 572 573 NOTE: This feature does not modify the ABI and is only enabled on 574 kernels targetting ARMv6+ CPU devices. Machine code generated 575 with this feature enabled will run unmodified on devices 576 running earlier CPU architectures. 577 578 For more information, see: 579 580 http://en.wikipedia.org/wiki/NX_bit 581 http://www.gentoo.org/proj/en/hardened/gnu-stack.xml 582 583 LOCAL_EXPORT_CFLAGS 584 Define this variable to record a set of C/C++ compiler flags that will 585 be added to the LOCAL_CFLAGS definition of any other module that uses 586 this one with LOCAL_STATIC_LIBRARIES or LOCAL_SHARED_LIBRARIES. 587 588 For example, consider the module 'foo' with the following definition: 589 590 include $(CLEAR_VARS) 591 LOCAL_MODULE := foo 592 LOCAL_SRC_FILES := foo/foo.c 593 LOCAL_EXPORT_CFLAGS := -DFOO=1 594 include $(BUILD_STATIC_LIBRARY) 595 596 And another module, named 'bar' that depends on it as: 597 598 include $(CLEAR_VARS) 599 LOCAL_MODULE := bar 600 LOCAL_SRC_FILES := bar.c 601 LOCAL_CFLAGS := -DBAR=2 602 LOCAL_STATIC_LIBRARIES := foo 603 include $(BUILD_SHARED_LIBRARY) 604 605 Then, the flags '-DFOO=1 -DBAR=2' will be passed to the compiler when 606 building bar.c 607 608 Exported flags are prepended to your module's LOCAL_CFLAGS so you can 609 easily override them. They are also transitive: if 'zoo' depends on 610 'bar' which depends on 'foo', then 'zoo' will also inherit all flags 611 exported by 'foo'. 612 613 Finally, exported flags are *not* used when building the module that 614 exports them. In the above example, -DFOO=1 would not be passed to the 615 compiler when building foo/foo.c. 616 617 LOCAL_EXPORT_CPPFLAGS 618 Same as LOCAL_EXPORT_CFLAGS, but for C++ flags only. 619 620 LOCAL_EXPORT_C_INCLUDES 621 Same as LOCAL_EXPORT_CFLAGS, but for C include paths. 622 This can be useful if 'bar.c' wants to include headers 623 that are provided by module 'foo'. 624 625 LOCAL_EXPORT_LDLIBS 626 Same as LOCAL_EXPORT_CFLAGS, but for linker flags. Note that the 627 imported linker flags will be appended to your module's LOCAL_LDLIBS 628 though, due to the way Unix linkers work. 629 630 This is typically useful when module 'foo' is a static library and has 631 code that depends on a system library. LOCAL_EXPORT_LDLIBS can then be 632 used to export the dependency. For example: 633 634 include $(CLEAR_VARS) 635 LOCAL_MODULE := foo 636 LOCAL_SRC_FILES := foo/foo.c 637 LOCAL_EXPORT_LDLIBS := -llog 638 include $(BUILD_STATIC_LIBRARY) 639 640 include $(CLEAR_VARS) 641 LOCAL_MODULE := bar 642 LOCAL_SRC_FILES := bar.c 643 LOCAL_STATIC_LIBRARIES := foo 644 include $(BUILD_SHARED_LIBRARY) 645 646 There, libbar.so will be built with a -llog at the end of the linker 647 command to indicate that it depends on the system logging library, 648 because it depends on 'foo'. 649 650 LOCAL_FILTER_ASM 651 Define this variable to a shell command that will be used to filter 652 the assembly files from, or generated from, your LOCAL_SRC_FILES. 653 654 When it is defined, the following happens: 655 656 - Any C or C++ source file is generated into a temporary assembly 657 file (instead of being compiled into an object file). 658 659 - Any temporary assembly file, and any assembly file listed in 660 LOCAL_SRC_FILES is sent through the LOCAL_FILTER_ASM command 661 to generate _another_ temporary assembly file. 662 663 - These filtered assembly files are compiled into object file. 664 665 In other words, If you have: 666 667 LOCAL_SRC_FILES := foo.c bar.S 668 LOCAL_FILTER_ASM := myasmfilter 669 670 foo.c --1--> $OBJS_DIR/foo.S.original --2--> $OBJS_DIR/foo.S --3--> $OBJS_DIR/foo.o 671 bar.S --2--> $OBJS_DIR/bar.S --3--> $OBJS_DIR/bar.o 672 673 Were "1" corresponds to the compiler, "2" to the filter, and "3" to the 674 assembler. The filter must be a standalone shell command that takes the 675 name of the input file as its first argument, and the name of the output 676 file as the second one, as in: 677 678 myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S 679 myasmfilter bar.S $OBJS_DIR/bar.S 680 </pre></body></html>
