[RAZR HD Original Android Development] skeevydude:
Please don't quote this post either. Thank you.

Introduction

One of the reasons people download rom sources is to just compile them, but the nostalgia from that wears of pretty fast and you're left thinking -- What Next??? There's plenty of things that can be done, you can add in things like Archidroid's Optimizations, take an AOKP feature and port it to Gummy, you could optimize the build with Linaro or a different GCC version, you might want to try your hand at compiling an optimized toolchain to optimize the rom's compile even further, you could do bug fixes and submit them to CM or your rom of choice's developer..the possibilities are endless, but where to start? How to start?

The example below is based on adding Archidroid's Optimizations to PAC and will be on my GitHub page for anyone to see and use. I'm using Archidroid's Optimizations because they're well documented, they don't cleanly pick with PAC, and they're a neat thing that can be done to nearly any rom -- all that makes it a good candidate for a basic first source based mod tutorial. I'll also be adding in Arrrghhh's kernel because why not.

First thing you need to do is get a Github account.

You're gonna want this. It's free and it gives you a place push your modified sources to; so when you sync, you get your changes. It also serves as a good backup for the projects you're working on. I'll go into remotes and pushing when the time comes.

Now, Archidroid and PAC...where to start?

I'm gonna assume that you've already synced PAC's sources as well as initialized a PAC build to create roomservice.xml and sync the device sources. If you haven't synced yet, but you already have, say, CM or AOSP synced, you can add --reference=/path/to/your/CM/sources and your PAC sync will use your local CM files if they're the same as what PAC needs. --reference is one of my favorite repo commands.

Well, you start by forking all the projects PAC has that are modified by Archidroid's Optimizations, which are android_build, android_art, & for PAC, android_vendor_pac to incorporate it properly into PAC's build script. See, PAC's build script already allows defining the GCC O Level which is a big part of what Archidroid's Optimizations target, but if done right, they can be integrated in a way that allows defining Os, O2, O3, Oa (O Archidroid), and Of (his Ofast commit that he's testing). I might even get around give PAC's build script a way to define GCC version and Google or Linaro GCC...

You're gonna want to open PAC's manifest, located here, and determine from where you fork the 3 projects. You'll see that android_art is from CM, so fork it from Cyanogenmod. To Fork, sign in to Github, go to where the project is located, and click the fork button in the upper right hand corner...simple. android_build and android_vendor_pac are PAC repos, so fork them from PAC.

Thought you were done forking? Nope, you have one more to fork IF you plan on submitting this to PAC's Gerrit like I plan on doing. That fork is PAC-man/pacman because Archidroids GCC repos and (a forked) android_art will have to be added to PAC's manifest.

I'm also going to go into detail and write the guide from the perspective view of using a local manifest, removals, and whatnot -- IMHO, Forking and updating manifests is better if you plan on contributing to a project/submit for Gerrit review, local manifests are better for personal projects, testing, and preparing to do a proper, correct submission to Gerrit review.

Create Local Manifests

Probably the easiest part of AO is adding GCC 4.8. This is done by simply making a file named (pretty much anything except roomservice.xml) linaro.xml. It'll be a standard repo xml file that looks like this

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<!-- Generic Github remote -->
<remote name="github"
fetch="https://github.com" />

<!-- LINARO TOOLCHAIN -->
<project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" remote="github" revision="4.8-eabi" />
<project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" remote="github" revision="4.8-androideabi" />
</manifest>

The only problem with that is, for us, Linaro GCC 4.8 built roms seem a bit more error prone, but we can't just add in Linaro GCC 4.7 like above because we'll get sync errors since PAC already has Google GCC 4.7...so we'll add some project removal lines in the xml...sources in local manifests take precedent.

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<!-- AOSP remote -->
<remote name="aosp"
fetch="https://android.googlesource.com" />

<!-- Generic Github remote -->
<remote name="github"
fetch="https://github.com" />

<!-- Removals -->
<remove-project name="platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7" />
<remove-project name="platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7" />

<!-- ADDS -->
<!-- LINARO TOOLCHAIN -->
<project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.7" remote="github" revision="4.7-eabi" />
<project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7" remote="github" revision="4.7-androideabi" />
<project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" remote="github" revision="4.8-eabi" />
<project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" remote="github" revision="4.8-androideabi" />
<!-- Google 4.8 TOOLCHAIN -->
<!-- Uncomment the two lines, comment out both Linaro 4.8s, then repo sync to change toolchains -->
<!-- <project name="platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" remote="aosp" revision="master" />
<project name="platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" remote="aosp" revision="master" /> -->
</manifest>

NOTE: The remote lines aren't needed here. They're already in PAC's manifest and I only included them above to get you thinking about your remotes when you're setting up a manifest. If you wanna compile PAC following this guides instructions, before you click save after you copy and paste the above xml, delete lines 3 to 11, making the new line the be the Removals line. You should also check the remotes before you use this with other roms, because this is pretty rom independent; the removal lines may not be necessary on some roms.

Now that we have an xml file that handles our toolchain, I'll break it down and explain where the different things come from.

The first thing you'll notice is the remotes. In the xml files, the remote is the website or location you're getting your sources from. They can also be used to use less characters in the xml -- I could have added a remote named Archi with fetch="https://github.com/JustArchi", then I'd change the remote to Archi and the name to just "Linaro". While the 4 repos here isn't that big of a deal, imagine having 300 name="CyanogenMod/blah" projects, name="blah" remote="cm" seems like a better idea doesn't it?.

Below the remotes are the removals, and they're determined by the name= part of a project line of your main manifest.xml or roomservice.xml. Adding in more removals is simply copy/pasting the name= line of a project and having it formatted like you see above.

The Adds....those are just your standard lines of a manifest containing the stuff you want to add to your project or use now that the crap you don't want to use is removed.

Side Project -- Adding in a Arrrghhh's Custom Kernel to the Local Manifest

This part here is generic and geared towards CyanogenMod. I won't be using this with the rest of the Archidroid tutorial.

Simple two line mod

<remove-project name="CyanogenMod/android_kernel_motorola_msm8960-common" />
<project name="arrrghhh/android_kernel_motorola_msm8960-common" path="kernel/motorola/msm8960-common" remote="github" revision="cm-11.0_mod" />

Adding Arrrghhh's Kernel to PAC Vendor

While the Dev Team's kernel is nice and stable, it just doesn't have all that many tweaks. That's where Arrrghh's kernel comes into play. It's the Dev Team's kernel with both higher and lower frequencies to use, more governors and schedulers, adjustable voltage table, and more.

Before I go on, there are two programs I use that help with merge conflicts, and those are Meld and Git-Cola. I'll be using them below, but if you have a preferred way of dealing with merge conflicts, then by all means use that (I like SmartGit HG too). For most Debian/Ubuntu distros, they can be installed with the following terminal command.

[COLOR="Blue"]sudo apt-get install meld git-cola[/COLOR]

IMPORTANT: I'll be using my own personal repos and directories below. I'll try to point them out, but for general note, /android/pac is my sources' root directory and remotes created named skeevy are mine, you need to create them with a different name and have the URL set to your github account, not mine.

Now that that's out of the way, fire up the terminal and go to your sources root directory, for me it's cd /android/pac, and do a repo sync. Once the sources update, we start.

Go to vendor/pac -- [COLOR="Blue"]cd vendor/pac[/COLOR]
Add your remote -- [COLOR="blue"]git remote add [/COLOR][COLOR="SeaGreen"]skeevy [/COLOR][COLOR="Blue"]https://github.com/[/COLOR][COLOR="SeaGreen"]skeevy420[/COLOR][COLOR="Blue"]/android_vendor_pac.git[/COLOR]
fetch remotes -- [COLOR="Blue"]git fetch --all[/COLOR] (or git fetch [I]name_of_remote[/I] to only fetch a single remote)
Add a new branch and switch to it -- [COLOR="Blue"]git checkout -b pac-4.4[/COLOR] [COLOR="green"]***BRANCH NOTE***[/COLOR]

Fire up your text editor, I use gedit, and use that to open up our pac device dependencies file

/android/pac/vendro/pac/dependencies/moto_msm8960.dependencies

[
{
"remote": "github",
"account": "PAC-Motorola",
"repository": "android_device_motorola_moto_msm8960",
"target_path": "device/motorola/moto_msm8960",
"revision": "cm-11.0"
},
{
"remote": "github",
"account": "CyanogenMod",
"repository": "android_device_motorola_qcom-common",
"target_path": "device/motorola/qcom-common",
"revision": "cm-11.0"
},
{
"remote": "github",
"account": "CyanogenMod",
"repository": "android_device_qcom_common",
"target_path": "device/qcom/common",
"revision": "cm-11.0"
},
{
"remote": "github",
"account": "CyanogenMod",
"repository": "android_kernel_motorola_msm8960-common",
"target_path": "kernel/motorola/msm8960-common",
"revision": "cm-11.0"
},
{
"remote": "github",
"account": "Pinky-Inky-and-Clyde",
"repository": "proprietary_vendor_motorola",
"target_path": "vendor/motorola",
"revision": "cm-11.0"
}
]

And modify the kernel part so it looks like this

"remote": "github",
"account": "arrrghhh",
"repository": "android_kernel_motorola_msm8960-common",
"target_path": "kernel/motorola/msm8960-common",
"revision": "cm-11.0_mod"

Save it. Gedit, by default, saves a backup file in the same directory as the file you saved, make sure you delete that file if it did. And back to the terminal.

Commit the change -- [COLOR="Blue"]git commit -a -m "Change moto_msm8960 kernel to arrrghhh's kernel"[/COLOR]
Push and set remote as upstream -- [COLOR="blue"]git push --set-upstream [/COLOR][COLOR="SeaGreen"]skeevy[/COLOR][COLOR="Blue"] pac-4.4[/COLOR]

Now that Arrrghhhs kernel has been added to PAC, we'll move on to adding Archidroid to android_art....just kidding, we gotta play with removals and local manifests again...remove PAC's vendor and use your forked one.

<remove-project name="android_vendor_pac" />
<project name="[COLOR="SeaGreen"]skeevy420[/COLOR]/android_vendor_pac" path="vendor/pac" remote="github" revision="pac-4.4" />

Android Art

Finally, actually doing something related to Archidroid's Optimizations. Yay.

JUST A TEMP SAVE. I'M STILL WORKING ON THIS

Art -- Remote

Art -- Branch

Art -- Pick

Art -- Push

Build -- Remote

Build -- Branch

Build -- Pick

Build -- Fix\Build Script Integration

Build -- Push

Vendor -- Almost same as above

Vendor -- Archidroid into Pac Build Script

Vendor -- Add Arrrghhh kernel

Pac Compile 0a

Pac Compile 0f

This part of the guide will take me 5 or 6 hours....but you'll get some cool builds out of it

Submitting to PAC's Gerrit if builds are successful, doesn't actually have to boot or work...I'll explain...

Wait a for anything above's upstream to be updated, and an update my forked stuff with master guide.

***BRANCH NOTE*** pac-4.4 (the branch name) can be whatever you want it to be, but if it's something you'll submit for a gerrit review, use the branch the project you're committing to is using. There's also using a temp branch then cherry-picking in the changes when your done...but we're not going into gerrit strategies here.