工具链是一套Makefiles和补丁，可用于为OpenWrt系统生成交叉编译器和根目录。正在使用的C库是musl。

编译工具链是用于为系统编译代码的工具集。 它包括：

• 编译器 (我们使用, gcc )
• 连接器和汇编器(我们使用, binutils )
• C標準函式庫 (例如 musl-libc, GNU Libc, uClibc 或者 dietlibc).

A compilation toolchain generates code for the same processor's instruction set architecture (ISA) it runs on (in the case of most PCs and servers, for an x86 processor).
On most Linux systems, the compilation toolchain uses the GNU libc as C standard library. This is called the “host compilation toolchain”, and the machine it is running on is called the “host system”. The host compilation toolchain is provided by the Linux distribution running on the host system, and has nothing to do with the actual build system.

Embedded systems use a different processor and require a cross-compilation toolchain - a compilation toolchain that runs on a host system but that generates code for a target system (and target processor's instruction set architecture (ISA)). For example, if your host system uses x86 and your target system uses MIPS32, the cross-compilation toolchain runs on x86 but generates code for MIPS32.

While it is possible to manually configure and compile your own software, this is complex and does not guarantee reproducible builds. LEDE's build system automates this process and provides a 100% reproducible build.

While the build system was designed for developers, inexperienced users can also use it to easily build their own custom firmware!

The build system's Makefiles have their own syntax, different from the conventional Makefiles of Linux make tool.
The Makefiles define the meta information of the package, where to download the package, how to compile, where to install the compiled binaries, etc.

• Makes it easy to port software
• Uses kconfig (Linux Kernel menuconfig) for configuration of features
• Provides integrated cross-compiler toolchain (gcc, ld, …)
• Provides abstraction for autotools (automake, autoconf), cmake, scons
• Handles standard download, patch, configure, compile and packaging workflow
• Provides a number of common fixups for badly behaving packages

• Offers a number of high level make targets for standard package workflows
• Targets always in the format “component/name/action”, e.g. “toolchain/gdb/compile” or “package/mtd/install”
• Prepare a package source tree: package/foo/prepare
• Compile a package: package/foo/compile
• Clean a package: package/foo/clean

1. tools – automake, autoconf, sed, cmake
2. toolchain/binutils – as, ld, …
3. toolchain/gcc – gcc, g++, cpp, …
4. target/linux – kernel modules
5. package – core and feed packages
6. target/linux – kernel image
7. target/linux/image – firmware image file generation

• Many packages will not work as-is and need patches to work on the target or to even compile
• the build system integrates quilt for easy patch management
• Turn package patches into quilt series: make package/foo/prepare QUILT=1
• Update patches from modified series: make package/foo/update
• Automatically rebase patches after an update: make package/foo/refresh

• Main objective is small memory and size footprint
• Features that make no sense on embedded systems are disabled through configure or patched out
• Packages must be compilable regardless of the host system, they should be self contained
• Shipped “configure” scripts are often faulty or unusable in a cross-compile setting, autoreconf or patching is often needed
• Build variants and kconfig includes allow for configurable compile-time settings
• There is no standard way for porting software, in many cases it “just works” but often the package build process needs tweaks

• Install the build system on the host
• Use the build system to compile a firmware image
• Work with patches in the build system

• commits concerning OpenWrt build system
• OpenWrt Forums: An introduction to OpenWrt Buildroot