Ios 在本地计算机上仅使用\u ACTIVE\u ARCH=NO进行编译时，未遇到编译警告

我有一个小问题，我不知道如何解决

在我们的多个项目中，我们希望将“将警告视为错误”（

GCC\u将警告视为错误

）更改为

YES

我们还希望将Xcode默认项目设置“仅构建活动体系结构”（

仅构建活动体系结构

）保留为

YES

，用于调试，而

NO

用于发布

然而，这有一个主要缺点。代码，例如

NSUInteger bob = 12234;
NSLog(@"bob %lu", bob);

应产生以下类型的警告（因此在我们的案例中为错误）：

“NSUInteger”类型的值不应用作格式参数； 改为向“unsigned long”添加显式强制转换

但是，当开发人员在本地构建和测试时，他们不会遇到此警告/错误，但是当他们提交到我们的存储库并且我们的持续集成从命令行运行时，会遇到警告，并且构建失败。这显然相当令人沮丧

我假设这与使用Xcode和从命令行使用

xcodebuild

时构建的体系结构之间的差异有关

我上传了一个样本项目在这里

我已经包括了两个方案。如果您使用“依赖于架构的编译警告”（使用调试构建配置，因此

仅\u ACTIVE\u ARCH==YES

）为iPhone 6S模拟器编译，则不会收到任何警告，编译工作正常。如果使用“架构相关编译警告失败”方案（使用发布版本配置，因此

仅\u ACTIVE\u ARCH==NO

），则会遇到警告，编译失败

---

我想以某种方式确保，在为仅使用

的模拟器构建时，总是会遇到此警告。\u ACTIVE\u ARCH==NO

。这可能吗？

原因是5s出现时字长的变化。换句话说，5s和更高版本的iPhone都有64位处理器，而之前的所有iPhone都有32位处理器

以下是

NSUInteger

#if __LP64__ || (TARGET_OS_EMBEDDED && !TARGET_OS_IPHONE) || TARGET_OS_WIN32 || NS_BUILD_32_LIKE_64
typedef long NSInteger;
typedef unsigned long NSUInteger;
#else
typedef int NSInteger;
typedef unsigned int NSUInteger;
#endif

您可以看到，对于32位处理器，

NSUInteger

被显式定义为

unsigned int

，而对于64位处理器，

NSUInteger

被显式定义为

unsigned long

所以，看看这个代码

NSUInteger bob = 12234;
NSLog(@"bob %lu", bob);

对于4s，此

NSLog

不匹配，因为

NSUInteger

被明确定义为

无符号int

，格式说明符

%lu

是

无符号long

。这种非常明显的不匹配是32位处理器存在警告的原因。对于64位处理器，没有不匹配，因此没有警告

警告中建议的修复方法假定您打算使用

无符号长字符

。然而，这里有一个替代解决方案

NSUInteger bob = 12234;
#if __LP64__ || (TARGET_OS_EMBEDDED && !TARGET_OS_IPHONE) || TARGET_OS_WIN32 || NS_BUILD_32_LIKE_64
NSLog(@"bob %lu", bob);
#else
NSLog(@"bob %u", bob);
#endif

底线是，您试图做的是在不存在不匹配时生成不匹配警告，这既不合适也不可能

编辑：

---

这不是不匹配错误未能显示为警告/错误的情况。事实上，这并不存在不匹配。显示此错误的唯一方法是实际存在不匹配。只有当您针对体系结构进行构建时，才会出现不匹配，

NSUInteger

的定义会在您提到的特定代码中产生不匹配。已经有一种标准方法可以实现这一点：将所有方案的“仅构建活动体系结构”设置为“否”

我认为这是不可能的，但我可能是错的。出现警告的原因是，当需要

无符号长字符时，会传递
无符号int
。因此，当
NSUInteger
为
无符号长时，一切看起来都很好。我可以想象，一个人可以调整构建过程，在成功构建结束时为每个所需的体系结构创建某种标记文件，如果标记文件无效，版本控制会拒绝提交（无论这在细节上意味着什么-如果标记文件比所有源文件都新，那么可能标记文件有效？）。我能够捕捉到这些的唯一方法是始终为“通用iOS设备”构建，即使在调试模式下也是如此，这与仅为_ACTIVE _ARCH=NO具有相同的实际效果（据我所知）。但如果您要这样做，也可能只是为所有ARCH构建，即使在调试模式下也是如此，这显然是不方便的。也许可以调整您的本地单元测试目标（我假设开发人员在提交之前在本地运行），以构建所有ARCH？作为一些实际建议，%zd将正确打印NSInteger，并且不会在任何架构上发出警告，因此，使用%zd将是一个好习惯。@gnasher729 OP使用的是无符号类型，因此我认为他们应该使用
%tu
。对，但这并不能回答如何在所有平台上始终打开这些字长警告的问题。我的键盘电池耗尽，我的答案在我完成之前就提交了。我换了电池，完成了我的回答。我真的很感谢你为了他人的利益花时间修正这个答案。然而，我非常清楚我所描述的行为背后的原因和历史。在我的OP中，我具体要求的是一种方法，以确保这些比我更无知的人，即使他们构建到某些模拟器时，也会出现此错误。这不是一个不匹配错误无法显示为警告/错误的情况。事实上，这并不存在不匹配。显示此错误的唯一方法是实际存在错误。有一种方法可以实现这一点：将所有方案的“仅构建活动体系结构”设置为“否”。我希望这有帮助。干杯