bibliothèque statique, headers et device
LeChatNoir
Membre, Modérateur
Salut,
Je me heurte à un problème de header...
Dans mon projet, j'ai inclut SVGKit. J'ai inclus le projet dans le mien, j'ai mis la bibliothèque en dépendance et j'inclus avec #import <SVGKit/SVGKit.h>
Tout va pour le mieux dans le simu.
Or, quand je choisis mon téléphone pour tester dessus, j'ai une erreur de pré compilation :
SVGKit/SVGKit.h file not found
WTF ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
1. Quand tu dis "j'ai inclus le projet SVGKit dans le mien" tu veux plutôt dit que tu l'as inclus dans ton workspace j'espère (et pas dans ton projet en tant que subproject comme c'était la mode du temps de Xcode3 mais n'est plus du tout d'actualité) ?
2. Le projet qui build SVGKit est-il correctement configuré avec en particulier une phase "Copy Files" qui copie les headerdoc au bon endroit ? (Et surtout pas une phase "Copy Header Files" qui n'est pas ce qu'il faut contrairement à ce qu'on pourrait penser)
Vu ce que j'ai déjà vu de la lib, qu'elle est pas toute jeune et n'est même pas sur CocoaPods, ça ne m'étonnerait qu'à moitié que l'auteur n'ait pas suivi les instructions de base d'Apple pour correctement configurer la lib et son intégration en particulier la partie où il doit configurer les headers que ça lib doit exporter...
Oui, ça sent un pb sur SVGKit car il n'y a pas de Copy files mais bien un Copy Header Files...
Alors voilà comment j'ai procédé :
=> j'ai copié le répertoire SVGKit avec les sources dans mon répertoire projet.
=> J'ai glissé /déposé le .xcodeproj dans mon projet
=> J'ai ajouté la bibliothèque SVGKit en "Target dependencies" de mon appli (pour qu'elle soit compiler d'abord)
=> J'ai ajouté la bibliothèque dans la phase de link des bibliothèques nécessaires
En simu, pas de sushis, ça compile et ça fonctionne.
En device, ko comme décrit ci-dessus.
Donc je suis allé dans les build settings de la bibliothèque, j'ai viré la phase de copie des headers et j'ai ajouté une simple phase "Copy Files" dans laquelle j'ai paramétré "Product directory" en destination, include/${PRODUCT_NAME} en subpath et j'ai glissé SVGKit.h dedans.
Mais pas mieux. Il faut savoir que dans mon XCode, je lui demande de tout compiler dans un répertoire buildTmp. Je sais pas si ça joue...
A la compilation, il me créer :
=> Debug-iphoneos
=> include
=> SVGKit-iOS.1.1.0pre
=> SVGKit.h
=> ClimbingAway
=> libSVGKit-iOS.1.1.0pre.a
Du coup, dans mon projet à moi, j'ai ajouté "${PROJECT_DIR}/SVGKit-iOS.1.1.0pre" dans mes Headers Search Paths mais rien n'y fait...
Je sèche... :-)
Tu t'es bien compliqué la vie ^^
Pas trop étonnant, si tu es resté avec un projet dans un projet, au lieu d'utiliser un workspace.
Normalement ce qu'il faut faire :
* Créer un workspace
* Mettre dans ce workspace ton xcodeproj à toi et celui de SVGKit
* Ajouter libSVGKit.a dans la Build Phase "Link Product with Libraries"
Et c'est tout.
Avec les workspaces, pas besoin de définir de dépendance explicite (contrairement à comme tu le fais quand tu fais avec un sous-projet dans un projet) il voit tout seul la dépendance implicite du fait que dans ton projet à toi tu vas avoir un libSVGKit.a dans la liste des fichiers, qui viendra des "Build Products" (vérifie quand même, en le sélectionnant dans le Project Navigator et en regardant ensuite dans le File Inspector à droite, que libSVGKit.a est bien référencé en "Relative to Build Products" quand même).
Pas besoin de copier les fichiers non plus, du moment que la Build Phase "Copy Files" est bien configurée, ce qui n'était pas le cas dans le projet SVGKit mais ça tu l'as corrigé.
Faudrait p'tet faire une Pull Request à l'auteur de SVGKit pour qu'il corrige tout ça, sa phase "Copy Files" d'une part et puis créer un podspec pour sa lib d'autre part, ce qui simplifierai énormément la procédure d'utilisation de sa lib, parce que là c'est pas au point son truc...
Merde, tu veux dire que je suis à la ramasse ? Que je pratique des méthodes complètement dépassées ?
Qui datent de XCode 3 ?
\o/
Je sais même pas ce que c'est un workspace... Tout ce que je sais, c'est que j'ai des bibliothèques que j'ai ajouté avec CocoaPod. Donc maintenant, j'ouvre un workspace, pas juste mon projet.
Donc faut que je vire mon "sous projet" SVGKit et que je l'ajoute dans mon workspace si j'ai bien compris... Je sais pas encore comment mais je trouverai.
++
[edit]
Ah mais non. Je pense que j'ai bien fait comme il faut. La première partie copie, c'est juste le répertoire contenant le projet SVGKit que j'ai copié dans mon répertoire de dev à moi, c'est tout. J'ai pas tout inclu dans mon projet XCode...
Et ajouter le .xcodeproj dans mon projet XCode, je pense que ça revient à ajouter la lib au workspace. La dépendance, il l'a peut être effectivement ajouté tout seul...
Bref, faut que je me replonge dedans...
Merci !
[/edit]
http://vimeo.com/59334757 Présentée par note serviteur @Aligator.
ok. Alors j'ai fait comme il faut.
C'est juste que le xcodeproj et SVGKit, je l'ai glissé dans "Frameworks" de mon projet à moi... Mais ça doit rien changer...
Et merci pour la démo
C'est un peu comme si tu mettais un dossier dans un autre au lieu de les mettre côte à côte dans un dossier parent.
---
Mais mais mais... je viens de relire que tu utilises CocoaPods... et je viens de revérifier j'avais supposé que tu faisais ton intégration à la main parce que SVGKit n'était pas sur CocoaPods... mais en fait il y est !
Du coup, pourquoi t'embêter à faire l'intégration de SVGKit à la main dans ton workspace, alors que tu utilises CocoaPods et donc qu'il est là pour ça ? Tu rajoutes la ligne "SVGKit" dans ton Podfile, tu fais un "pod update", et c'est fini, pas besoin de t'embêter avec cette intégration à la main du coup !!
Puisque tu a l'air de déjà utiliser CocoaPods (sans doute pour d'autres librairies), pourquoi n'as-tu pas utilisé CocoaPods aussi pour SVGKit aussi du coup ?
(Nan parce que depuis le début on s'embête dans des explications pour l'intégration à la main, alors que rajouter une ligne dans le Podfile c'est tellement plus simple...)
Il est cocoapodisé ?
Ah ben ça y est, ils ont mergé toutes les branches !
En fait, je bossais avec un fork d'adam car la branche officielle était très vieille et non maintenue.
J'avais lu dans leurs issues qu'ils bossaient à tout merger mais ils l'ont fait il y a 8 jours seulement !
Parfait ça :-P
Je vous tiens au courant !
Et merci pour ttes les explications !
Cool ça va te faciliter la vie du coup
Même si un projet n'est pas podifié, il est très facile d'en podifié un.
Car contrairement a d'autre gestionnaire de dependance dans d'autre technologie (composer pour php, npm pour nodejs etc...), il est pas nécessaire d'avoir le Podspec (fichier qui décrie le pod) à la racine du projet, mais on peux l'avoir n'importe ou sur son disque dur.
J'ai donc déjà podifiais des projets qui ne l'étés pas, et qui ne m'appartennés pas, pour pouvoir les intégrer facilement avec mes projets qui utilise cocoapods.
Si quelqu'un veut plus d'explication, il suffit de demander.
Bon ben mettons nous à table alors :-P
Car après avoir utilisé CocoaPod, j'étais super content car ça fonctionnait nickel.
Sauf que... Je me suis mis à avoir des bugs un peu partout.
Après en avoir causé sur le github de SVGKit, les mecs m'ont répondu que ces bugs, ils les ont corrigé depuis bien longtemps et que c'est parce que j'utlise CocoaPod que ça merde. Ils connaissent pas du tout et veulent virer le support CocoaPod...
Du coup, j'ai refait machine arrière et je me recasse les dents avec les headers....
Raaaaaaa.... J'en perd mon latin.
Alors si l'un de vous 2 peut me guider... Je veux bien faire évoluer le "pod" de cette bibliothèque mais je connais vraiment pas... Y a un rapport avec les tags du repository Git ou pas ?
Merci d'avance...
Si au moins il release des versions proprement, ce qui n'est pas gagné...
- est-ce qu'il tag régulièrement son repo GIT au moins ? (Car oui il y a un lien)
- est-ce qu'il respecte le semantic versionning (semver.org) au moins ?
Créer un podspec c'est pas la mort. Le maintenir c'est encore plus simple (ils doivent pas être doués ^^) puisqu'il suffit d'incrementer la version (en respectant le semver évidemment sinon ça n'a aucun sens et aucune logique)
Au pire s'ils savent pas faire tu peux le faire toi-même le podspec c'est pas sorcier. Par contre s'ils taguent n'importe comment leur repo (voire encore pire, pas du tout) là c'est une autre histoire. Tu peux toujours t'en sortir (tu fais pointer le podspec vers un n° de commit plutôt qu'un nom de tag c'est que dalle) mais c'est moins lisible et plus facile de s'emmêler les pinceaux que s'ils faisaient de suite bien les choses comme tout le monde.
oui, t'as tout compris.
Ils ont un seul tag : 1.0 qui correspond à une version d'il y a qques mois.
Depuis, il y a eu une branche 1.1.0 qui semble être une version corrigeant pas mal de choses et notamment, tous les bugs auquels je me suis heurté.
Et une branche 1.x qui est la branche en cours de dev.
Du coup, la solution serait sans doute de "tagger" la branche 1.1.0 avec le tag 1.1 et de faire évoluer le podspec en conséquence ? C'est ça ?
Je vais me pencher sur les podspecs...
A+, je te laisse finir ta nuit :-D
Ce que tu peux faire c'est cloner le repo SVGKit sur ta machine, switcher sur la branche 1.1.0, et dans ton Podfile tu met ça:
Et rajouter le fichier SVGKit.podspec à l'interieur du repo. Normalement il ne devrait pas être beaucoup different du podspec de la branche Master.
Dans mes projets je travail souvent avec des pod locals, c'est un très gros avantage pour le développement.
Sinon tu peux aussi cloné la librairie, switcher sur la branche 1.1.0, rajouter le Podspec à l'interieur du repo, et lancé la commande qui enverra le podspec sur le repo public de cocoapod. J'ai vu le podspec de la version master, et il est plutot simple, donc a coup sur le pod spec de la branche 1.1.0 sera identique sauf pour le tag.
oui ! Je viens de creuser un peu et j'ai compris que les podspec étaient sur le repo de CocoaPod. J'ai trouvé celui de SVGKit et effectivement, ça colle. Ca point vers le tag 1.0 qui est vieux.
Je vais donc demander aux gard de SVG de tagger la 1.1 et faire évoluer le podspec vers le tag 1.1.
Je vais tenter. Mais je suis un peu léger en git en fait... J'avais cru comprendre qu'il fallait cloner le repo de cocoapod (les specs), faire la modif, et faire une "pull request". C'est pas ça ?
Dans le principe c'est ce qui est fait, mais tu ne clones pas le repo de cocoapod à la main (c'est déjà fait à l'installation de cocoapod), il y a une commande "pod push" qui permet de vérifier si le Podspec et valide, et qui va le publier sur le repo de cocoapod.
Mais tu peux aussi faire la méthode que je t'ai donner, ce qui je pense est plus facile, c'est à dire le faire en local sans rien envoyé sur cocoapod. Bien sur cet technique à c'est défauts et c'est avantages:
- Inconvénients:
- Avantages:
Je comprend que je peux le faire en local. Mais dans l'idée, j'aimerai partager ça et éviter ces prises de têtes à d'autres...
Donc dans l'ordre, je fais quoi au final ?
Je clone SVGKit (la branche 1.1.0)
Je met SVGKit.podspec à sa racine (après l'avoir modifié)
Je teste à la limite en modifiant mon podfile à moi en local.
Je vais un pod push depuis la racine de mon SVGKit ?
Désolé hein, je suis noob dans le domaine...
C'est tout a fait ça, et ton intention est louable.
Tu disposes principalement deux commandes:
pod spec lint: qui permet de vérifié si ton podspec est valide (cf pod_spec_lint)
pod push: Si ton podspec est valide, il le commit sur cocoapod (cf pod_push)
Tu peux aussi ajouter les options --allow-warning et --only-errors, qui permet de laisser passé les warnings de compilation (peut parfois être necessaire si nos dépendances ont des warnings).
Plus d'info sur ce lien
Ok. Merci le beau gosse Je vais tenter tout ça.
En survolant le dernier lien, je m'aperçoit qu'il indique de cloner le repo cocoapod, puis d'ajouter le podspec et ensuite de faire un pull request.
Je t'avoue que je n'ai pas encore partagé mes podspecs avec la communauté, mais seulement partagé les podspecs sur un repo privé de ma boite, et pour ça la méthode "pod push" fonctionne. A voir, si ça fonctionne aussi avec le repo public de cocoapod.
1) Soit tu veux juste utiliser la branche 1.1.0 de SVGKit tout seul dans ton coin
Dans ce cas, pas besoin de cloner manuellement SVGKit, tu copies juste le dernier SVGKit.podspec (qui se trouve dans le repo de CocoaPods/Specs.git sur GitHub) dans le dossier de ton projet (au même niveau que le Podfile), puis tu édites ce fichier podspec pour l'adapter :
- tu mets "1.1.0" en face du champ "version"
- dans le champ "source", tu mets ":branch => "1.1.0" à la place de ":tag => 1.0" pour dire à CocoaPods d'aller chercher le dernier commit de la branche nommée 1.1.0 (et non pas le tag nommé "1.0" comme c'est le cas dans le podspec actuel)
- et dans ton Podfile au lieu de mettre "pod 'SVGKit'" tu mets "podspec 'SVGKit'" pour lui dire d'aller lire le fichier podspec plutôt que cherche le pod dans le repo central (voir doc)
En faisant ça, quand tu vas faire un "pod update" il va aller chercher les infos concernant SVGKit d'après ton podspec local de cette lib (que tu auras donc adapté) et non d'après le podspec qui est sur CocoaPods.Specs.git sur GitHub (qui est trop vieux).2) Si maintenant tu veux en faire profiter tout le monde :
- taguer régulièrement leur repo, en respectant le Semantic Versionning (derrière ce nom barbare ce cache simplement un concept très simple à respecter pour permettre d'avoir une numérotation logique des versions d'un composant)
- Mettre leur podspec à la racine de leur repo (en + de le mettre sur CocoaPods bien sûr), car cela permet d'une part aux gens de pointer encore plus facilement sur la HEAD de leur repo au cas où ils auraient besoin (pour ceux qui veulent utiliser la toute dernière version même si elle n'est pas encore considérée stable et donc pas encore taguée) mais surtout parce que ça leur faciliterait la maintenance (pour publier une nouvelle version il leur suffira de faire un tag, de mettre à jour le podspec pour indiquer ce nouveau numéro de version, puis de faire "pod push" pour pousser ce podspec local sur CocoaPods tout seul au bon endroit dans le bon dossier de CocoaPods/Specs.git et tout.
Mais bon c'est sûr que s'ils ne participent pas un peu à cet effort collectif, ça va pas aider les gens voulant utiliser leur librairie voire ça va leur compliquer la vie...Alors que ce n'est pas grand chose à faire de leur part pour que ça marche : juste taguer régulièrement son repo, maintenir un fichier podspec local en conséquence, et exécuter "pod push" pour partager cette version... (alors que s'ils ne le font pas c'est aux utilisateurs comme toi de maintenir tout ça, se débrouiller avec, et de savoir si le GIT de SVGKit peut être considéré comme une version stable (taguée) ou pas (Work in Progress), etc... bref pas cool pour leurs utilisateurs)
- Vérifie la validité du podspec local, à l'aide de "pod spec lint", ce qui vérifie à la fois qu'il n'y a pas d'erreur de syntaxe dans le fichier podspec, qu'il n'y a pas d'incohérence dans le podspec (utilisation d'un champ inconnu ou déprécié, etc), et que le pod compile correctement (pas de dépendances manquante, etc).
- Fait un "git stash save" si besoin
- Fait un "git pull" sur le repo "~/.cocoapods/repos/master" pour s'assurer qu'il est à jour et récupérer son dernier état
- Crée un dossier du nom du composant dans "~/.cocoapods/repos/master" (par exemple "~/.cocoapods/repos/master/SVGKit") s'il n'existe pas déjà
- Crée un sous-dossier dont le nom correspond à la version du composant, par exemple "~/.cocoapods/repos/master/SVGKit/1.1.0"
- Copie le podspec local (SVGKit.podspec) dans ce sous-dossier : "~/.cocoapods/repos/master/SVGKit/1.1.0/SVGKit.podspec"
- Commit ce fichier (git add + git commit)
- Push ce commit (git push)
- Restore l'état du repo (git stash apply) si besoin
Ce qui marche très bien si, comme moi, tu as les droits sur le repo CocoaPods/Specs (je fais partie de la team CocoaPods). Comme ce n'est probablement pas ton cas, cela va rater au moment du "git push" puisqu'il va dire que tu n'as pas les droits.
Du coup le plus simple si tu n'as pas les droits de contributions à CocoaPods/Specs, c'est de faire un fork de CocoaPods/Specs.git sur ton compte GitHub, le cloner dans "~/.cocoapods/repos/myspecs" par exemple, puis de faire "pod push myspecs" au lieu de juste "pod push".
Comme ça ça va faire toutes les étapes décrites plus haut... mais sur ton fork à toi (sur lequel tu as les droits de pusher, évidemment). Et il suffira alors après cette étape de créer une "Pull Request" depuis l'interface de GitHub pour demander à ce que ton tork soit mergé avec le repo officiel de CocoaPods et donc que le podspec que tu viens d'ajouter avec ton commit sur ton repo soit pris en compte et intégré au repo officiel.
Merci pour ttes ces réponses.
Je vais faire les 2 méthodes au final :
=> la première pour pas etre bloqué
=> la 2eme pour contribuer un peu au truc.
J'ai donc commencé par la première.
Mais quand je fais un pod update, j'ai ça :
Donc faut écrire un truc genre :
oé... Y a aussi pas mal de "Apple sucks" ou "Because of Apple bug"...
Mais bon, pas le choix... Y a que leur lin qui tient la route à priori.
Donc maintenant, avec podspec :name => 'SVGKit'