Add support for selectable kernel toolchains set in device

TARGET_KERNEL_CUSTOM_TOOLCHAIN= linaro
     builds kernel with linaro toolchain in: prebuilts/gcc/linux-x86/toolchain/linaro/bin/arm-eabi-

TARGET_KERNEL_CUSTOM_TOOLCHAIN= arm-eabi-4.6/bin/arm-eabi-
     builds kernel with arm-eabi-4.6 toolchain in: prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-

TARGET_KERNEL_CUSTOM_TOOLCHAIN= arm-eabi-4.7/bin/arm-eabi-
     builds kernel with arm-eabi-4.7 toolchain in: prebuilts/gcc/linux-x86/arm/arm-eabi-4.7/bin/arm-eabi-

Conflicts:
	core/tasks/kernel.mk
build: use the system's ccache by default

ccache 3.x supports direct mode (http://ccache.samba.org/manual.html#_the_direct_mode)
This is not supported in the prebuilt version. Direct mode has been shown to decrease build time by up to 40x, compared to preprocessor mode used in ccache 2.4, which is substantially less

Change-Id: I224de8e5bc53bbe18a7a02fc811324307cf3ab8c
Add recoveryzip target. Import recovery building/porting tools.
build: let TWRP eat zips too

This allows us to sideload zips regardless of the recovery in place.

Change-Id: I5e95614e545a617737fcc27fd892f42c29a06f9b

Conflicts:
	envsetup.sh
envsetup: do not print an error if complete fails

complete is a bashism; so it will fail on other shells. Avoid printing
an error if that is the case.

Change-Id: Id6d6311792f409cc3a697c7a2bb003863f1afe60
envsetup: drop unnecesary exports

export -f is a bashism and we don't actually need it, so lets remove it.

Conflicts:
	envsetup.sh

Change-Id: I9228cef0c4a9543b3d34fdc39a368ad0238431e2

Conflicts:
	envsetup.sh
envsetup: Mark zsh as compatible

Basic functionality has been tested on zsh 5.0.2 and has been found to
work correctly.

Change-Id: I02e5e3bedf56b43104c280d9737ae7b334357643
[HAX] Allow per-target dtbTool

 * Revert this when fixed

Change-Id: I97ecb0448ae7bd5859454be290c5dde6248b2859

Conflicts:
	core/generate_extra_images.mk
Y u no accurate

Conflicts:
	core/version_defaults.mk
Revert "Y u no accurate"

This reverts commit 42d17b4d53397167c5df9770c3b55f5c5305b9d3.
gettop: fix symlink detection

Summary: We must use the -P flag for pwd to properly get $PWD from the environment *with* symlinks. Otherwise symlink
detection is broken and anything we do using $(gettop) at the top of a symlinked path won't work properly. I noticed this
issue while running on a system that has a SSD RAID symlinked to my android build home directory, which is ~/ssd_storage.
The top in this instance is a symlink, which means that gettop() returns my home path, or the path above the symlink
directory (but not the symlinked directory). This is a major issue in case developers choose to use $(gettop),
$ANDROID_BUILD_TOP, or $T (doesn't really matter either way).

Test Plan: Create a symlink and sync android source into the path. Open up the symlink, run envsetup.sh, and check
$(gettop) output.

While this isn't the best solution, it fixes an issue without creating new issues.

Change-Id: I65bc345753805e6161098d2af6e0bee0b07d37b1
Update ASCII on updater script
Fixes for gcc 4.8/4.9

Change-Id: I498ab5fd5ef97b21e365dbcac6110eabaec5d289
Revert "Update ASCII on updater script"

This reverts commit a5bb8c2b5c644aa94904ac2a2f793af467b78c5b.
Build: Add more Color Options

Signed-off-by: Chester Kener <Cl3Kener@gmail.com>
 4.8 GCC, Strict Aliasing=3, -O3 CFLAG, Opt Flags!!

For those of you who are building cm-11.0 with the neofy script,
none of this stuff applies to you as the script did it all for you ;)

To everyone else:
With this commit, you will be heavily modifying your build environment. What this
will do, is allow you the freedom of using any custom toolchain of your choice,
provided you follow two simple rules:

RULE #1: Both the androideabi and armeabi toolchain folders of your choice HAVE to
be named like the following:

for androideabi, the folder has to be prefixed with: arm-linux-androideabi-
and for arm-eabi, the folder has to be prefixed with: arm-eabi-

ex:

If you want to use GCC-4.8 as your toolchain of choice, both the androideabi and
armeabi folders have to look like this:

arm-linux-androideabi-4.8
arm-eabi-4.8

if you want them to be different, say, 4.8 for the arm-eabi and 4.9 for androideabi,
then they should look like this:

arm-eabi-4.8
arm-linux-androideabi-4.9

Take note, that if usining linaro, you will have to clone in the toolchain twice as
this method requires two different folders (the way it should be IMO). You would need
to rename one of the clones to arme-abi- and the other to arm-linux-androideabi-.

SECTION 2
RULE #2: The default configuration I've set is to build with GCC 4.8 for androideabi and 4.8 for
armeabi by default (in core/combo/TARGET_linux-arm.mk lines 50-51) unless you specify an alternate
target chain on those two lines! So if you want to use a different chain, you'll
need to change the build numbers on those two lines. for Example:

Say you wanted to use a 4.7 chain instead for armeabi and 4.8 for androideabi.. You would
change lines 50 and 51 to the following:

TARGET_GCC_VERSION_ARM := 4.7
TARGET_GCC_VERSION_AND := 4.8

Notice at the end of each line one is for ARM and one is for AND which hints at armeabi
and androideabi and the only thing you're changing is the number.

You also need to make sure rule number 1 is observed if you do this.. Can't build with
an alternate chain if one is not present ;) Personally, I've found the following two
toolchains to be the best without any drawback to rom (sans ART) courtesy of sparksco:

https://github.com/SaberMod/android_prebuilts_gcc_linux-x86_arm_sabermod-arm-eabi-4.8
https://github.com/SaberMod/android_prebuilts_gcc_linux-x86_arm_sabermod-arm-linux-androideabi-4.8

MAKE SURE YOU PULL BOTH FROM THE sm-kk-mr1 BRANCH IF YOU DECIDE TO USE THESE CHAINS!

This build commit also changes your global compiler ARM flags to -O3. -O3 is an option
that enables all -O1 and -O2 flag options as well as some heavy -O3 flag options that build
for optimized performance!

This commit also adds a few optimization flags that I've pre-selected for added performance.

This commit also builds the entire rom using a Strict Aliasing rule set at the highest level
of =3 and set to error on every strict aliasing issue. Make sure that you have all the
proper strict aliasing commits needed! If you can't find them, they will be
available to you on my github account at https://github.com/IAmTheOneTheyCallNeo

to make your search for all those needed easier, you can find all of them in the following script:
https://github.com/vigor/android/blob/cm-11.0/neofy.sh

Contact me if you have any issues and I will help you when and if I can.

-Neo

Conflicts:
	core/combo/TARGET_linux-arm.mk
	core/combo/select.mk
	core/tasks/kernel.mk
	envsetup.sh

Conflicts:
	core/combo/TARGET_linux-arm.mk
	core/combo/select.mk
	envsetup.sh
Allow building with SaberMod/Linaro Toolchains
Add option to flag 4.8 builds for devices that do not support 4.9 yet
Lets show what we are building with

Conflicts:
	core/dumpvar.mk
build: Inline kernel building as a buildtime task
By arcee

Kernel image integration is now done in the build system. The
"one true way" of doing this is to download the kernel source
into kernel/TARGET_BOOTLOADER_NAME (by usage of the cm.dependencies
mechanism or otherwise), and defining the TARGET_KERNEL_CONFIG
variable in the device's BoardConfig makefile

If the kernel's location doesn't match the automagic location
(multi-device kernel source, for instance), TARGET_KERNEL_SOURCE
can be used to specify a kernel path (i.e.,
"TARGET_KERNEL_SOURCE := kernel/shared-whatever")

If the device requires out-of-kernel-tree modules to be built,
the TARGET_KERNEL_MODULES variable can be used, pointing to a
_make target_ that will build and install such modules. Definition
of such a target is the device author's responsibility, the only
restriction is that it is a normal makefile recipe (example
below)

Optionally (or as an alternative), a prebuilt binary can also be
defined at BoardConfig, by usage of the TARGET_PREBUILT_KERNEL
variable. This binary will be used if the kernel source is absent
(or undefined).

A minimal BoardConfig.mk should look something like this:

TARGET_KERNEL_CONFIG := cyanogenmod_<device>_defconfig
TARGET_PREBUILT_KERNEL := device/<vendor>/<device>/kernel

To include, for example, the TI WLAN modules, this can be used:

-----------------------------
TIWLAN_MODULES:
       make -C hardware/ti/wlan/wl1283/platforms/os/linux/ KERNEL_DIR=$(KERNEL_OUT) ARCH="arm"
CROSS_COMPILE="arm-eabi-" TNETW=1273 RANDOM_MAC=n REPORT_LOG=n
       mv hardware/ti/wlan/wl1283/platforms/os/linux/tiwlan_drv.ko $(KERNEL_MODULES_OUT)
       make -C hardware/ti/wlan/wl1283_softAP/platforms/os/linux/ KERNEL_DIR=$(KERNEL_OUT) ARCH="arm"
CROSS_COMPILE="arm-eabi-" TNETW=1273 REPORT_LOG=n
       mv hardware/ti/wlan/wl1283_softAP/platforms/os/linux/tiap_drv.ko $(KERNEL_MODULES_OUT)

TARGET_KERNEL_MODULES := TIWLAN_MODULES
---------------------------

Change-Id: I8634fa4c788a42dc6f62e62ca170825b66db126a

Conflicts:
	core/tasks/kernel.mk