lib extern plusieurs xcodeproj cf presentation aligator
suite à la video (présentation) workspace, librairies et ressource
je me permets de créer un sujet car le probleme est evoqué dans un autre sujet mais pas évident à suivre.
Pour le moment, je fonctionne avec des repertoires dans le projet pour chacune des librairies externes que j'utilise dans le projet. Les libs ne sont pas copiés dans le projet puisqu'elles sont sur un svn et sont utilisé par plusieurs projets
dans ta méthode, tu copy les libs dans le projet en cochant l'option copy item in group folder if necessary
du coup, ca va copier les dossiers de la lib dans le projet ? si c'est le cas, le projet peut vite grossir
si tu pouvais m'éclairer sur ce point pour éventuellement essayer ta méthode dans de futur projet
merci
je me permets de créer un sujet car le probleme est evoqué dans un autre sujet mais pas évident à suivre.
Pour le moment, je fonctionne avec des repertoires dans le projet pour chacune des librairies externes que j'utilise dans le projet. Les libs ne sont pas copiés dans le projet puisqu'elles sont sur un svn et sont utilisé par plusieurs projets
dans ta méthode, tu copy les libs dans le projet en cochant l'option copy item in group folder if necessary
du coup, ca va copier les dossiers de la lib dans le projet ? si c'est le cas, le projet peut vite grossir
si tu pouvais m'éclairer sur ce point pour éventuellement essayer ta méthode dans de futur projet
merci
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Alors dans ma solution de créer des projets séparés, non cela ne va pas copier les dossiers de la lib dans le projet.
Ce qui se passe, c'est que chaque librairie a son projet et son dossier indépendant, et chaque librairie sera compilée de façon indépendante.
Ensuite une fois la librairie compilée, le binaire généré (le ".a") est du coup dans les "Build Products" de ton workspace, et c'est ce binaire que je lie au projet principal de l'application.
Il n'y a pas de copie du ".a" à proprement parler (le ".a" généré est déjà généré par Xcode dans les Build Products dans tous les cas, on ne fait ensuite que l'utiliser à l'endroit où il a été compilé), ni de copie des fichiers ".m" (qui ne servent à rien pour l'application qui utilise la librairie, puisqu'elle va directement se linker avec le ".a" déjà compilé : les ".m" ont juste servi dans le projet de la lib pour compiler cette dernière en ".a" mais ne sont pas "visibles" aux autres projets utilisant la lib comme le projet de ton appli par exemple, c'est aussi tout l'intérêt d'ailleurs pour pouvoir séparer proprement les différentes fonctionnalités et modules)
Les seuls fichiers qui sont réellement copiés, et encore juste dans les Build Products donc juste pendant la compilation, ce sont les ".h" (headers) qui permettent d'indiquer au code utilisateur de tes librairies quelles sont les méthodes disponibles que tu peux appeler. Mais ça c'est pareil que quand tu fais un framework par exemple, où le framework contient à la fois la librairie et les headers associés pour pouvoir l'utiliser.
@AliGator : je te relance pour nous montrer comment rendre les .m d'une library invisible.
Merci
Pour compiler du code en une librairie une fois pour toutes, que vous pourrez ensuite redistribuer toute seule (enfin avec ses .h pour que les gens puissent l'utiliser quand même, mais sans livrer le code source), le principe est le suivant :
- Compiler comme d'habitude votre librairie (donc faite un projet avec le modèle "Static Library", comme j'ai montré dans mon tuto)
- Livrez la librairie compilée (.a) et ses headers (.h) à votre client
Sur le principe, c'est tout !
En pratique, quand vous compilez la librairie, vous la compilez pour une architecture donnée (par exemple armv7). Pour certains cas Xcode sait vous aggréger plusieurs architectures dans une seule compilation (armv7+armv7s), parce que ces architectures se ressemblent et visent la même cible, mais pas plus.
Du coup vous pourriez livrer 2 versions à votre client (une version malib-i386.a et une version malib-arvm7.a par ex) mais en général vous préférez avoir un unique fichier ".a" qui puisse être utilisé à la fois pour iPhone (armv7/armv7s) et sur le Simulateur (donc avec l'architecture i386), pour pas obliger l'utilisateur de votre librairie à linker une fois avec une version armv7 quand il compile pour iPhone et une vois avec une autre version i386 quand il tester sur Simulateur et à changer sans cesse.
Pour cela, il faut utiliser l'outil en ligne de commande "lipo" qui va permettre d'aggréger 2 version d'une librairie .a en un seul fichier, donc en gros de fusionner vos librairies malib-i386.a et malib-arvm7.a en un unique fichier malib.a
Je te laisse regarder un peu la doc de la commande lipo (tape "man lipo" dans le terminal) pour voir comment elle s'utilise.
Après, pour intégrer ça dans Xcode c'est pas forcément évident, car quand tu build avec Xcode tu build pour une architecture donnée... On peut intégrer ça dans un script de Post-Build mais faut forcer la compilation des architectures manquantes... Donc en général on fait un petit Makefile à côté qui se charge de ça (compilation pour chaque architecture puis exécution de la commande lipo sur les divers ".a" générés pour les aggréger en un unique ".a" que tu peux filer à ton client)
C'est possible ?
Oui à condition qu'il n'y ait pas de dépendance du .h public vers des .h privés (#import ou #include).
Merci pour la réponse. Je vais chercher du coté [font=helvetica, arial, sans-serif]de la commande lipo.[/font]
Une autre question
Bah en fait ce qu'il faut que tu fournisse comme fichier(s) .h c'est le ou les .h publics, ceux qui lui permettront de savoir quels méthodes il a le droit d'appeler et quelles sont les signatures de ces méthodes, pour qu'il sache quoi écrire dans son code quand il veut appeler les méthodes de ta librairie. Si tu as des méthodes privées que l'utilisateur de ta librairie n'a pas à appeler, évidemment autant ne pas lui fournir les signatures de ces méthodes (donc les mettre dans un .h séparé que toi tu utilises en interne mais que tu ne fournis pas au client)
@samir
Quand tu compiles pour le store, tu compiles donc pour iOS Device et pas pour simulateur, donc il te faut absolument l'architecture armv7/armv7s.
Si tu essayes de compiler ton application en armv7 mais qu'elle link avec une librairie qui n'est que i386 et n'as pas armv7, il te mettra une erreur genre "Can't find the appropriate architecture" (enfin dans l'idée) et n'arrivera pas à faire l'édition de lien donc à produire ton application
Mal !
L'application ne se builde pas tout simplement. L'éditeur de liens va râler.
Grillé par Ali qui a tapé ses 10 lignes plus vite que moi mes deux lignes.
En fait, Ali a des petits lutins qui font la saisie de ses idées (une sorte de SIRI quoi !), c'est pour çà qu'il va toujours aussi vite !
Les petits lutins ça n'existent pas. Ali a tout simplement plus de 10 doigts à chaque main.
Juste pour confirmation : Je construit une Library Static et je la build pour device ( sinon sur simulateur on a pas le .a généré, non ?).
Ensuite je fait glisser le .a et tous les .h de ma Library dans le projet principal
Le problème ça ne marche pas.
L'erreur :
_OBJC_CLASS_$_...", referenced from:
objc-class-ref in....o
objc-class-ref in....o
Je viens de voir aussi cette erreur :
StaicLib.a, file was built for archive which is not the architecture being linked (armv7s):
et pourtant j'ai fait un build pour device ( de ma Library) et je vois bien armv7 et armv7s séléctionné dans les configs de la Library.
Merci.