Bizarre que la syntaxe avec accolades ne fonctionne pas (ça veut dire quoi ne fonctionne pas d'ailleurs ?) mais bon ça fait un bail que j'ai pas utilisé CocoaPods ni fait de Ruby.
La syntaxe que tu as utilisée est une syntaxe compacte (sans accolades) mais du coup arc une seule paire clé/valeur... et manque de pot tu as pas choisi de garder la bonne ^^
La clé "name" donne juste un nom de pod sans indication d'où trouver le podspec. Le nom tout seul n'est pas très utile. Essayé plutôt la clé ":path" à la place, qui elle est bien plus déterminante
Je devais être fatigué, ça fait trop longtemps que j'ai pas fait de Ruby et de CocoaPods, je sais même plus ce qu'attend la commande "podspec" comme type... et dans toutes les solutions que je t'ai donné à testé y'en a aucune qui suit la doc dont je t'ai donné le lien... je devrais mieux la lire et me reposer un peu !
Donc si on se pose 2 secondes et qu'on suit sagement l'exemple donné dans la doc plutôt que d'essayer de faire n'importe quoi (donc sans les accolades) ça marche mieux ?
Bon, du nouveau. C'est vraiment un truc de dingue !
Je ne peux pas podiser les nouvelles branches avec le même .podspec (à la version prêt) car il y a eu du nouveau : ils ont changé le framework de log. Pour l'utiliser, ils ont ajouté les sources dans leur xcodeproj et ajouté ça dans le .pch :
#import "DDLog.h" #if DEBUG
static const int ddLogLevel = LOG_LEVEL_VERBOSE; #else
static const int ddLogLevel = LOG_LEVEL_WARN; #endif
Or, ça, ça n'est pas repris dans le pod quand je le "podifie".
'Tin, je sais plus quoi faire... Je crois que je vais revenir à la méthode du début, sans CocoaPod. Bibli statique et en tenant de faire fonctionner les headers...
Putain mais ils ont vraiment fait du grand n'importe quoi sérieux !!
Il sont passés à CocoaLumberjack (CLJ), mais pour faire ça ils ont copié comme des bourrins les sources de CocoaLumberjack dans leur projet, au lieu de simplement indiquer une dépendance dans le podspec ?!
Alors que CocoaPods c'est aussi fait pour ça et aussi sa grande force, gérer les dépendances ! Comment tu fais toi utilisateur de leur lib si tu utilises déjà CLJ en version 1.1 et que leur lib elle inclut en dur les sources de CLJ 1.0 ? C'est la merde, tu vas avoir CLJ en double dans ton projet, des duplicate symbols et tout... Alors qu'ils auraient fait ça proprement avec une simple dépendance de leur lib vers CLJ (ça s'écrit juste via un truc du genre " dependency "CocoaLumberjack", "~>1.0" " dans le podspec, de mémoire) ça aurait marché tout seul, et toutes ces problématiques de dépendances mais aussi d'inclusion dans le PCH auraient été réglées par CocoaPods...
Non, franchement, plus je regarde plus je vois qu'ils ont fait vraiment leur sauce dans leur coin, sans respecter : - La séparation de librairies dans des projets séparés (ils incluent tout en interne dans leur projet donc sans te laisser le choix si tu as d'autres libs qui utilisent les mêmes dépendances ça va te foutre la merde et t'empêcher de compiler par leur faute) - Sans respecter le semantic versionning (qui n'est pas compliqué : c'est juste un triplet "major.minor.patch" et si tu corriges des bugs sans modifier l'API tu augmentes le patch, si tu ajoutes des méthodes dans l'API mais que les anciennes sont toujours là (donc ça reste compatible avec ton code existant) tu augmentes le minor, et si tu changes l'API et supprimer des méthodes, tu augmentes le major... c'est quand même pas sorcier) - Sans utiliser la gestion de dépendances que permet CocoaPods (c'est son principal intérêt) - Sans faire de tags pour marquer leurs versions et leurs milestones (donc impossible de savoir quand leur code est stable ou quand il est en Work In Progress) - ...
Bref ils sont à contre-courant sur à peu près tout, ils font leurs trucs dans leur coin sans chercher à faciliter l'utilisation de leur librairie et sans respecter une seule des conventions de la communauté.
Moi quand je vois ça ça me donne envie d'aller voir ailleurs (voire développer ma propre lib de SVG), parce que là c'est n'importe quoi leur truc...
Pourquoi ne ma forker leur lib et corriger les quelques soucis d'intégration avec Cocoapods (virer la dépendance statique de CocoaLumberjack et la mettre en dépendance cocoapod, ne plus utiliser le pch etc...) sa prendrai un peu de temps, mais moins que de refaire une lib
Oh oui ! Bonne idée Ali ! Tu me fais une lib SVG en 2/2 ? :-P
Ca me tenterai bien, y compris pour ma curiosité personnelle... mais j'ai vraiment plus le temps !
Pourquoi ne ma forker leur lib et corrigé les quelques soucis d'intégration avec Cocoapods (viré la dépendence static de CocoaLumberjack et la mettre en dépendence cocoapod, ne plus utilisé le pch etc...) sa prendrai un peu de temps, mais moins que de refaire une lib
Oui ça serait une solution en effet.
Après j'ai pas regardé leur API, si elle était bien faite ou si c'était aussi catastrophique que leur intégration... ?
Bon, pour l'heure, je fais avec la bibli statique et j'ai remplacé mes #import <SVGKit/SVGKit.h> par #import "SVGKit.h"... En parallèle, je vois avec le gars pour le "convertir" à popod
Réponses
La syntaxe que tu as utilisée est une syntaxe compacte (sans accolades) mais du coup arc une seule paire clé/valeur... et manque de pot tu as pas choisi de garder la bonne ^^
La clé "name" donne juste un nom de pod sans indication d'où trouver le podspec. Le nom tout seul n'est pas très utile. Essayé plutôt la clé ":path" à la place, qui elle est bien plus déterminante
pareil
Si je met la syntaxe avec accolades, j'ai ça :
Je vais tenter avec la méthode de Jojo.
La méthode que je t'ai donné est très bien quand on est le developpeur de la librairie. Mais tu peux aussi l'utiliser dans ce cas la.
OMG... En fait, c'est une cata cette bibliothèque... Maintenant, voilà que plus une branche ne compile... A cause de leur script post compilation.
J'en perd mon latin. Je vais aller me coucher, j'en peux plus...
Donc si on se pose 2 secondes et qu'on suit sagement l'exemple donné dans la doc plutôt que d'essayer de faire n'importe quoi (donc sans les accolades) ça marche mieux ?
Bon, du nouveau. C'est vraiment un truc de dingue !
Je ne peux pas podiser les nouvelles branches avec le même .podspec (à la version prêt) car il y a eu du nouveau : ils ont changé le framework de log. Pour l'utiliser, ils ont ajouté les sources dans leur xcodeproj et ajouté ça dans le .pch :
Or, ça, ça n'est pas repris dans le pod quand je le "podifie".
Avec le podspec tu peux lancer des scripts pre-install et post-install
http://docs.cocoapods.org/specification.html#pre_install
http://docs.cocoapods.org/specification.html#post_install
Ali y'a pas un paramètre à mettre dans le podspec pour charger le fichier pch ? Je n'ai pas trouvé ça dans la doc.
Edit:
Je viens de voir ça finalement dans la doc.
http://docs.cocoapods.org/specification.html#prefix_header_file
Oh là là . Retour à la case départ !
En indiquant le pch, devinez quoi ?
Ca fonctionne !
MAIS UNIQUEMENT pour le simulateur ! Sur device, des tas de "redefinition of...." issus des headers de SVGKit....
Je vais aller me taper la tête contre des murs... Marre...
Et la lib normalement elle est censé marcher ?
^^
Oui oui, elle marche...
'Tin, je sais plus quoi faire... Je crois que je vais revenir à la méthode du début, sans CocoaPod. Bibli statique et en tenant de faire fonctionner les headers...
Il sont passés à CocoaLumberjack (CLJ), mais pour faire ça ils ont copié comme des bourrins les sources de CocoaLumberjack dans leur projet, au lieu de simplement indiquer une dépendance dans le podspec ?!
Alors que CocoaPods c'est aussi fait pour ça et aussi sa grande force, gérer les dépendances !
Comment tu fais toi utilisateur de leur lib si tu utilises déjà CLJ en version 1.1 et que leur lib elle inclut en dur les sources de CLJ 1.0 ? C'est la merde, tu vas avoir CLJ en double dans ton projet, des duplicate symbols et tout...
Alors qu'ils auraient fait ça proprement avec une simple dépendance de leur lib vers CLJ (ça s'écrit juste via un truc du genre " dependency "CocoaLumberjack", "~>1.0" " dans le podspec, de mémoire) ça aurait marché tout seul, et toutes ces problématiques de dépendances mais aussi d'inclusion dans le PCH auraient été réglées par CocoaPods...
Non, franchement, plus je regarde plus je vois qu'ils ont fait vraiment leur sauce dans leur coin, sans respecter :
- La séparation de librairies dans des projets séparés (ils incluent tout en interne dans leur projet donc sans te laisser le choix si tu as d'autres libs qui utilisent les mêmes dépendances ça va te foutre la merde et t'empêcher de compiler par leur faute)
- Sans respecter le semantic versionning (qui n'est pas compliqué : c'est juste un triplet "major.minor.patch" et si tu corriges des bugs sans modifier l'API tu augmentes le patch, si tu ajoutes des méthodes dans l'API mais que les anciennes sont toujours là (donc ça reste compatible avec ton code existant) tu augmentes le minor, et si tu changes l'API et supprimer des méthodes, tu augmentes le major... c'est quand même pas sorcier)
- Sans utiliser la gestion de dépendances que permet CocoaPods (c'est son principal intérêt)
- Sans faire de tags pour marquer leurs versions et leurs milestones (donc impossible de savoir quand leur code est stable ou quand il est en Work In Progress)
- ...
Bref ils sont à contre-courant sur à peu près tout, ils font leurs trucs dans leur coin sans chercher à faciliter l'utilisation de leur librairie et sans respecter une seule des conventions de la communauté.
Moi quand je vois ça ça me donne envie d'aller voir ailleurs (voire développer ma propre lib de SVG), parce que là c'est n'importe quoi leur truc...
Oh oui ! Bonne idée Ali ! Tu me fais une lib SVG en 2/2 ?
:-P
Pourquoi ne ma forker leur lib et corriger les quelques soucis d'intégration avec Cocoapods (virer la dépendance statique de CocoaLumberjack et la mettre en dépendance cocoapod, ne plus utiliser le pch etc...) sa prendrai un peu de temps, mais moins que de refaire une lib
Oui ça serait une solution en effet.
Après j'ai pas regardé leur API, si elle était bien faite ou si c'était aussi catastrophique que leur intégration... ?
OMG... Ca devient compliqué !!!!
Je vous tiens au jus... En attendant, mon appli n'avance plus
Déjà que j'ai pas bcp de tps à y consacrer. C chaud chaud !
Bon, pour l'heure, je fais avec la bibli statique et j'ai remplacé mes #import <SVGKit/SVGKit.h> par #import "SVGKit.h"... En parallèle, je vois avec le gars pour le "convertir" à popod