summaryrefslogtreecommitdiffstats
path: root/core/envsetup.mk
Commit message (Collapse)AuthorAgeFilesLines
* Permit redirection of vendor to systemSam Mortimer2015-11-161-2/+2
| | | | | | | | | | | For devices where /system/vendor needs to be a symlink to /vendor. This allows a target to set TARGET_COPY_OUT_VENDOR := system in order to force modules that want to be placed in vendor to instead be redirected into /system. eg angler Change-Id: I4bffcefcda0b33dc5350b1702ec6d0166b18d775
* envsetup: use $(CURDIR) for getting current directoryChirayu Desai2015-10-061-1/+1
| | | | Change-Id: I5f00faf64ec31d86dd2e48ec038748ce8499380b
* build: work around missing readlink -f on MacDavid Ferguson2015-10-061-1/+1
| | | | Change-Id: I5d56366cf33a2b02f1886c87815d00cff279779d
* envsetup: set OUT_DIR to an absolute path alwaysChirayu Desai2015-10-061-0/+4
| | | | | | | | | | | | | | | OUT_DIR was set to $(TOPDIR)out previously, but $(TOPDIR) was null, so it was a relative path. This broke releasetools, inline kernel building, etc since they require absolute paths. Fix it so that it is set to $(shell readlink -f .)/out if $(TOPDIR) is null. Also remove hacks which checked if (OUT_DIR) was out and changed it to $(ANDROID_BUILD_TOP)/out to workaround the aforementioned problem. Change-Id: I459a3b1325a1bbea0565cd73f6acf160d4ed9b39
* am 540772fa: am cf469989: Add new variable SCAN_EXCLUDE_DIRS; specifies ↵C. Sean Young2015-06-121-0/+5
|\ | | | | | | | | | | | | directories to exclude when searching source tree. * commit '540772fa2287e63a0c745229fb72b78903c9cd70': Add new variable SCAN_EXCLUDE_DIRS; specifies directories to exclude when searching source tree.
| * Add new variable SCAN_EXCLUDE_DIRS; specifies directories to exclude when ↵C. Sean Young2015-06-101-0/+5
| | | | | | | | | | | | | | | | | | | | searching source tree. These directories are excluded in addition to OUT_DIR. This can be useful if your build system has other output directories beyond what OUT_DIR is set to. Change-Id: I6d98a85bcc8c89279e939406a7fec32547e8922f
* | am b7fe2e62: am f7683b81: Merge "Clearly explain that 32-bit x86 is not ↵Brian Carlstrom2015-03-201-0/+4
|\ \ | | | | | | | | | | | | | | | | | | supported" * commit 'b7fe2e622d7a6a696749d5441358b84569de6f75': Clearly explain that 32-bit x86 is not supported
| * | Clearly explain that 32-bit x86 is not supportedBrian Carlstrom2015-03-201-0/+4
| | | | | | | | | | | | Change-Id: I7f352fae8fa3742c61dc74e20aacd32254451bce
* | | am 4cbc4b39: am ae61f50a: Support to configure and build multiple custom images.Ying Wang2015-03-141-1/+16
|\ \ \ | |/ / |/| / | |/ | | * commit '4cbc4b392da57c34626af38a4ea0fe4dc115af57': Support to configure and build multiple custom images.
| * Support to configure and build multiple custom images.Ying Wang2015-03-141-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Build additional images requested by the product makefile. This script gives the ability to build multiple additional images and you can configure what modules/files to include in each image. 1. Define PRODUCT_CUSTOM_IMAGE_MAKEFILES in your product makefile. PRODUCT_CUSTOM_IMAGE_MAKEFILES is a list of makefiles. Each makefile configures an image. For image configuration makefile foo/bar/xyz.mk, the built image file name will be xyz.img. So make sure they won't conflict. 2. In each image's configuration makefile, you can define variables: - CUSTOM_IMAGE_MOUNT_POINT, the mount point, such as "oem", "odm" etc. - CUSTOM_IMAGE_PARTITION_SIZE - CUSTOM_IMAGE_FILE_SYSTEM_TYPE - CUSTOM_IMAGE_DICT_FILE, a text file defining a dictionary accepted by BuildImage() in tools/releasetools/build_image.py. - CUSTOM_IMAGE_MODULES, a list of module names you want to include in the image; Not only the module itself will be installed to proper path in the image, you can also piggyback additional files/directories with the module's LOCAL_PICKUP_FILES. - CUSTOM_IMAGE_COPY_FILES, a list of "<src>:<dest>" to be copied to the image. <dest> is relativ to the root of the image. To build all those images, run "make custom_images". Bug: 19609718 Change-Id: Ic73587e08503a251be27797c7b00329716051927 (cherry picked from commit 5fcf1094f9cf4d57c2598237f99621f254130d71)
| * Fix HOST_LIBRARY_PATH.Ying Wang2014-08-141-1/+5
| | | | | | | | | | | | | | Since we switched to $(HOST_OUT)/lib64 for 64-bit libraries and $(HOST_OUT)/lib for 32-bit libraries. Change-Id: Ie43bc03c37e2ac8542412a7543a6af5d60c6f725
* | Remove support of factory ramdisk/bundle.Ying Wang2015-02-041-2/+0
| | | | | | | | | | Bug: 18779515 Change-Id: Ia6d51d43965447e2e95944a7d2b4b41adb121cb7
* | am 80ff45ba: am 0850330c: Merge "Default host module to 64-bit except for ↵Ying Wang2014-09-021-13/+11
|\ \ | | | | | | | | | | | | | | | | | | SDK builds." * commit '80ff45ba98922b56ca70cc39fdb530482d366684': Default host module to 64-bit except for SDK builds.
| * | Default host module to 64-bit except for SDK builds.Ying Wang2014-09-021-13/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | Set "HOST_PREFER_32_BIT := true" only if "sdk" or "win_sdk" is among the make command line goals, or it's a MinGW windows build, which only builds host SDK tools. Bug: 13751317 Change-Id: I8ec1a97a5d1af065a153b16523c2ee3434d0dd71
* | | am 798c8430: am 3c6e4910: Merge "Fix HOST_LIBRARY_PATH."Ying Wang2014-08-141-1/+5
|\ \ \ | |/ / | | | | | | | | | * commit '798c8430d5d5389e15379d64119dfc75cfc61ff8': Fix HOST_LIBRARY_PATH.
| * | Fix HOST_LIBRARY_PATH.Ying Wang2014-08-141-1/+5
| | | | | | | | | | | | | | | | | | | | | Since we switched to $(HOST_OUT)/lib64 for 64-bit libraries and $(HOST_OUT)/lib for 32-bit libraries. Change-Id: Ie43bc03c37e2ac8542412a7543a6af5d60c6f725
* | | am 8ac188ff: am 6dbbb159: Merge "Consistent use of USE_MINGW"Ying Wang2014-08-081-1/+1
|\ \ \ | |/ / | | / | |/ |/| * commit '8ac188ff0e739ea75ea02166c54428245200f088': Consistent use of USE_MINGW
| * Consistent use of USE_MINGWYing Wang2014-08-071-1/+1
| | | | | | | | Change-Id: I05e212e5a99639d0196006b9c2ec35072c54f399
* | Support to set up TARGET_COPY_OUT_VENDOR in board config.Ying Wang2014-07-231-3/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | We first define TARGET_COPY_OUT_VENDOR as a placeholder. In product config makefiiles we actually get the placeholders in PRODUCT_COPY_FILES. A device can set up TARGET_COPY_OUT_VENDOR in its BoardConfig.mk. We substitute the placeholder with the real TARGET_COPY_OUT_VENDOR value after loading the BoardConfig.mk. With this change, we can support building vendor stuff to system.img (the default) or a separate vendor.img. Bug: 16515152 Change-Id: I5b601d7a8b34fe032a1bac02aa5c204a3765691d
* | am d3b5d574: am ce40d5f9: am bc7501e1: Merge "More consistent use of 64-bit ↵Ying Wang2014-07-091-13/+11
|\ \ | |/ | | | | | | | | | | build variable." * commit 'd3b5d574defd565d6e810cbb86e3943837f94065': More consistent use of 64-bit build variable.
| * More consistent use of 64-bit build variable.Ying Wang2014-07-081-13/+11
| | | | | | | | | | | | | | | | Set up TARGET_IS_64_BIT and HOST_IS_64_BIT early so we don't need 2 mechanisms to judge if it's 64-bit build; Remove the unnecessary 32-bit host variables. Change-Id: I08d6d4d9ea70f91135fe2ee05463fb9a0d1cee42
* | am 0d0b7b36: am 2530c787: am 4b539d15: Merge "More consistent host library ↵Ying Wang2014-07-011-6/+4
|\ \ | |/ | | | | | | | | | | path in multilib build." * commit '0d0b7b3669d3cb309ddd26cf23ddddbe4d42fd8e': More consistent host library path in multilib build.
| * More consistent host library path in multilib build.Ying Wang2014-06-301-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 64-bit multilib host build, changed from 32-bit lib: out/host/<platform>/lib32 64-bit lib: out/host/<platform>/lib to 32-bit lib: out/host/<platform>/lib 64-bit lib: out/host/<platform>/lib64 . That way the host library path is consistent with the multilib target build's. Also with this change prebuilt 32-bit libraries can be reused in 64-bit host build as 2nd arch binaries. (With previous setup, they can't be used because they have rpath ../lib in it while the 2nd arch library path needs ../lib32. Change-Id: I020199d0c7dd52cdc8dcb7d3a1d22cd6178672e1
* | build: fix vendor symbols in gdbColin Cross2014-06-271-0/+1
| | | | | | | | | | | | | | Set TARGET_OUT_VENDOR_SHARED_LIBRARIES_UNSTRIPPED Append '64' for 64-bit libraries Change-Id: Ief289bb23950d4bed84cf616cff6038fbd8caf95
* | Set up oem.img directory structure for TARGET_2ND_ARCH.Ying Wang2014-06-261-3/+11
| | | | | | | | Change-Id: Ia931a10708225c428b658cb4a30e8bba66fa7308
* | am 0d276266: am 128cd1b7: am 6cc4598d: Merge "Add global variable ↵Ying Wang2014-06-111-2/+5
|\ \ | |/ | | | | | | | | | | HOST_LIBRARY_PATH." * commit '0d27626620676dbe72bf5c020008bb2dad20d75f': Add global variable HOST_LIBRARY_PATH.
| * Add global variable HOST_LIBRARY_PATH.Ying Wang2014-06-101-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | With multilib host build, the build system installs host shared libraries to different directories depending on a library's bitness: - HOST_OUT_SHARED_LIBRARIES points to the library path of 64-bit; - 2ND_HOST_OUT_SHARED_LIBRARIES points to the library path of 32-bit; - If you don't care the bitness of the libraries and just want whatever version the librareies are built by default, use HOST_LIBRARY_PATH. Bug:13751317 Change-Id:Id4c818941dc4ea35d795767c76f698529bd6aebb
* | am 2d19cbd2: resolved conflicts for merge of 135e11df to ↵Ying Wang2014-06-111-10/+14
|\ \ | |/ | | | | | | | | | | klp-modular-dev-plus-aosp * commit '2d19cbd279ed69c7202f089be174c35c1585f709': Switch to 32-bit-by-default host multilib build.
| * Switch to 32-bit-by-default host multilib build.Ying Wang2014-06-091-10/+14
| | | | | | | | | | | | | | | | Also we don't need to force LLVM built from source, for we already force LLVM to be built as 32-bit. Bug: 13751317 Change-Id: Ifadf1988d28b60cb06316de50f5bdc1834f1acc0
* | am 2bf10a72: am cdcb6926: am 6cb69bd4: Merge "Add HOST_PREFER_32_BIT to ↵Ying Wang2014-05-231-0/+10
|\ \ | |/ | | | | | | | | | | support 32-bit-by-default multilib build" * commit '2bf10a72f87a8e97923286aa331f7db81e2361ca': Add HOST_PREFER_32_BIT to support 32-bit-by-default multilib build
| * Add HOST_PREFER_32_BIT to support 32-bit-by-default multilib buildYing Wang2014-05-201-0/+10
| | | | | | | | | | | | | | | | | | | | We already support pure 32-bit and 64-bit-by-default multilib build. With HOST_PREFER_32_BIT we can build 32-bit-by-default multilib build. This will be lest disruptive during the period we transition to 64-bit-by-default. Bug: 13751317 Change-Id: I0d56ce4abbe4afeaacfd70d709f6a349791c0722
* | am e50f2d9f: am 40b49d30: am a74ade94: Merge "Support host multilib build"Ying Wang2014-05-151-15/+36
|\ \ | |/ | | | | | | * commit 'e50f2d9f32a27d8290692dbf99ab8b247ef9d553': Support host multilib build
| * Support host multilib buildYing Wang2014-05-141-15/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change basically ported our target multilib to the host side. It supports 2 host build modes: x86 and x86_64 multilib build. For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64 multilib build. Later we'll default to x86_64 build and have a flag to force 32-bit only build, which may be needed by SDK build. In host module definition, like in target ones, you can use the following LOCAL variables to set up multilib configuration: LOCAL_MULTILIB: can be "both", "first", "32" or "64". It also supports the same set of arch or 32-vs-64 specific LOCAL variables. By default, it builds only for the first arch. To keep path compatibility, in x86_64 build files are still output to out/host/linux-x86; Both 32-bit and 64-bit executables are in out/host/linux-86/bin; In x86_64 build 32-bit shared libraries are installed to out/host/linux-x86/lib32 and 64-bit shared libraries are installed to out/host/linux-x86/lib; 32-bit object files are output to out/host/linux-x86/obj32 and 64-bit object files are output to out/host/linux-x86/obj. Bug: 13751317 Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
* | Set up rules to build oem.imgYing Wang2014-04-281-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | To build oem.img: - You must define BOARD_OEMIMAGE_PARTITION_SIZE in your BoardConfig.mk - The file system type will be the same as system.img and userdata.img. - To install a module to oem.img, use "LOCAL_OEM_MODULE := true" - run "make -j48 showcommands oem_image dist". By default it's not built. Bug: 13367676 Change-Id: I1a26d4d0c61b72ecffe60279667b1b3de050780d
* | resolved conflicts for merge of 8af7e8ed to masterNarayan Kamath2014-04-091-22/+0
|\ \ | |/ | | | | Change-Id: Ib427b36e133e29d1c2e9cea065e4e63c1e2e2122
| * Add 32 / 64 bit abi lists to system properties.Narayan Kamath2014-04-081-22/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce ro.product.cpu.abilist32 / abilist64, which are comma separated lists of the 32 and 64 bit ABIs that the device supports. These properties are used by the zygote and system server to determine what ABI an app should be started with. This changes move abilist related make steps out of envsetup.mk and into config.mk because they depend on variables set by core/combo/***. Additionally, config.mk performs a few additional cleanups of these variables (like stripping them) after the inclusion of envsetup.mk so this seems like a better place to put them. bug: 13647418 Change-Id: I3db39bdd761220c5b4966f651892fb592396f9a1
* | am f6811abe: am 9fbd3afd: am 431b4bb3: Merge "Extend the CPU ABI ↵Narayan Kamath2014-03-311-0/+22
|\ \ | |/ | | | | | | | | | | specification mechanism." * commit 'f6811abe12601c9753f329cb34da568f0072ca76': Extend the CPU ABI specification mechanism.
| * Extend the CPU ABI specification mechanism.Narayan Kamath2014-03-281-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a (read only) system property that is a comma separated list of ABIs supported by the device in order of preference. For example, typical arm-v8 device might define: ro.cpu.abilist = arm64-v8a,armeabi-v7a,armeabi For most purposes, a single flattened list like the above is probably more useful than the parallel system of variables TARGET_CPU_ABI{2} / TARGET_2ND_ARCH_CPU_ABI{2} that we use in the build system. Change-Id: If9102669ad9f5f8fd89a8bcc5bf88cca1acadc3c
* | am 8c89a9ff: am 4695598d: am ae49acbd: am 1acb1b64: Merge changes ↵Colin Cross2014-01-271-0/+6
|\ \ | |/ | | | | | | | | | | | | | | I62504bad,I16208cca,I4e4ceec6 * commit '8c89a9ff9cd461e4bc077a91a0c7c32b17a92ebd': add new gen/ directory for generated sources warn on LOCAL_MODULE_PATH in multiarch shared libraries Support LOCAL_MODULE_RELATIVE_PATH
| * add new gen/ directory for generated sourcesColin Cross2014-01-271-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | Allow modules to generate source into $OUT/gen, which will then be copied into $OUT/obj and $OUT/obj_$(TARGET_2ND_ARCH) as necessary. This allows a single build rule invocation that includes generated source to build for the first and second architectures. Modules will need to change calls to local-intermediates-dir into local-generated-sources-dir. Change-Id: I62504bad9454b3d9fde7b84ab9f0a487a2ecf0bf
* | am 088319dd: am dda94546: am 4a1f42d7: am 7c7f28e7: Merge changes ↵Colin Cross2014-01-251-0/+4
|\ \ | |/ | | | | | | | | | | | | | | Ib1d950e1,I3d020a3c,Ic9594718 * commit '088319dd22ac4bc65eb284dfeeab368ac2e90ca9': Add 2nd arch directories for apps Set up rules to build prebuilts for TARGET_2ND_ARCH Set up rules to build packages for TARGET_2ND_ARCH
| * Add 2nd arch directories for appsColin Cross2014-01-241-0/+4
| | | | | | | | | | | | | | Apps built for 2nd arch install in the same directories as when built for the 1st arch. Change-Id: Ib1d950e186eef88212b44d04e6bc6c30a3d56155
| * Support arch-specific LOCAL_ variablesYing Wang2014-01-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | With those variables, you can set up different values for TARGET_ARCH and TARGET_2ND_ARCH. Also fixed a couple of variables. Bug: 11654773 Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b Conflicts: core/base_rules.mk
| * Support to build executables for TARGET_2ND_ARCHYing Wang2014-01-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | By default, an executable is built for TARGET_ARCH. To build it for TARGET_2ND_ARCH in a 64bit product, use: LOCAL_32BIT_ONLY := true To skip a module for TARGET_2ND_ARCH, use: LOCAL_NO_2ND_ARCH := true Bug: 11654773 Change-Id: Ieb293d25b21024bfe1b554044df338e064ac7b46
| * Set up rules to build static libraries for TARGET_2ND_ARCHYing Wang2014-01-241-0/+3
| | | | | | | | | | | | | | | | | | | | The rules for the 2nd arch are set up in the second inclusion of static_library_internal.mk. libfoo of the 2nd arch will be built into $(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/libfoo_intermediates/libfoo.a. Bug: 11654773 Change-Id: I1d92733968fc442e9225b4df5bd1b551a81d89f7
| * Load compiler environment for a second arch.Ying Wang2014-01-241-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the first step to build 32-bit libraries in a 64-bit product. It will work like this: 1) In the product's BoardConfig.mk, define: TARGET_2ND_ARCH, TARGET_2ND_ARCH_VARIANT, TARGET_2ND_CPU_VARIANT. The build system uses those variables to set up an additional compiler environment for the second arch. 2) When parsing Android.mks, the build system sets up rules to build a module for both the 1st arch and the 2nd arch, unless it's explicitly asked to skip so. Android.mk will be adapted if there is additional rule of generating source files. The build system will accept arch-specific LOCAL_ variables, such as LOCAL_CFLAGS_arm, LOCAL_CFLAGS_armv7-a-neon, LOCAL_CFLAGS_cortex-a15, LOCAL_CFLAGS_aarch64 etc. Modules use such variables to set up build for various archs at the same time. 3) Install binary of the 2nd arch by adding "<module_name>:32" to PRODUCT_PACKAGES. All 2nd-arch libraries linked in by "<module_name>:32" will be installed automatically. Bug: 11654773 Change-Id: I2df63cd5463a07bf5358bee2a109f8fb9590fe30 Conflicts: core/combo/TARGET_linux-arm.mk
* | Support arch-specific LOCAL_ variablesYing Wang2014-01-231-0/+4
| | | | | | | | | | | | | | | | | | With those variables, you can set up different values for TARGET_ARCH and TARGET_2ND_ARCH. Also fixed a couple of variables. Bug: 11654773 Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
* | Support to build executables for TARGET_2ND_ARCHYing Wang2014-01-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | By default, an executable is built for TARGET_ARCH. To build it for TARGET_2ND_ARCH in a 64bit product, use: LOCAL_32BIT_ONLY := true To skip a module for TARGET_2ND_ARCH, use: LOCAL_NO_2ND_ARCH := true Bug: 11654773 Change-Id: Ieb293d25b21024bfe1b554044df338e064ac7b46
* | Set up rules to build static libraries for TARGET_2ND_ARCHYing Wang2014-01-161-0/+3
| | | | | | | | | | | | | | | | | | | | The rules for the 2nd arch are set up in the second inclusion of static_library_internal.mk. libfoo of the 2nd arch will be built into $(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/libfoo_intermediates/libfoo.a. Bug: 11654773 Change-Id: I1d92733968fc442e9225b4df5bd1b551a81d89f7
* | Load compiler environment for a second arch.Ying Wang2014-01-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the first step to build 32-bit libraries in a 64-bit product. It will work like this: 1) In the product's BoardConfig.mk, define: TARGET_2ND_ARCH, TARGET_2ND_ARCH_VARIANT, TARGET_2ND_CPU_VARIANT. The build system uses those variables to set up an additional compiler environment for the second arch. 2) When parsing Android.mks, the build system sets up rules to build a module for both the 1st arch and the 2nd arch, unless it's explicitly asked to skip so. Android.mk will be adapted if there is additional rule of generating source files. The build system will accept arch-specific LOCAL_ variables, such as LOCAL_CFLAGS_arm, LOCAL_CFLAGS_armv7-a-neon, LOCAL_CFLAGS_cortex-a15, LOCAL_CFLAGS_aarch64 etc. Modules use such variables to set up build for various archs at the same time. 3) Install binary of the 2nd arch by adding "<module_name>:32" to PRODUCT_PACKAGES. All 2nd-arch libraries linked in by "<module_name>:32" will be installed automatically. Bug: 11654773 Change-Id: I2df63cd5463a07bf5358bee2a109f8fb9590fe30