Si il vous arrive régulièrement de recompiler un logiciel développé en C ou C++, ccache pourrait vous intéresser. Concrètement, il s’agit d’un programme que vous allez appeler à la place du compilateur et qui va regarder si il n’a pas déjà dans son cache un objet binaire correspondant au fichier à compiler. Ainsi, vous éviterez le temps de compilation pour ce fichier! Au final, on obtient un gain plus ou moins sensible en fonction des projets.

Le cache est par défaut stocké dans le répertoire ~/.ccache/.

Pour utiliser ccache, rien de plus simple sous Debian et ses dérivés comme Ubuntu :)

Il suffit de l’installer

sudo aptitude install ccache

et d’ajouter la ligne suivante dans son fichier ~/.bashrc

PATH=/usr/lib/ccache/:$PATH

Voilà, maintenant ccache remplacera de manière transparente votre gcc qui ne sera appelé qu’en cas de besoin réel :)

Cela fait presque 2 mois que j’utilise git et git-svn au lieu de svn, pour Wormux ou dans mon travail. Git est sans doute plus complexe que subversion, mais cette complexité apporte quelques avantages (je suis plutôt réservé quant aux avantages pour des graphistes ou autres).

Le micro-commit

Avec git, plus d’hésitation à “commiter” localement les fichiers une fois qu’on commence à avoir quelque chose de convenable. Si au final, ce n’était pas une bonne idée, il suffira de revenir en arrière dans l’historique mais les autres développeurs ne seront pas impactés. Ça permet d’avoir des messages de commits plus précis, et des modifications plus fines par commit, plus facile à annuler et à comprendre. On est alors dans un cycle de développement beaucoup plus itératif.

Admettons qu’on veuille faire une modification massive de l’organisation du code et qu’on souhaite que tout ne soit visible qu’en version “finale” aux autres développeurs, car on est pas sûr à 100% de ce qu’on va faire, et que l’on craigne devoir revenir en arrière plusieurs reprises dans le processus. Avec git, à chaque étape, on fait un commit, et si finalement les dernières modifications (non commitées) ne conviennent pas, on utilisera git stash ou git checkout HEAD pour annuler ces modifications. Une fois qu’on est satisfait, on envoie le tout sur le dépôt centralisé avec git svn dcommit :)

Avec subversion, il est probable qu’on n’ait pas osé commiter chaque petite modification, et du coup, dès qu’il faut revenir en arrière, c’est galère :(

La gestion de branche locale à porter de main

L’autre avantage, c’est la facilité avec laquelle on peut gérer des branches locales. Par défaut, avec git-svn, on a une branche locale appelée master. Personnellement, je ne fais aucune modification sur cette branche et me contente de la maintenir à jour par rapport au trunk svn à l’aide des commandes suivantes :

• git svn fetch pour mettre à jour l’historique par rapport aux modifications apportées sur le dépôt centralisé SVN. Ça n’applique pas ces modifications sur votre copie locale.
• git checkout master pour passer sur la branche master. Nécessaire uniquement si vous étiez sur une autre branche.
• git rebase trunk pour synchroniser la branche courante avec la branche distante trunk.

Je fais toutes mes modifications sur une autre branche, appelons là local-devel. Je crée la branche avec git branch local-devel puis passe sur cette branche avec git checkout local-devel. À partir de là, je commence à travailler puis commite localement de temps en temps.

Il m’est arrivé par 2 fois d’avoir une correction de bug plus urgente à faire. Je repasse alors sur la branche master (git checkout master), je la met à jour (git svn fetch && git rebase trunk), je branche (git branch fastfix && git checkout fastfix), je corrige le bug, je compile, je teste, je commite localement (git commit -a), je propage la modification (git svn dcommit), je remet à jour ma branche master (git checkout master && git rebase trunk) et efface la branche devenue inutile (git branch -D fastfix) puis je retourne ensuite à mon développement standard que je rebase sur la branche master (git checkout local-devel && git rebase master). C’est une certaine gymnastique, mais au final, c’est plus confortable que faire un svn diff qu’on redirige dans un fichier pour ré-appliquer le patch plus tard ;)

Maintenant que le projet a été importé, il est possible de travailler normalement en éditant ses fichiers avec son éditeur de texte favori.

De la même manière qu’avec SVN, on peut renommer des fichiers avec Git en utilisant git mv nom_de_fichier_actuel futur_nom_de_fichier.

Avant de propager les modifications dans l’historique local, on va d’abord vérifier les changements, avec git diff [mes_fichiers]. Contrairement à svn diff, il est suffisamment intelligent pour ouvrir directement dans le pager. git diff [mes_fichiers] est donc plus ou moins équivaleut à svn diff [mes_fichiers] | less.

Pour voir uniquement le noms des fichiers modifiés sans voir les modifications, on fera git diff --name-only [sous-répertoire].

Git étant décentralisé, on va d’abord propager localement les modifications avec git commit. Contrairement à SVN, avec Git, par défaut, git commit n’agit sur aucun fichier. On peut faire git commit -a pour commiter (bouh, le vilain franglais!) tous les fichiers (déjà surveillés) modifiés. Ou alors, avant d’appeler git commit on peut appeler git add mes_fichiers que mes_fichiers soient déjà présents ou non dans le dépôt. git commit prendra alors en compte tous le fichiers sur lequel on a fait un git add. Dernière possibilité, git commit mes_fichiers. Bien évidemment, git commit demande ensuite de remplir un commentaire sur la modification effectuée et refuse si le commentaire est vide :)

Viens ensuite le moment de la propagation dans le dépôt central SVN, avec git-svn dcommit. On pourrait se dire que ça oblige à taper 2 commandes au lieu d’une (git commit mes_fichiers, git-svn dcommit au lieu de svn commit) mais ça permet de faire des plus petits commits qu’on ne propagera globalement qu’une fois un peu plus de travail effectué. Au final, en profitant bien de cette possibilité, ça permet d’avoir un historique de meilleur qualité :)

Petit exemple de code qui ne fait pas ce pourquoi il a été écrit

[cpp]
void MoveCharacter(Character& character, bool slowly)
{
   ...
   // Check we can move (to go not too fast)
   while (character.CanStillMoveRL(walking_pause) && ComputeHeightMovement (character, height, true));
   {
       // Move !
       Game::GetInstance()->character_already_chosen = true;
       // Eventually moves the character
       character.SetXY( Point2i(character.GetX() +character.GetDirection(),
                                character.GetY() +height) );
       // If no collision, let gravity do its job
       character.UpdatePosition();
   }
   ...
}

Le bug se situe ici dans le ; à la fin du while. La suite est alors considérée comme un bloc indépendant qui sera exécuté 1 seul fois et systématiquement à chaque fois que la fonction MoveCharacter() est appelée, ignorant complètement le résultat du test du while…

PS: ce code a été écrit et modifié pour http://www.wormux.org Wormux. Je me suis bien pris la tête à chercher cette erreur bête (dont je suis l’auteur)!

Aujourd’hui, je suis heureux :)

Je vais passer une agréable soirée avec ma compagne, mais en plus, j’ai corrigé un gros bug cette après-midi!!

C’est assez hallucinant de voir d’ailleurs le plaisir ressenti lorsque le bug qu’on a traqué pendant des heures trépasse enfin. On fait le test, on se dit : j’espère que c’est bien ça, il commence à être #@&$%¤ ce bug. Et là, c’est inespéré, le test se déroule …, on scrute avec attention le résultat… OUI! Victoire!! Le bug est corrigé!

Quel extase d’avoir passé des heures pour 2 lignes mal placées… le résultat est tellement agréable qu’on en oublierait les ronchonnements et les arrachages de cheveux!! À tel point qu’on se dit que c’est plus jouissif de corriger un bug poilu que de coder des trucs simples, surtout si c’est des trucs pour le boulot ;)