Problème lors de l'utilisation de Cocoapods avec un projet existant
Bonjour,
j'ai assez récemment commencé à utiliser Cocoapods, et là je viens de rencontrer un problème sur un projet ou j'utilise AFNetworking. Initialement j'avais incorporé ce frameworks "manuellement", je l'ai maintenant retiré pour le remettre via un Podfile qui contient
platform :ios, '6.0'
pod 'AFNetworking'; '2.3.1'
suivit d'un pod install
comme je l'avais pour des projets "nouveau", le workspace s'est bien créé et il y a bien un projet Pods ajouté à mon projet dans le workspace.
Cependant ca a bloqué "cruellement" au link, avec des messages du genre
Undefined symbols for architecture armv7:
"_OBJC_CLASS_$_AFHTTPResponseSerializer", referenced from:
avec le différentes classes où il est invoqué et idem pour différents symboles provenant d'AFNetworking.
Au début j'ai vérifié s'il ne s'agit pas d'un problème d'architecture, mais, sur ce projet j'ai plusieurs targets et le projet compile sans erreur pour la première target de la liste (qui fait aussi usage du même framework).
De ce fait j'ai tendance à penser que le workspace séparant le projet Pods de mon projet initial, le fait de compiler pour une target devrait signifier que le problème ne vient pas du projet "Pods".
Ensuite je me suis souvenu qu'en ouvrant le projet à partir du workspace j'avais appelé sans le vouloir Xcode6, donc j'ai virer le workspace le pod et le lock et généré à nouveau un workspace que j'ai ouvert dans Xcode5, et là même problème...
Je suis allé dans Configuration dans les settings globaux de mon projet, Pods est bien sélectionné globalement (la première fois il ne l'était qu'au niveau de ma première target), à la fois en Debug et en Release.
Quelqu'un a une idée ?
Denis
Mots clés:
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Regarde comment elle est configurée et applique les mêmes réglages.
Ceci est un comportement connu (et qu'on espère changer dans les prochaines versions car on est d'accord que c'est déroutant) :
- Tous les pods qui sont listés à la "racine" du podfile ne sont intégrés qu'à la première Target. L'objectif est que cela colle avec la l'usage le plus courant d'un projet qui n'a qu'une target de type App et une target de type Tests, pour ne linker qu'avec le target de l'app
- Tous les pods qui sont listés à l'intérieur d'un groupe "target XXX do ... end" pour n'ajouter ces pods qu'à ce target donné, se trouvent hériter aussi des pods listés à la racine (sauf si tu spécifies "exclusive => true" sur le target dans le Podfile).
On a conscience qu'il y a un problème de consistance (le premier point est là pour que ceux qui débutent dans CocoaPods puissent avoir un Podfile super simple à juste lister des pods et que ça marche, mais du coup ça va un peu en contradiction avec le 2e point...). On évoque la question ici et c'est prévu depuis qques temps de faire une refonte sur ce point (cf cette issue GitHub), mais pour l'instant on n'a toujours pas eu le temps. L'objectif est d'arriver là mais on n'y est pas encore... (et le jour où on y passera faudra qu'on réfléchisse à comment faire faire la transition pour les Podfiles déjà écrits...)En attendant mieux, le plus simple est :
- Soit de linker (modification de ton App.xcodeproj à la main) le 2e target à libPods.a (car pour l'instant seul le 1er target est linké à libPods.a), exactement comme c'est le cas pour la 1ère target. C'est ce que décrit Céroce, et c'est sans doute le plus simple si tu sais que tes 2 targets auront toujours les mêmes pods.
- Soit de définir tes "target XXX do" dans ton Podfile pour chaque target, et de ne plus vraiment mettre de pods à la racine finalement. (Quitte à utiliser une fonction Ruby pour lister les pods communs et se contenter t'appeler cette fonction dans les blocs "targetXXX do", pour éviter de les répéter, comme il est fait ici).
En tout cas c'est clair que dans ce cas-là on a des choses à améliorer, en attendant il faut fixer le pb à la main dans le App.xcodeproj (mais au moins tu n'as à le faire qu'une fois pour toutes).Cela aura pour impact que tu n'auras plus de "libPods.a" (lib qui contient les pods listés à la racine, là si tu n'en a plus y'aura plus de libPods.a du coup) mais que des "libPods-Target1.a" et "libPods-Target2.a" (libs qui contiennent les pods listés pour chaque target). Du coup il faudra peut-être, à l'inverse, enlever libPods.a de la liste "Link Binary with Libraries" dans le 1er target de ton App.xcodeproj
merci pour les réponses.
Ali, j'ai adopté la première solution (dès que je vois le mot "simple" j'ai un réflexe compulsif). En fait j'ai commencé par ajouté libPods.a dans la phase de link de ma target et cela a fonctionné, mais c'est du provisoire car la librairie static n'est construite que pour la première target (mais j'ai eu le "instant gratification"). Je vais examiner tout cela et ensuite je vais ensuite aussi différencier mes pods selon les targets comme tu l'avais suggéré pour les customizations