Add Local.mk optional override include for build paths

[DrMattChristian]

Summary

Replace the previous approach (changing default directory locations) with a minimal Local.mk include that lets users override build variables without modifying environment variables or shell config.

Changes

• Added: -include of Local.mk from the build directory (after root derivations, before overridable defaults)
• Added: .gitignore entry for lt/lt/build/Local.mk
• Updated: Doc comment on LT_TARGET_ROOT to mention Local.mk override

Why not just env vars?

Environment variables remain the primary override mechanism (nothing changes for existing users). Local.mk is an additional option for:

• Per-project scoping — no shell profile pollution across projects
• Discoverability — new developers see Local.mk mentioned in comments and know they can create it
• CI/CD consistency — file-based overrides work identically locally and in CI
• Guilt-free experimentation — create, edit, test, and delete without touching shell config

Usage

Create lt/lt/build/Local.mk with any Makefile variable assignments:

# Example: place toolchains outside $HOME
LT_VENDOR_TOOLCHAINS_DIR := /opt/lt-vendor-toolchains

# Example: place build targets elsewhere
LT_TARGET_ROOT := /scratch/lt-targets

The file is gitignored and silently skipped when absent.

[RokuDon]

The LT_VENDOR_TOOLCHAINS_DIR is where the extracted toolchains go. Basically we wanted to include toolchains for the supported platforms, but the vendor distributions were huge so we took the vendor distributions and stripped out all but the gnu tools needed and tarred those up. The Makefile looks for the tools in LT_VENDOR_TOOLCHAINS_DIR and if it doesn't find it, extracts them there from the tarballs. Extracting the toolchains into the LT_VENDOR_TOOLCHAINS_DIR in the user's home directory is suboptimal, but putting it under the os root is not a good solution. Great care was taken to put all build artifacts outside of anything that got checked into git. Putting the LT_TARGETS_DIR at the same level of the repo is also suboptimal but outside the repo. We considered putting LT_VENDOR_TOOLCHAINS_DIR inside of LT_TARGETS_DIR, but decided we liked the simplicity of "make cleanall" (rm -rf ${LT_TARGETS_DIR}).

Where we landed was to leave things as-is, with the ability to override LT_VENDOR_TOOLCHAINS_DIR and LT_TARGETS_DIR in your environment.

[DrMattChristian]

Thank you for your comprehensive review and comments @RokuDon . I guessed that there were good reasons for these directory placement decisions, but the rationale wasn't exactly clear to me. I couldn't figure it out on my own, at least without full (Roku internal) git repo history/logs. Therefore it sounds like the way forward to avoid polluting $HOME is to keep a local Makefile with uncommitted changes which overrides these LT_VENDOR_TOOLCHAINS_DIR and LT_TARGETS_DIR variables. Perhaps another way would be to optionally include a local Makefile variables file that can override while keeping the Roku-as-designed Makefile intact. I'll think about it. This PR can remain in DRAFT status (WIP, not ready) until a different/better solution can be attempted. Likely I'll totally re-work my approach.

[RokuDon]

You could edit your .bashrc file to export LT_VENDOR_TOOLCHAINS_DIR and LT_TARGETS_DIR to whatever you want. Or modify or make your own build-setup.sh file to do same.

[DrMattChristian]

You could edit your .bashrc file to export LT_VENDOR_TOOLCHAINS_DIR and LT_TARGETS_DIR to whatever you want. Or modify or make your own build-setup.sh file to do same.

That's correct, and understood about modifying the shell scripts and setting shell environment variables. I'm looking at the directory customization via the Make configuration as well, with suggested plans forthcoming and in the works.

[DrMattChristian]

This PR and change set has been entirely rewritten from scratch. Refer to the updated title, description and very minimal changes. If Roku isn't interested in merging these updated changes then I understand why now. There are alternative workarounds, including me keeping/stashing my own uncommitted changes.