because the dumpvar target was included early in envsetup.mk, it was
not possible to use it to dump variables that were defined by makefiles
included later (like the toolchain variables in combo/select.mk).
move dumpvar.mk to after select.mk and javac.mk, so that shell functions
can be created using the toolchain build variables
Change-Id: I1c22025a8981fa91c183846fb28be26fb562adfb
Signed-off-by: Gary King <gking@nvidia.com>
Besides that, add enough magic to build everything tagged
as "shell_$(TARGET_SHELL)" and permit ash/mksh as not unusual
Change-Id: I36c0590ba49f45251d24dc179cb27c8368c3662a
- envsetup.mk & config.mk: we define a new BUILD_OS and a minimal set
of things like BUILD_OUT to be able to use some local tools when
doing cross-compilation. This allows us to use the Linux version of
ACP when cross-compiling the tools to Windows.
- Makfile: include windows_sdk.mk when needed to build a Windows SDK.
- main.mk: support a win_sdk target (e.g. PRODUCT-sdk-win_sdk)
(Merge master Change I9d08d0df)
Construct the /system/etc/event-log-tags file by unioning together any
*.logtags files included in LOCAL_SRC_FILES throughout the system (with
appropriate error checking for dup tag numbers, etc.)
For java packages, generate a java source file from the logtags file for
that package that contains static integer constants for each tag name.
BoardConfig.mk typically defines TARGET_CPU_ABI to the name of the
native machine code CPU ABI supported by the target device. For example,
existing devices today use the value 'armeabi' corresponding to an
ARMv5TE instruction set with soft-float implementation.
This patch allows this file to also define TARGET_CPU_ABI2 to name
a secondary (minor) CPU ABI also supported by the device. This is useful
when the main ABI is ARMv7-A (identified as 'armeabi-v7a') which also
supports ARMv5TE. Such devices should have TARGET_CPU_ABI defined to
'armeabi-v7a' and TARGET_CPU_ABI2 defined to 'armeabi'.
TARGET_CPU_ABI2 will be translated into the ro.product.cpu.abi2 property
in build.prop. This value will be used by the PackageManager to handle
"fat-binaries" generated with the NDK.
to make not having a virtual destructor in classes with virtual
methods an error. I already fixed all code that had this problem,
so now it's a matter of turning the option on.
Also, as long as we don't have any C-specific options, it's
probably best to copy the CPP flags from the C flags. We can
always break them out later.
Merge commit 'e41accf68eedfd17bc569aee8480cf8c48d82e61'
* commit 'e41accf68eedfd17bc569aee8480cf8c48d82e61':
Pass compiler flags for C++ too, and add a flag that enables warnings about missing virtual destructors
This allows TARGET_ARCH_VARIANT to be set by the vendor before we choose the
architecture in core/combo/select.mk.
Also add a primitive armv7-a.mk for turning on hardware floating point.
Use zlib's minigzip utility, built as part of our source tree, instead of
whatever installation of GNU gzip happens to be on the user's machine.
Using zlib's deflater, which is nicely available as a library (unlike
GNU gzip's deflater) will ultimately let us do binary patches to the
boot and recovery images.
