Source

Building

First, you’ll need a case sensitive filesystem, which handily rules out Windows. With OSX, the default is a case *in*sensitive FS. You can, however, create a disk image (sparse bundle or sparse image will be easiest) with a case sensitive filesystem. Journaled HFS as long as it’s case sensitive is fine, if there’s still UFS support that should be fine too. About 15-20gb is fine.

Then, download the repo script from the andriod git repository (android.git.kernel.org). This part is documented in the Android documentation. Put it somewhere in your path. There are some other tools needed, so install macports (or if you have a preferred package manager, use that… if you’re on Linux use whatever package management tools your distribution comes with.. I still like dselect) and glean the proper tools from the CyanogenMod wiki (pick a phone and look at its build instructions most will list which packages you’ll need to install).

Then, initialize your repository (repo init) with the proper branch (in this case, gingerbread). This proper flags should also be in the Android documentation.

The stock CyanogenMod repo is here: http://github.com/CyanogenMod/android/
The IHO repo for proper LS670/VM670 support is here: http://github.com/inferiorhumanorgans/android/
Note: You only need ONE of the repositories. If you’re building for an LG Optimus choose the latter. If you’re building for a phone that’s officially supported by CyanogenMod use the former.

After you’ve run repo init, sync the repository. This will download a few (six?) gigabytes of data. Take a break here.

With the IHO stuff there is a binary blob repository with files for the VM670 and MS690. If you’ve files from another model you’d like to contribute, please fork the repository and open a pull request. You can find the list of files needed in device/lge/thunderc/device_thunderc.mk. Look for everything copied over from “vendor/lge/thunderc/proprietary/”.

With that all setup include build/envsetup.sh into your current terminal window/console. Run “source build/envsetup.sh” or “. build/envsetup.sh”.

Then configure the build by running lunch, and selecting your phone model.

Then run ‘make bacon’. Assuming all goes well, you’ll end up with the last two lines showing the file name of the newly created zip and an md5 checksum. Copy the zip to your phone’s sd card and flash it from your recovery. Then flash the appropriate gapps (available from the CM wiki).

Updating

If you want to make significant changes, or you want to be able to create pull requests with github (to submit changes back to me or CM), then, yes, fork the repo manifest repository (typically ‘android’), fork the appropriate other repositories on github, change the entries in the repo default.xml, commit default.xml to your forked ‘android’ repository, re-init and re-sync your build tree. Nothing will be lost.

Pushing your changes back to github or to gerrit will be left as an exercise to the reader. I’m trying to figure out which I like least: git, gerrit, or repo.

When it comes time to grab the latest CM or IHO changes, repo sync will update your whole tree. I will again highly recommend not forking anything on your own unless you plan on making significant changes. If you use a forked version of something, you will have to manually pull in CM and IHO changes, push them back to your GitHub fork, and /then/ sync.

Video Tutorial

Here is the first in a series of videos by TechTV about building Android from source. They are long videos, but they cover things pretty well, and should leave you with a much better understanding of how the various files interact in the build process.
TechTV— Build Android from Source