在 Application.mk 中更改 APP_OPTIM 会导致完全重建答案

【问题标题】：Changing APP_OPTIM in Application.mk causes full rebuild在 Application.mk 中更改 APP_OPTIM 会导致完全重建
【发布时间】：2014-03-26 18:06:00
【问题描述】：

我猜 Eclipse 或 NDK 构建系统都没有使用单独的文件夹来提供有关调试与发布构建的编译器输出，但无论出于何种原因，它都使得来回切换以进行调试非常缓慢，因为它每个都在进行完全重建时间。这种（不良）行为是否有补救措施？

【问题讨论】：

标签： android build android-ndk compiler-optimization

【解决方案1】：

有两种情况会导致这种情况发生：

1) 如果您更改 Application.mk 文件，make 系统会触发完全重建。我不确定这是否是 gnu make 的标准或与 android 如何使用 make 有关。

解决方案：
使用两个单独的 make 文件进行发布和调试，以防止完全重建。

2) 用于发布和调试的目标文件的输出文件夹发生冲突。

**Note:** This is not an issue with V9 of the NDK. I was seeing this behavior with V8* NDK V9 seems to always us the APP_OPTIM when determining an output object folder.

这与ndk_build参数NDK_DEBUG有关。

当您在没有NDK_DEBUG=0|1 的情况下调用 ndk_build 时，它将检查您项目的 AndroidManifest.xml。如果存在 android:debuggable 标志，它将设置 NDK_DEBUG=1（如果为真）或NDK_DEBUG=0（如果为假）。如果 debuggable 为 true，则文件夹为 local/*abi*/objs。如果为 false，则文件夹为 local/*abi*/objc-debug。

解决方案是从清单中删除 debuggable 标志（如果您的目标是 SDK r8 或更高版本，则不需要这样做）。接下来，如果您想调试幼稚代码，请为您的 ndk_build 调试调用指定 NDK_DEBUG=1 标志。

祝你好运！

【讨论】：

【解决方案2】：

问题在于 ndk-build 将 Application.mk 标记为一切的先决条件。它无法知道只有NDK_DEBUG 改变了。

您可以安全地在命令行上提供NDK_DEBUG 参数。在Eclipse中，你可以创建两个独立的构建配置，一键切换。

【讨论】：