Targets / Configurations / Schemes

Réponses

• yoann Membre

  janvier 2013 janvier 2013 modifié #2

  Bonne réflexion en effet même s'il aurait été plus adéquat de commencer par se présenter dans la section approprié.
  
  
  
  
  
  Pour chaque projet tu peux avoir plusieurs targets qui sont le produit de ton projet. Aujourd'hui c'est principalement utilisé pour ton application et son bundle de test unitaire. Sur iOS il n'y a pas grand chose à  faire de plus. Sur OS X on peut ajouter des outils secondaire comme autre target (par exemple une ligne de commande pour contrôler ton application). Quand il y a plusieurs target sur un projet généralement on va créer une autre target qui est un agrégat des précédentes pour tout builder.
  
  
  
  Avant, jusqu'à  Xcode 3, on pouvait avoir plusieurs configuration (Release, Debug, OptionA, OptionB) qui permettait d'avoir pour une même target plusieurs scénario de compilation (le plus intéressant étant de pouvoir modifier entre chaque config les -D pour la compilation conditionnelle). Aujourd'hui sur Xcode 4 on a plus que Release et Debug, je n'ai pas trouvé comment en avoir d'autres.
  
  
  
  Les schéma c'est le dernier arrivé, un peut bizarre comme truc, ça permet en fait de configurer les scénario de compilation pour choisir la build config et des options d'execution, d'archivage, etc. Le soucis de ce truc c'est qu'on n'est restreint aux scénario proposés par Apple (Build, Run, Test, Profile, Analyze et Archive). On ne peut pas créer un Build for bidule, l'intérêt est donc très limité.
  
  
  
  De ce que tu décris, c'est clairement les configurations que tu devrai toucher, et ensuite ajouter un nouveau schéma qui vient utiliser cette configuration. Mais toujours sur la même target (ne duplique pas les target pour une même application sinon tu va devenir fou à  devoir rajouter les fichier pour chaque cible). Mais comme je disais plus haut, je n'ai pas retrouvé l'option permettant de rajouter des configuration. Si quelqu'un sait comment je suis preneur.
• AliGator Membre, Modérateur

  janvier 2013 #3

  'yoann' a écrit:

  Aujourd'hui sur Xcode 4 on a plus que Release et Debug, je n'ai pas trouvé comment en avoir d'autres.

  Bien sûr qu'on peut en créer d'autres ! Bien qu'en pratique je n'en ai jamais eu l'utilité.
  
  
  
  Si tu veux gérer d'autres configurations, ou baser tes configurations sur des fichiers xcconfig de configuration, etc, sélectionne le projet dans le "Project Navigator" à  gauche, puis dans l'écran qui s'affiche au centre, sélectionne ton projet (et non une des target).
  
  Dans l'onglet "Info" tu vas alors pouvoir gérer les différentes configurations de ton projet, ainsi que les diverses localisations qu'il gère (et même indiquer la configuration à  utiliser par défaut si tu compiles ce projet avec xcodebuild en ligne de commande sans préciser de config spécifique)
  
  
  
  
  
  Moi je décrirais ça comme ça :

  • Les configurations, c'est une sorte de contexte qui définit un ensemble de réglages (de "Build Settings"). Par exemple en Debug, que tu utilises pour développer et mettre au point ton application, donc compiler rapidement car souvent, tu vas vouloir activer certains warnings, choisir des réglages pour le compilateur comme par exemple ne pas s'embêter à  optimiser le code au maximum et garder les symboles de debug... alors qu'en Release, configuration que tu utilises en général pour générer une version finale de ton application, tu vas choisir comme réglage de demander au compilo de faire + d'efforts pour optimiser un maximum la compilation (taille et vitesse de l'exécutable généré), garder les symboles de debug à  part et pas dans l'exécutable, etc, etc
    
  • Les Target, ça correspond à  un produit généré. En général tu n'as qu'un seul target qui va générer une application (.app ou .ipa). Ou si tu as un projet qui génère une librairie, tu as un seul target qui génère une librairie ".a". Eventuellement tu en as une 2e pour générer le bundle de tests unitaires, qui est un peu à  part.
    
    Un target a des réglages (Build Settings) qui peuvent être différents en Debug et en Release par exemple, mais a aussi une liste de fichiers qu'il va compiler. Par exemple ton target de tests unitaires va compiler les fichiers métier de ton application ainsi que les sources de tes fichiers unitaire,s mais le target de ton application ne va pas compiler les fichier de tests unitaires, il n'a pas besoin de les include dans l'application finale. Aussi, si tu voulais générer par exemple 2 versions de ton application, disons une version "Lite" et une version "Pro", tu pourrais imaginer avoir un target "Lite" et un target "Pro", chaque target incluant certains fichiers et pas d'autre, et la target Pro pouvant définir la directive de compilation "PRO=1" te permettant de tester dans ton code "#ifdef PRO" ... "#endif" pour inclure certain bouts de code uniquement dans la version PRO, etc
    
  • Les Scheme, c'est un peu ce qui fait la glue entre tout ça. Un scheme va te permettre de dire "quand je Run l'application, je veux habituellement compiler tels targets, et lancer l'appli sur tel simulateur, avec telle configuration". Ou "quand je lance les tests unitaires, je veux lancer tel target, avec telle configuration, et tel jeu de données de test". Ou encore "quand j'archive mon application, par exemple pour préparer une soumission de mon app à  l'AppStore, je veux utiliser la configuration Release". Ils sont là  en gros pour définir les scénarios de choix entre configuration, target, et autres réglages d'environnement d'exécution, pour t'éviter à  chaque fois de devoir jongler entre les configurations, t'éviter d'avoir à  penser de changer de configuration à  chaque fois que tu compiles pour l'AppStore et pas juste pour tes tests sur le simu, etc, etc. En général automatiquement Xcode génère un scheme par Target dans chaque projet du workspace, pour qu'automatiquement tu aies un scheme te permettant de builder chaque target. Mais ce n'est pas obligé, par exemple ce n'est pas toujours utile d'avoir un scheme pour builder une librairie de ton workspace alors qu'un autre scheme va automatiquement compiler cette librairie avant de compiler ton application et que tu ne vas jamais ou rarement compiler cette librairie toute seule indépendamment de l'appli... donc tu peux toujours supprimer ce scheme si tu ne t'en sers jamais. Tu peux aussi très bien avoir plusieurs scheme qui utilisent tous la même configuration pour l'action "Run", et tous la même configuration pour l'action "Archive", il n'y a pas de lien entre le nombre de scheme et le nombre de configurations.
    
• yoann Membre

  janvier 2013 #4

  'AliGator' a écrit:

  
  
  Bien sûr qu'on peut en créer d'autres ! Bien qu'en pratique je n'en ai jamais eu l'utilité.
  
  
  
  Si tu veux gérer d'autres configurations, ou baser tes configurations sur des fichiers xcconfig de configuration, etc, sélectionne le projet dans le "Project Navigator" à  gauche, puis dans l'écran qui s'affiche au centre, sélectionne ton projet (et non une des target).
  
  Dans l'onglet "Info" tu vas alors pouvoir gérer les différentes configurations de ton projet, ainsi que les diverses localisations qu'il gère (et même indiquer la configuration à  utiliser par défaut si tu compiles ce projet avec xcodebuild en ligne de commande sans préciser de config spécifique)
  

  
  
  
  
  Ah bah il était tellement sous mes yeux que je ne l'ai pas vu !
  
  
  
  Perso je trouve ce truc utile quand tu fais de la compilation conditionnelle (essentiellement sous Mac) et que tu as besoin de plus de détail que du simple Release / Debug.
• AliGator Membre, Modérateur

  janvier 2013 janvier 2013 modifié #5

  J'ai pas dit que c'était pas utile parfois, j'ai juste dit que malgré tous les projets que j'ai fait (certes, essentiellement sous iOS), il se trouve que je n'en ai jamais eu besoin sous Xcode4 et que j'ai pu me contenter de la configuration "Debug" (que j'utilise pour l'action "Run" et "Tests" de mon Scheme) et la configuration "Release" (que j'utilise pour l'action "Archive" de mon Scheme).
  
  
  
  La seule fois où j'ai créé une config perso c'était en Xcode 3 pour me faire une config spéciale "AppStore" différente de ma config "Release" utilisée pour les livraisons OTA, pour permettre de choisir si je devais taper sur le serveur de preprod ou de prod.
  
  Sauf qu'au final au passage à  Xcode4, et avec la possibilité offerte par les Scheme d'automatiquement sélectionner une config différente qd on "Run" et quand on "Archive", je n'en ai plus eu l'utilité et suis revenu au Debug et Release, en ayant configuré mon scheme correctement, car il se trouve que ça me convenait mieux. Mais j'aurais pu garder aussi cette configuration "AppStore" dédiée si j'avais préféré aussi !
  
  
  
  Au final, bien sûr dans certains cas il se peut que ces 2 configurations ne suffisent pas c'est pourquoi tu peux en créer d'autres. C'est juste que pour mon cas en pratique j'ai toujours fini par me contenter des 2 par défaut /wink.png' class='bbc_emoticon' alt=';)' />
• MrT Membre

  janvier 2013 #6

  Bonjour et merci beaucoup pour vos réponses détaillées /thumbsup.gif' class='bbc_emoticon' alt='' />
  
  
  
  Dans mon cas j'ai choisi de garder la même Target, de créer une configuration "Ad hoc" (pour mes builds TestFlight) et de créer un schéma "Ad hoc" (qui utilise la configuration "Ad hoc").
  
  
  
  Ma configuration "Ad hoc" set par exemple "Strip Debug Symbols During Copy" à  NO (à  la différence de Release). Grâce au scheme je peux très rapidement archiver l'application (avec la configuration "Ad hoc" donc) et l'uploader sur TestFlight.
  
  
  
  Encore merci pour ces explications qui m'aident et m'aideront beaucoup /cool.gif' class='bbc_emoticon' alt='8--)' />
  
  
  
  MrT