Après avoir mis à jour Swift + projet ObjC vers Xcode 8 (Swift 2.3), j'ai trouvé 50% ou plus du temps que Xcode effectue une reconstruction complète du projet au lieu d'une construction incrémentielle.
Les modifications apportées ajoutent des instructions d'impression simples. Il ne semble pas y avoir de logique quant au moment où il effectue une reconstruction complète.
Il apparaît dans la phase "Vérifier les dépendances" qu'il décide. Sur Xcode 7, cela ne semblait pas être un problème.
Quelqu'un d'autre a-t-il rencontré cela?
J'ai trouvé que cela fonctionne de manière cohérente, il compilera cependant des fichiers Swift si vous modifiez un en-tête inclus dans l'en-tête de pontage. Il effectuera également une compilation complète si vous changez de branche git dans les deux sens.
Assurez-vous d'abord que le niveau d'optimisation pour le débogage est défini sur Aucun (pas sur l'optimisation du module entier)
Ensuite, selon https://forums.developer.Apple.com/thread/62737 Apple Staff (ddunbar):
Nous pensons que le réglage:
HEADERMAP_USES_VFS = YES
à vrai dans votre projet (ou pour toutes vos cibles) peut être une solution de contournement efficace> pour de nombreuses personnes. Cela n'est pas garanti de fonctionner (c'est la raison pour laquelle il n'est pas> déjà activé par défaut), mais cela devrait fonctionner pour la plupart des projets.
Cela doit être ajouté via "Ajouter un paramètre défini par l'utilisateur" sous vos paramètres de build cibles.
.
Ok, voici une réponse à pourquoi cela se produit, mais je ne connais pas la solution. Si vous utilisez le "Other Swift Flag" -driver-show-incremental Xcode affichera ce qu'il décide qu'il doit compiler en fonction de ses dépendances. Vous verrez des choses comme:
Queuing EditProfileViewController.Swift because of dependencies discovered later
Queuing ChangePasswordViewController.Swift because of dependencies discovered later
Queuing JoinViewController.Swift because of dependencies discovered later
Queuing JoinProfileViewController.Swift because of dependencies discovered later
Queuing FormViewBuildable.Swift because of dependencies discovered later
Queuing RadioTextFormView.Swift because of dependencies discovered later
Queuing TextFieldFormView.Swift because of dependencies discovered later
Queuing AccountProfileViewController.Swift because of dependencies discovered later
Je me demande si c'est un problème Swift 3, car je n'avais pas ce problème avant la conversion. J'ai fait un petit exemple de projet où
FileA inclut une chose de FileB inclut une chose de FileC
et même en ajoutant une modification privée de fichier à FileC qui n'est utilisée nulle part, FileA, FileB et FileC sont mis en file d'attente pour la compilation en raison de dépendances. Je vais tester cet exemple dans Xcode 7 plus tard dans la journée pour voir ce qui se passe.
Il ressemble donc à Swift 3 ne fonctionne pas très bien. J'ai testé cela sur 2 autres Swift 3 projets à l'œuvre, et les mêmes) est vrai. Apportez des modifications à n'importe quel fichier et chaque fichier est compilé. Il ne semble pas lent jusqu'à ce que vous commenciez à accéder à des projets avec environ 15 000 lignes de code, ce qui peut être la raison pour laquelle personne n'en parle beaucoup. À moins que vous avoir une application Swift 3 application de taille moyenne, vous ne remarquerez probablement même pas que la complication incrémentielle ne fonctionne pas très bien. Je mettrai à jour si j'apprends quelque chose de plus.
Apple a publié hier une nouvelle version bêta de Xcode (14 novembre)
Xcode 8.2 beta 2
Et ce problème a été marqué comme résolu dans la note de publication.
Build System
• Xcode ne reconstruira pas une cible entière lorsque seules de petites modifications se sont produites. (28892475)
Ça marche pour moi. La vitesse de construction est revenue comme d'habitude. Tous ceux qui sont confrontés à ce problème devraient essayer!
Décocher "Rechercher les dépendances implicites" dans Modifier le schéma> "Schéma"> onglet Générer l'a corrigé pour moi pour les fichiers de projet. "Copier Swift bibliothèques standard" prend toujours une éternité ..