Si vous pensiez cela, vous êtes aussi loin de la vérité que je suis loin de chez moi (notez que ça dépend de la date à laquelle vous me lisez, et je vous conseille de vous dépêcher). J'écris cette petite page pour rapporter un peu mon expérience de Xcode dans un projet qui n'utilise (presque) pas Cocoa, et pour vous montrer comment utiliser Xcode pour vos travaux de développement "ordinaires".

Je pense que Xcode a pas mal d'avantages, et je parie que vous en connaissez déjà quelques-uns. L'éditeur est joli, pratique (complétion automatique sympa, code folding...) et intégré à tout le reste (les erreurs sont signalées, par exemple), l'application est légère (alors que mon Netbeans, il est bien sympa mais je crois que j'ai pas dû désactiver l'option qui transforme ma machine en 486) et permet de travailler sur plusieurs projets sans s'arracher les cheveux, ça réagit comme un programme Mac, c'est super génial, tout ça.

Dans le cadre d'un des cours de ma formation universitaire actuelle, à Sherbrooke, il est question d'un projet devant respecter des contraintes temps-réel. C'est pas trop le sujet de discuter temps réel ici, mais c'est juste pour dire que mon cher collègue Gafar (celui qui m'a donné l'idée d'écrire cet article à partir de notre expérience) et moi même avons la chance d'être des gros bébés, et vu que nous devons finaliser une étape importante de notre projet (si injustement nommé Mon piano d'amour) à la fin de cette semaine, nous avons envisagé l'utilisation collaborative de Xcode pour notre projet.

Malheureusement, nous avions peu de temps pour rédiger une sorte de cahier des charges de notre projet, et nous dûmes nous résoudre à utiliser des choses assez proches des enseignements de notre professeur magique, le vénéré Patrice Roy, pourfendeur des mauvaises pratiques, protecteur de la veuve et de l'orphelin, craint dans toute la galaxie, notamment parce qu'il sait lancer des chevrons plus vite que son ombre. Nous nous sommes donc arrêtés sur les choix technologiques suivants : utilisation du langage C++ et des bibliothèques SDL et Portaudio.

Avec ces choix, l'idée de travailler avec Xcode paraissait impossible. Et pourtant, la disponibilité d'un modèle de projet Xcode pour SDL m'a redonné la confiance que je semblais avoir perdu à jamais ! Le codage pouvait être envisagé avec Xcode, et il y avait même mieux puisque cet environnement de développement permet de travailler avec un système de gestion de versions comme SVN, ce qui permet d'accélérer le travail !

Nous sommes d'abord parvenus à faire deux ou trois unités de compilation de manière totalement désorganisée, sans plan, et nous avons pensé à un truc : le prof, aussi cool soit-il, il trouve vim dépassé, mais ça on s'en fout, et pire encore, il n'a pas Mac OS X ! Et il aimerait bien pouvoir jouer avec son piano d'amour lundi prochain... Nous avons donc cherché à gérer une structure qui puisse être multiplateforme et bien organisée. Nous avons trouvé : les fichiers spécifiques à OS X sont bien rangés, tout comme ce qui est spécifique aux autres plateformes, et ce qui est commun est rangé à une place commune.

On va donc voir comment procéder pour mettre en place un projet multiplateforme qu'on peut développer avec Xcode.

Je vous conseille d'abord de faire un petit changement dans votre configuration de Xcode. Ce changement concerne l'endroit où seront stockés les résultats de la compilation de toutes vos applications : il vaut mieux garder ces builds très volumineux en dehors des répertoires des projets, car cela permet de ne pas polluer le projet et alourdir le répertoire qui le contient. La configuration de cet endroit se fait dans les préférences de Xcode au rayon Building (à ne pas confondre avec les immeubles du même nom).

C'est plus pratique lorsqu'on utilise un système de gestion de versions, par exemple, et qu'on est amené à souvent mettre à jour les fichiers concernés par un projet, et de manière générale ça permet de pouvoir éliminer tous ces produits de compilation intermédiaire en une fois !

Avant toute chose, prenons un répertoire bien vide, affublé d'un nom évoquant le projet à réaliser. À tout hasard, je suggère "monpianodamour". Assurons-nous qu'il ait une structure assez commune. Je propose de créer un répertoire par plateforme prévue : windows, linux, macosx (vous êtes libre d'en rajouter ou d'en enlever). Ces répertoires accueilleront tout ce qui est spécifique à une plateforme (cela peut être du code d'initialisation, des trucs pas vraiment jolis...). Dans le même niveau d'arborescence, on rajoutera des répertoires pour les choses communes à toutes les plateformes (donc le maximum de choses) : src (sources) et ressources (images, sons...).

Nous allons prendre un exemple bien particulier, mais doutez-vous bien que la création du projet Xcode fonctionnera avec n'importe quel type de modèle de projet, même le modèle vide (que vous aurez d'ailleurs plus de facilités à remplir de bonnes choses).

On va dire que SDL est installé, et qu'on crée un projet sur le modèle SDL Application. Une fois le projet créé dans le répertoire macosx/ de notre structure, on peut commencer à régler les préférences du projet (je pense à des choses comme la version du SDK de destination, ou la version de Xcode à utiliser, pour être sûr de la compatibilité du projet avec vos collaborateurs qui ont sûrement oublié de vous dire qu'ils étaient encore sur Leopard, par exemple...) ainsi que celles de l'application Cocoa (comme l'icône, la version, entre autres, si application il y a, et c'est le cas pour le modèle fourni par les développeurs de SDL). Il faudra peut-être ensuite déplacer certains fichiers. Ici, vu qu'on a affaire à une application SDL (les développeurs ont mis au point ce qu'il faut pour que l'application tourne sur Mac OS X en séparant tout de façon à ce que vous n'ayez pas besoin de faire de l'Objective-C), il faut déplacer le fichier main.c vers le répertoire des sources communes, et pourquoi pas le changer un peu pour en faire une source C++ respectant le standard. On a donc la hiérarchie suivante :

monpianodamour/
        macosx/
                English.lproj
                Icone.icns
                Info.plist
                monpianodamour.xcodeproj
                monpianodamour_Prefix.pch
                SDLMain.h
                SDLMain.m
        ressources/
        src/
                main.cpp

Il va maintenant falloir s'assurer d'organiser les groupes du projet (la liste à gauche dans la fenêtre du projet) afin qu'ils correspondent aux répertoires créés. Pour cela, vous n'avez qu'à créer des groupes et ajuster leurs propriétés afin qu'ils pointent vers les répertoires qu'ils désignent. Ainsi, tout fichier ajouté à un groupe ira à la bonne place dans la hiérarchie du projet, et c'est bien mieux ainsi !

Il faut qu'un serveur accueille le dépotoir que vous allez créer. Ici, par exemple, on a choisi Google Code, qui donne accès à un SVN. La page de création d'un projet est un peu galère à trouver, mais une fois que c'est fait, c'est le bonheur. Nous avons donc paramétré le projet Google Code et récupéré certaines informations afin de pouvoir utiliser le SVN.

Allons dans les préférences de notre petit Xcode chéri, au rayon SCM, car c'est là que sont indexés tous les dépôts que Xcode aura à gérer dans sa petite vie. Une fois entré dedans, rajoutons un dépôt (repository) et choisissons le nom et le système de gestion de versions qui correspond. Ici on a un SVN, et de toute façon Xcode ne propose pas 50 choix alors je doute que le vôtre sera différent.

Ben oui, quoi ! C'est fait ! Quoi ? Vous attendez encore quelque chose ? Il vous manque peut-être le lien entre la super structure que vous avez préparé et le super dépôt auquel vous êtes maintenant connecté(e). Pas de panique.

Déjà, allez dans la fenêtre d'informations de votre projet, et assurez-vous de configurer ce que Xcode appelle Roots & SCM. Il s'agit de dire à Xcode que votre projet est en lien avec un SCM qu'il a enregistré, en précisant quel répertoire est la racine. Donc sur Xcode 3.2, une fois que vous avez cliqué sur Configure Roots & SCM, vous rajoutez un répertoire, et il faut que ce soit la racine de votre projet (pas monpianodamour/macosx/ mais monpianodamour/). Ce répertoire sera lié au SCM Monpianodamour que vous venez de rajouter.

Si Xcode n'importe déjà pas tout le projet comme un grand, on va le faire nous mêmes. Allez dans le menu SCM > Repositories afin d'accéder à la fenêtre des dépôts. Vous allez maintenant ajouter votre projet au dépôt, grâce au bouton de barre d'outils nommé Import. Choisissez le répertoire racine du projet (nommé monpianodamour, il s'entend), et rajoutez un petit commentaire du style : "Première révision, coucou maman je passe sur internet". Une fois votre importation réussie, vous pouvez être content(e) de vous, car vous avez fini.

Vos collègues, eux, ils ont encore quelques petites étapes à accomplir. Ils doivent configurer Xcode comme je l'ai conseillé et rajouter le SCM avec leurs identifiants. Ensuite, ils pourront aller dans la fenêtre des dépôts, sélectionner le répertoire racine du projet et cliquer vaillamment sur Checkout afin d'extraire la révision courante du dépôt. Qu'ils l'enregistrent où ils le souhaitent. Une fois le répertoire rapatrié, il faudra qu'ils aillent ouvrir le projet Xcode situé dans macosx/ et ils pourront alors commencer à travailler, en s'assurant de faire des Commit pour soumettre leur travail, et des mises à jour pour récupérer les dernières versions des dépôts. Xcode inclut ce qu'il faut pour gérer les conflits de version et tout le bazar. Les collègues précautionneux prendront bien soin d'aller vérifier si le projet récupéré est bien relié au SCM qu'ils ont configuré, parce que sinon, ils ne peuvent pas participer à l'orgie de commits que vous leur aviez promis.

Vous pouvez donc maintenant utiliser Xcode pour des projets quelconques et collaborer à plusieurs sans quitter votre IDE préféré. Bien sûr, ce que j'ai montré n'était qu'un petit exemple, à vous de l'adapter à votre cas de figure...

...gros bébé :)