[Verizon Samsung Galaxy S 4] Jon8RFC:
I'm having quite a difficult time getting a final product actually compiled, and have a question about modifying extract_files.sh.

The primary guide (in addition to many hours of setups, searches and additional reading) I've been using is Cyanogenmod's for JFLTEVZW, and the unified builds have officially confused the hell out of me. I know it went from non-unified, to unified, back to non-unified, but my attempts at compiling a build continue to fail or the OS completely freezes--I've recreated my build environment multiple times and am now using someone else's pre-configured, downloadable Cyanogenmod build environment image, which I've imported into VirtualBox...but something inevitably goes wrong, and I guess I'll ask about that if and when it fails/freezes during the "brunch" process again.

Does linux or however this whole git/repo/sync system is configured "remember" in some configuration file somewhere when I've done a breakfast jflte (not jfltevzw) once before, and despite deleting all contents of the android/system folder and starting fresh, if I do it for jfltevzw again, it will still grab files for jflte, or is that normal?

android@builduntuvm:~/android/system$ source build/envsetup.sh && breakfast jfltevzw
including device/generic/mini-emulator-x86/vendorsetup.sh
including device/generic/mini-emulator-mips/vendorsetup.sh
including device/generic/mini-emulator-arm64/vendorsetup.sh
including device/generic/mini-emulator-x86_64/vendorsetup.sh
including device/generic/mini-emulator-armv7-a-neon/vendorsetup.sh
including device/samsung/jflte/vendorsetup.sh
including device/samsung/jfltevzw/vendorsetup.sh
including vendor/cm/vendorsetup.sh
including sdk/bash_completion/adb.bash
including vendor/cm/bash_completion/git.bash
including vendor/cm/bash_completion/repo.bash
including vendor/cm/vendorsetup.sh
Looking for dependencies

============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=5.0.2
CM_VERSION=12-20150417-UNOFFICIAL-jfltevzw
TARGET_PRODUCT=cm_jfltevzw
TARGET_BUILD_VARIANT=userdebug
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
TARGET_CPU_VARIANT=krait
TARGET_2ND_ARCH=
TARGET_2ND_ARCH_VARIANT=
TARGET_2ND_CPU_VARIANT=
HOST_ARCH=x86_64
HOST_OS=linux
HOST_OS_EXTRA=Linux-3.16.0-28-generic-x86_64-with-Ubuntu-14.10-utopic
HOST_BUILD_TYPE=release
BUILD_ID=LRX22G
OUT_DIR=/home/android/android/system/out
============================================

Is it supposed to be doing this, or have I messed up somewhere since I'm not a linux guru and I know the concept of "I deleted the folder" is not the same as in Windows? I'm wondering if something was written to a file somewhere when I FIRST ran breakfast jflte without knowing exactly which one I should be doing, or if this is normal, despite the s4 being unique by having unified CM builds for a while. I may need to have this build/compile process explained to me as if I'm new to computers, apparently.

My goal is to make various compiled builds so that I can attempt to fix the broken compass. The problem may be that the code worked before the unified builds, and so the other part of my question is, how do I modify extract_files.sh so that I can have it pull the files from a cyanogenmod .zip file? I've read this, and looked at the file and don't understand which of the four lines to edit. Also, within android/system/device/samsung there are jf-common, jflte, jfltevzw, qcom-common folders, and both the jflte and jfltevzw (again, I don't know if both should even be there since I'm doing a sync when the builds are no longer unified) have an extract_files.sh which points to the file in jf-common (again, I don't know if I should/can be doing breakfast/brunch jflte or jfltevzw because of the lack of acknowledgement to prior and vestigial unified components remaining in the CM code in the "how to build CM" documentation):

#!/bin/sh

set -e

export DEVICE=jfltevzw
export VENDOR=samsung
./../jf-common/extract-files.sh $@

#!/bin/bash

function extract() {
for FILE in `egrep -v '(^#|^$)' $1`; do
OLDIFS=$IFS IFS=":" PARSING_ARRAY=($FILE) IFS=$OLDIFS
FILE=`echo ${PARSING_ARRAY[0]} | sed -e "s/^-//g"`
DEST=${PARSING_ARRAY[1]}
if [ -z $DEST ]; then
DEST=$FILE
fi
DIR=`dirname $FILE`
if [ ! -d $2/$DIR ]; then
mkdir -p $2/$DIR
fi
if [ "$SRC" = "adb" ]; then
# Try CM target first
adb pull /system/$DEST $2/$DEST
# if file does not exist try OEM target
if [ "$?" != "0" ]; then
adb pull /system/$FILE $2/$DEST
fi
else
cp $SRC/system/$FILE $2/$DEST
# if file dot not exist try destination
if [ "$?" != "0" ]
then
cp $SRC/system/$DEST $2/$DEST
fi
fi
done
}

if [ $# -eq 0 ]; then
SRC=adb
else
if [ $# -eq 1 ]; then
SRC=$1
else
echo "$0: bad number of arguments"
echo ""
echo "usage: $0 [PATH_TO_EXPANDED_ROM]"
echo ""
echo "If PATH_TO_EXPANDED_ROM is not specified, blobs will be extracted from"
echo "the device using adb pull."
exit 1
fi
fi

BASE=../../../vendor/$VENDOR/jf-common/proprietary
rm -rf $BASE/*

DEVBASE=../../../vendor/$VENDOR/$DEVICE/proprietary
rm -rf $DEVBASE/*

extract ../../$VENDOR/jf-common/common-proprietary-files.txt $BASE
extract ../../$VENDOR/$DEVICE/device-proprietary-files.txt $DEVBASE

../jf-common/setup-makefiles.sh

So what exactly do I need to change, per these instructions so that I can pull the proprietary files from, say, cm-11-20140210-SNAPSHOT-M3-jfltevzw.zip (pre-unified) or cm-11-20140504-SNAPSHOT-M6-jflte.zip (post-unified) instead of from my phone? I saw the PATH_TO_EXPANDED_ROM part, but I don't know where that's referenced, so I don't know how to make use of that instead.

I'll be grateful for any help, because I'd really like to take a shot at reviving the compass since it used to work correctly. Thanks =)

Unless someone can guarantee to me that if I were to recompile the very first CM10 build for the S4, I could just do a normal pull of the proprietary files from my CM12 nightly phone and end up with a compiled zip identical to the first CM10 and would have zero changes compared to the original CM10, then I won't bother with trying to pull the proprietary files from an older CM zip instead of my current nightly, which I presume are related to hardware functionality--something I want to fix.