Xcode, Abort trap : 6
Bonjour tout le monde,
Je viens de changer de mac et j'ai transférer tout le projet (copier/coller) sur le nouveau mac.
Il manquait plein de librairie, je les ai donc re-télécharger sur leur github respectifs, re-intégré à mon projet en pensant que ça suffirait mais non.
Du coup, j'essaie de comprendre ce que je dois corriger pour que ça compile mais je ne comprends pas vraiment..
Par où je peux commencer à chercher pour comprendre cette erreur ?
Merci de votre aide 
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Par essayer de nous indiquer s'il y a un message d'erreur dans la console ?
Par essayer de localiser la ligne qui pose problème et nous la donner ?
Les fameuses librairie ont toutes la même version qu'alors ?
bah justement, les logs ont l'air assez conséquent.. je met juste la fin du message d'erreur (trop long sinon)
et j'ai du mal à y comprendre quelque chose
Dans l'doute, il faudrait déjà regarder DiscussionsCollectionViewController.swift et sa méthode
imagePickerController(_:didFinishPickingMediaWithInfo:)qui pose déjà un warning.Et j'aurais tendance à dire que ton app est mixée entre du Swift 3 & du 4.2.
En relisant ce qu'il y au-dessus, par exemple,
UIImagePickerController.InfoKeyest en Swift 4.2, et j'pense qu'avant c'étaitUIImagePickerControllerInfoKey, donc j'pense qu'il ne retrouve pas ses petits.Du coup, j'essaie de tout passer en 4.2 ?
J'ai un warning qui m'indique que je peux convertir en Swift 4.2, je le tente ?
ça va pas tout me foutre en l'air ça ?.. il me semble que j'avais déjà testé ça il y a quelque temps et ça avait été une catastrophe
Au pire, je vais faire une copie du dossier du projet, comme ça je pourrai toujours revenir en arrière..
Oui et tu penseras à utiliser un créer un repo git sur ce projet...
Ou bien tu attends Swift 5.0...
Bon et bien la conversion en 4.2 a échouée
Je vais voir si mes librairies ont bien les mêmes versions que sur l'ancien mac comme le conseillait Pyroh ^^
J'ai donc repris les librairies de l'ancien mac et là ça fonctionne.. ça compile, impeccable.
C'était donc bien ça.. merci à vous pour les pistes ^^
Pour les prochains projets, est ce que c'est pas mieux de passer par les pods pour les librairies (avec la version à utiliser dans le pod, etc etc ?)..
ça éviterai ce genre de soucis nan ?
Comment ça ?
Comment tu inclus tes librairies ?
J'installe le librairies manuellement, je glisse le .xcodeproj dans Xcode.
Du coup, j'ai fais un clic droit dessus + "Show in Finder" (sur l'ancien mac) pour retrouver le chemin (ils étaient n'importe où dans mon répertoire de téléchargement, c'était le bordel), je les ai copiés sur le nouveau mac et réintégré au projet.. ça fonctionne
Alors CocoaPods ou pas, peu importe.
L'important est de fixer les versions.
Swift évolue, des noms changent, etc. des APIs passent en dépréciées, disparaissent et de nouvelles apparaissent (AddressBook.framework => Contacts.framework sur iOS par exemple), et donc tes bibliothèques tierces peuvent faire de même, ne pas supporter telle version (Swift, iOS, etc), être incompatibles avec une autre (par exemple, XCode 10 a enlevé le support de libstdc++ et donc les bibliothèques statiques qui se basaient dessus ne fonctionnent plus), etc.
Les ajouter à la main, c'est un peu plus de travail pour mettre les nouvelles versions, il faut enlever la précédente et la rajouter. Ce qui peut-être un peu fastidieux. Pour des bibliothèques statiques, c'est assez simple en soit, mais des flags/dépendances peuvent changer, et il ne faut pas les oublier.
Pour des codes comme AFNetworking, il faut redéplacer tous les fichiers, potentiellement également aussi rajouter des dépendances nouvelles etc.
CocoaPods te permet juste d'éviter ces modifications manuelles (si le podspec est bien fait, mais c'est le cas en général).
Et là, c'est quand tu updates en général qu'un patch, voire une mineure.
Sur un majeur, potentiellement tu auras une modification de code (nouvelles classes, renommage, etc.). Et là, CocoaPods ne fera pas de miracle. Il faudra que tu adaptes ton code.
Dans un podfile, tu peux indiquer le numéro de version que tu veux, laisser des updates "automatiques" de patch ou de mineures uniquement et ainsi t'éviter trop de surprises.
Mais clairement, les dépendances, c'est un partie de notre boulot.
Oui parce qu'il y a encore des cuistres qui sont capables d'introduire des breaking changes sur une minor... (la 6.2.0 de xcodeproj pour ne pas la citer...)
Je n'ai pas en tête l'exemple de ce XCodeProj, mais oui, on peut rendre privée une méthode, ou la renommer.
Mais on espère que cela n'affectera qu'une méthode publique ou deux, pas 36.
Après, pour gérer des changements plus importants, il est intéressant de rajouter une classe d'intégration supplémentaire.
J'ai tendance à faire ça depuis que j'ai dû updater une projet d'AFNetworking X à X+1.
Cela consiste juste à créer une méthode supplémentaire qui cache l'utilisation d'AFNetworking.
En cas de renommage/nouvelle implémentation/logique, tu ne touches qu'à ce fichier (en général, que le code des méthodes en soit, les implémentations, pas les déclarations) car le reste de ton code appelle ce "fichier".
C'est pratique également si du jour au lendemain de passer d'une librairie à une autre (pour diverses raisons, non-maintenue, etc.).
Cas basique : passer KingFisher à SDWebImage. Ces deux codes tiers permettent d'afficher des images avec des méthodes qui se ressemblent.