Saz*_*han 7 configuration xcode build xcodebuild ios
我一直在做iOS项目。关于Xcode Derived Data内容由构建系统生成的文件夹,有很多 Stackoverflow 帖子,即 如何删除派生数据文件夹或删除派生数据文件夹是否安全等,但没有我正在寻找的内容。我的问题是知道什么时候应该删除派生数据文件夹,什么时候不应该?换句话说,在什么条件下,这些派生数据变得不可重用,为什么?在项目的资源或配置更改或其他任何事情后,这些派生数据是否会过时?我经常看到许多问题在删除派生数据后得到解决,但我们通常不会尝试了解问题的根本原因。
能不能简单的说,直到.xcodeproj文件发生变化,派生出来的数据才能安全复用?
问题背景:在我的项目中,我有一个证明构建系统,因此每个 CL 在合并到远程分支之前都需要通过证明构建。因此,当我应该(或不应该)重用派生数据文件夹以使证明构建系统具有高性能时,我需要了解架构师的风险。
可悲的是,删除DerivedData已成为尝试解决构建问题的万能办法。如您所知,您可以DerivedData在任何时间点删除,不会出现任何问题(当然除非您正在构建)。何时安全的细微差别有点复杂。在实践中,我通常发现构建之间代码的重大更改可能会出现问题。同样,更改 Xcode 版本也可能会出现问题。这里的关键词是“可以”,并不意味着“会”。
我不认为有任何明确的方法可以知道何时进行清除,这就是为什么我认为大多数人通常会问“您是否删除了DerivedData”,这是当某人遇到构建问题时的第一个问题。
IMHO, I think there is some subtle caching that Xcode does within DerivedData, as I've had build failures in weird situations I could not trace. I would not be surprised if Xcode has some subtle bug related to this caching. In general, I only trusted a command line delete of the project's DerivedData. And if I was extra careful, I'd also purge any associated libraries/frameworks as well as the ModuleCache (in DerivedData). There is also some voodoo in the /var/folders. Not sure if this is still the case, but I have found myself surgically nuking stuff there. Yeah, bad. But I'm also the kind of person that has been known to edit the project.pbxproj file to fix it, so I guess I throw caution to the wind.
Let me ask you this question. What is more important? "bullet-proof" or build times? I've been roped into maintaining or upgrading the build systems for a few apps. I've always done everything as a clean build. This always was fresh pull from source control and then having a defined DerivedData within the workspace (these were Jenkins builds and was configured to use a clean workspace). This pretty much avoided build issues related to needing to remove DerivedData. I've seen way too many strange issues occur due to some Xcode voodoo. It is far better to not add red herrings if you have a build error.
If you do find that the builds as well as any tests needed are taking too long, you can start to devise other strategies to help make it more manageable. This becomes very project dependent. For example on a project I was working on, I moved all libs to pre-built versions. For some reason, they had it setup where they had to build all the 3rd party libs (like openssl) during the build process. This also means that the devs incurred this build penalty the first time they built or any time the cleaned.
| 归档时间: |
|
| 查看次数: |
4045 次 |
| 最近记录: |