构建包

应该使用 emake 函数来调用 make。这将确保用户的使用 MAKEOPTS 被正确使用。 emake 函数会传递任何提供的参数，因此它可以用来执行非默认的目标（例如 emake extras）。有时你可能会遇到一个奇怪的非 autotools Makefile，它会随着 emake 而崩溃，但这很少见。

构建应该用各种 -j 设置在 MAKEOPTS 中进行测试，以确保构建能正确并行化。如果一个包没有干净地并行化，它应该被修补。

如果修补真的不是一个选择，应该使用 emake -j1。然而，在这样做的时候，请记住，你正在严重地降低许多非 x86 用户的构建时间，尤其是。强制使用 -j1 会使一些 MIPS 和 SPARC 系统的构建时间从几分钟增加到一个小时。

修复编译器使用

有时一个包会尝试使用一个奇怪的编译器，或者需要被告知使用哪个编译器。在这些情况下，应该使用 tc-getCC() 函数，它来自 toolchain-funcs.eclass。还有其他类似的函数可用 - 这些函数在 man toolchain-funcs.eclass 中有文档。

请注意，软件包应该始终尊重用户的 CC 首选项，并且不能依赖于诸如 /usr/bin/cc 或 /usr/bin/gcc 之类的便捷符号链接。一个追踪器 bug 存在于记录此类问题。 wiki 上有额外的文档。

注意： 使用 ${CC} 变量来实现此目的不正确。

有时一个包不会使用用户的 ${CFLAGS} 或 ${LDFLAGS}。这必须得到解决，因为有时这些变量被用来指定关键的 ABI 选项。在这些情况下，构建脚本应该被修改（例如，使用 sed 或通过补丁）来正确使用 ${CFLAGS} 或 ${LDFLAGS}。

inherit flag-o-matic toolchain-funcs

src_prepare() {
	default

	# We have a weird Makefile to work with which ignores our
	# compiler preferences. yay!
	# Note the single quotes (hence the delimiter is not an issue)
	sed -i -e 's:cc -O2:$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS):' Makefile \
		|| die "sed fix failed. Uh-oh..."
}

src_compile() {
	# -Os not happy
	replace-flags -Os -O2

	emake CC="$(tc-getCC)" \
		CPPFLAGS="${CPPFLAGS}" \
		CFLAGS="${CFLAGS}" \
		LDFLAGS="${LDFLAGS}"
}

注意： 尽量不要直接用 sed 替换值，而是让构建脚本使用变量。变量可能包含斜杠、逗号或冒号等字符，这些字符经常与 sed 一起使用，这会导致语法错误。

Portage 执行一个 QA 检查，验证 LDFLAGS 是否被尊重。此 QA 检查仅在 LDFLAGS 变量包含 -Wl,--hash-style=gnu 时启用。（此标志只能在使用 sys-libs/glibc 的系统上使用，除了 MIPS CPU 的机器。）