Le produit iPhone / iPad de mon entreprise a émigré plusieurs générations d'iOS et de Xcode (maintenant à 5.1 et 4.3) et a de nombreuses cibles. Peut-être à cause de ces facteurs, il existe de nombreuses lignes identiques pour chaque fichier source de la section PBXBuildFile, par exemple: Notez que les lignes d'un fichier source donné sont absolument (j'avais tort, Ils ne sont pas tout à fait ...) identiques, et le nombre de lignes en double varie de rien à une demi-douzaine ou plus. En raison de cette double duplication, la section PBXBUILDFILE du projet.PBXPROJ est de près de 5 000 lignes de long, bien que nous n'avions vraiment qu'environ environ 1200 fichiers uniques. Avant de piquer un script pour éliminer toutes ces lignes en double et demander le test Pour une régression complète sur toutes les constructions et objectifs, j'aimerais être sûr que Xcode n'a pas besoin de ces lignes en double pour une raison arcanique. Je suis assez certain que cela n'était pas causé par contrôle de version; Les lignes en double apparaissent uniquement dans la section PBXBuildFile et pendant que je n'aime pas P4, nous avons peu de difficulté à fusionner des changements de fichier projet.PBXProj, bien que près de 20 000 lignes, c'est un peu difficile à manier. Je pense que la libération de Xcode a fait cela, peut-être tout en ajoutant de nouvelles cibles, mais je n'ai trouvé que personne d'autre se plaignant de la question. Questions secondaires:
Comment est-ce arrivé? Quelqu'un d'autre a-t-il trouvé ces types de lignes en double?
4 Réponses :
Comme vous voyez que le fichier ref est dupliqué, mais l'ID de fichier à l'intérieur de chaque cibles a une seule différence 14e4CD * 3 * 15A5E69000DCA763, le 8ème chiffre varie plutôt.
Les rats, je ne peux pas croire que j'ai raté cela dans la mer de presque les mêmes identifiants. J'aurais donné une réponse à ce sujet, je vais devoir revenir en arrière et voir comment la carte IDS pour projeter des variantes.
Oui, cela semble que si vous avez plusieurs cibles de construction, cette section les référencera de manière unique une fois par cible. Genre de sens.
J'ai enfin écrit et exécutez le script décapant les nombreuses références de fichier en double. Cela semblait tout à fait inoffensif, mes constructions locales ont tous continué à fonctionner correctement. Je n'ai jamais vérifié ces correctifs, car j'ai changé d'employeurs à ce moment-là, et il semblait impoli de jeter une bombe qui avait potentiel de casser une douzaine d'équipes juste avant de partir.
généralement Xcode génère une référence unique (ID) pour les fichiers référencés dans plusieurs cibles. Je suppose que vous disposez de plus d'une cible de construction et de loginViewController référencée dans les deux qui finit par différents identifiants en fileref. Bien qu'il ait l'air identique mais la retirant en supposant qu'il pourrait être inoffensif peut provoquer des accidents.
Vous pouvez en savoir plus sur le fichier PBXProj à partir de http: //www.monobjc. NET / XCODE-Project-Project-File-Format.html .
Postage pour la postérité, au cas où d'autres courent aussi.
Cela arrive tout le temps lorsque les développeurs travaillent sur des succursales distinctes et par ex. Déplacez des fichiers sur différents dossiers, ajoutez de nouveaux groupes dans le même sous-dossier qu'un autre groupe qu'un autre développeur effectue une modification sur une branche distincte, etc., puis de fusionner que leur projet passe à une branche de base commune. La fusion de fichiers de projet Xcode est son propre type d'enfer, et il n'y a pas de bon moyen de déterminer laquelle de ces références est celle que vous souhaitez conserver; comme @maistor Kokir souligne, l'ID va être unique pour chaque référence, et qu'il est essentiel que vous choisissiez Le bon, car les groupes font référence à des fichiers par ID, et plus important encore, de créer des règles et des cibles se réfèrent également à l'ID.
La seule façon de résoudre de manière fiable ceci est de supprimer toutes les références au fichier en question (dans la zone de construction de la cible de construction | "Compiler les sources"), puis ajoutez-le à nouveau.
et, pour le réparer vraiment à la source, j'ai recommandé que les développeurs effectuent tout projet modifications sur la branche commune (par exemple, une branche de "maître" git), puis fusionnez ce changement de passage à leur Direction du développement. Projet ajouts n'exige généralement pas le même traitement; seulement changements "dans la raison", qui inclurait (mais