›

bibliothèque statique, headers et device

LeChatNoirLeChatNoir Membre, Modérateur
dans API UIKit #1

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 ?


 


 


«1

Réponses

  • AliGatorAliGator Membre, Modérateur
    novembre 2013 modifié #2
    ça sent un problème de config de SVGKit.


    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...
  • LeChatNoirLeChatNoir Membre, Modérateur
    #3

    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... :-)

  • AliGatorAliGator Membre, Modérateur
    #4

    Oui, ça sent un pb sur SVGKit car il n'y a pas de Copy files mais bien un Copy Header Files...

    Bah cherche pas plus loin, Apple explique dans le lien que j'ai mis pourquoi il ne faut pas faire comme ça...

    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

    Tu t'es bien compliqué la vie ^^

    Mais pas mieux.

    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...
  • LeChatNoirLeChatNoir Membre, Modérateur
    novembre 2013 modifié #5

    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]


  • samirsamir Membre
    #6


    Je sais même pas ce que c'est un workspace... 




    http://vimeo.com/59334757   Présentée par note serviteur @Aligator.

  • AliGatorAliGator Membre, Modérateur
    #7
    +1 samir c'est vrai que c'est un bon début... sauf qu'à  l'époque où j'ai fait cette présentation, je ne connaissais justement pas la subtilité du "Copy Files" à  utiliser à  la place du "Copy Header Files"... donc dans cette présentation justement au niveau des headers je n'apporte pas de bonne solution.
  • LeChatNoirLeChatNoir Membre, Modérateur
    #8

    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...

  • LeChatNoirLeChatNoir Membre, Modérateur
    #9

    Et merci pour la démo :)


  • AliGatorAliGator Membre, Modérateur
    novembre 2013 modifié #10

    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...

    Si tu as glissé un xcodeproj dans un groupe "Frameworks" à  l'intérieur de ton propre xcodeproj, alors non tu n'as pas deux xcodeproj côte à  côte dans un workspace commun, mais un xcodeproj dans un autre...

    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...)
  • LeChatNoirLeChatNoir Membre, Modérateur
    #11

    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 !


  • AliGatorAliGator Membre, Modérateur
    #12
    Ah ben c'est pour ça que j'avais aussi souvenir qu'il n'était pas podifié, c'est que c'était pas le cas à  l'époque, tout s'explique :)

    Cool ça va te faciliter la vie du coup :)
  • jojolebgjojolebg Membre
    #13

    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.


  • AliGatorAliGator Membre, Modérateur
    #14
    Oui c'est ce que je lui conseillais déjà  plus haut et dans un autre thread, s'il utilise déjà  CocoaPods, autant créer le fichier podspec, c'est aussi simple. C'est ce que je fais aussi, genre pour des composants pas podifiés ou des composants certes podifiés mais pour lesquels je veux utiliser une version pas encore releasée (HEAD) ou une branche autre que la master (genre à  l'époque où pour pas mal de composants le portage iOS7 était en WIP sur une branche).
  • LeChatNoirLeChatNoir Membre, Modérateur
    #15

    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...

  • AliGatorAliGator Membre, Modérateur
    #16
    En gros le gr de SVGKit sait pas faire un podspec correct et le faire évoluer au fur et à  meute qu'il release des versions c'est ça ?

    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.
  • LeChatNoirLeChatNoir Membre, Modérateur
    #17

    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

  • jojolebgjojolebg Membre
    novembre 2013 modifié #18

    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:



    
pod "SVGKit", :local => '../svgkit'

    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.


  • LeChatNoirLeChatNoir Membre, Modérateur
    #19

    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.


     


     


     




     


    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.




     


    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 ?

  • jojolebgjojolebg Membre
    #20

    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:


    • Il faudra vérifié avant le pod install, si le repo de svgkit est bien présent sur ta machine, relativement au chemin mis dans le podfile.

    - Avantages:


    • Permet de gagner beaucoup de temps en développement. (si tu t'occupe du developpement de SVGKit par exemple). Car toute les modifications faite sur le repo svgkit local, seront aussi fait sur la version linké de ton projet. Sans avoir besoin de faire les commit necessaire, mais surtout sans avoir besoin de lancé la commande "pod push", qui peut prendre beaucoup de temps (jusqu'à  5 minutes chez moi, et attendre 5 minutes à  chaque modif c'est juste pas possible).
  • LeChatNoirLeChatNoir Membre, Modérateur
    #21

    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...


  • jojolebgjojolebg Membre
    novembre 2013 modifié #22

    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


  • LeChatNoirLeChatNoir Membre, Modérateur
    #23

    Ok. Merci le beau gosse :) Je vais tenter tout ça.


  • jojolebgjojolebg Membre
    novembre 2013 modifié #24

    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.


  • AliGatorAliGator Membre, Modérateur
    novembre 2013 modifié #25
    Alors les solutions que tu as :

    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 :
    • Demandes aux auteurs de SVGKit de créer un tag pour figer la 1.1.0
    • Tu mets ":tag => '1.1.0'" à  la place du ":branch => '1.1.0'" que je t'ai fait modifier au point 1
    • Ensuite, soit tu envoies le podspec aux auteurs de SVGKit pour qu'ils n'aient plus qu'à  le pousser sur CocoaPods/Specs.git sur GitHub, soit tu fais un "pod push" pour pousser ce podspec sur le repo GIT de CocoaPods
  • AliGatorAliGator Membre, Modérateur
    #26
    Ah et sinon tu peux au passage inciter les auteurs de SVGKit à  :
    • 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)
  • AliGatorAliGator Membre, Modérateur
    #27

    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.

    pod push fait plusieurs choses :

    - 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.
  • LeChatNoirLeChatNoir Membre, Modérateur
    #28

    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 :


     


     


    [!] Invalid `Podfile` file: undefined method `keys' for "SVGKit":String. Updating CocoaPods might fix the issue.

     

     #  from /Users/LeChat/Documents/Devel/iPhone4/CAV21/Podfile:4

     #  

     #  pod "MagicalRecord", "~> 2.0"

     >  podspec "SVGKit"

     #  

     

    Mon podspec modifié : 

     



    
Pod::Spec.new do |s|
    
s.name        = 'SVGKit'
    
s.version     = '1.1.0'
    
s.license     = 'MIT'
    
s.platform    = :ios, '5.0'
    
s.summary     = "Display and interact with SVG Images on iOS, using native rendering (CoreAnimation)."
    
s.homepage = 'https://github.com/SVGKit/SVGKit'
    
s.author   = { 'Steven Fusco'    => 'github@stevenfusco.com',
    
'adam'            => 'git.sucks.this.email.doesnt.exist@mailinator.com',
    
'adamgit'         => 'adam.m.s.martin@gmail.com',
    
'Kevin Stich'     => 'stich@50cubes.com',
    
'Joshua May'      => 'notjosh@gmail.com',
    
'Eric Man'        => 'meric.au@gmail.com',
    
'adamgit'         => 'git.sucks.this.email.doesnt.exist@mailinator.com',
    
'Matt Rajca'      => 'matt.rajca@me.com',
    
'Moritz Pfeiffer' => 'moritz.pfeiffer@alp-phone.ch',
    
'Steven Fusco'    => 'sfusco@spiral.local',
    
'Eric Man'        => 'Eric@eric-mans-macbook-2.local' }
    
s.source   = { :git => 'https://github.com/SVGKit/SVGKit.git', :branch => "v1.1.0" }
    

    
s.ios.source_files = 'Source/*{.h,m}', 'Source/**/*.{h,m}'
    
s.libraries = 'xml2'
    
s.framework = 'QuartzCore', 'CoreText'
    
s.xcconfig = { 'HEADER_SEARCH_PATHS' => '$(SDKROOT)/usr/include/libxml2' }
    
end

  • AliGatorAliGator Membre, Modérateur
    #29
    Ah oui le champ "podspec" attend un dictionnaire et pas une chaà®ne. Du coup forcément qu'il arrive pas à  déterminer les keys d'une chaà®ne ;)


    Donc faut écrire un truc genre :
    podspec { :name => 'SVGKit', :path => 'SVGKit.podspec' }
  • AliGatorAliGator Membre, Modérateur
    #30
    PS : quand je vois les adresses des auteurs façon "git.sucks.this.email.doesnt.exist" et que je vois qu'ils sont si nombreux dans la liste des auteurs donc à  maintenir leur lib, je me dis qu'ils sont quand même pas doués si à  autant ils sont même pas capables de maintenir proprement leur lib pour leurs utilisateurs ^^
  • LeChatNoirLeChatNoir Membre, Modérateur
    novembre 2013 modifié #31

    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'


    Il ne me met plus d'erreur (La syntaxe podspec { :name => 'SVGKit', :path => 'SVGKit.podspec' } ne fonctionne pas).

     

    Mais il ne m'installe pas non plus SVGKit :(

Connectez-vous ou Inscrivez-vous pour répondre.