Articles tagués “eclipse

Activer la compilation multicœur dans Eclipse CDT

Mon premier article sur ce blog expliquait comment dire à make d’utiliser plusieurs cœurs lors de la compilation. Il suffit d’utiliser l’option -j pour spécifier le nombre de jobs pouvant s’exécuter en parallèle. Si vous utilisez Eclipse CDT et son builder interne, il existe aussi une option activer la compilation multicœur. Je l’ai trouvé par hasard aujourd’hui, elle est dans les propriétés du projet puis C/C++ Build et Behavior :

eclipse-compilation-multicoeur

J’ai étonné que cette option ne soit pas cochée par défaut et j’ai bien sûr immédiatement testé ça. Mon projet n’est pas encore très gros, il n’a que 78 fichiers. En l’activant, je suis passé de 31s.792 ms à 13s.114 ms pour le builder. Wouhou !


ObjectAid : sources Java vers diagrammes de classes

Ceci est mon 100e article ! \o/

Au début de cette année, j’avais passé plusieurs heures à chercher sur Internet un outil permettant de gérer des diagrammes de classes à partir d’un projet Java existant. Il n’y avait pas beaucoup de critères :

  • être gratuit,
  • être simple,
  • s’intégrer dans Eclipse.

J’avais essayé des tas de mots-clés dans Google et je n’avais rien trouvé. Vraiment rien. J’avais essayé quelques usines à gaz d’Eclipse Modeling sans arriver à un résultat concluant. J’avais alors laissé tomber. La semaine passée, j’ai cherché à faire l’inverse : créer des diagrammes de classes pour pouvoir ensuite générer du code Java. J’ai fais une recherche dans Google et le premier résultat était une discussion stackoverflow expliquant comment… générer des diagrammes de classes à partir de sources existantes. Oui, je suis très sérieux.

C’est ainsi que j’ai découvert ObjectAid. Il ne permet pas de créer de diagrammes de classes pour générer ensuite du code ; il analyse le code existant et l’afficher sous forme de diagrammes de classes. Il est disponible via le Marketplace d’Eclipse. En fait, j’ai vu cet outil lors de mes recherches de début d’année mais j’avais crû qu’il n’était pas gratuit. Il existe en effet des licences payantes mais elles donnent accès à des fonctionnalités supplémentaires. Les fonctionnalités de base sont bien gratuites. Voici la description de l’outil donné par le site officiel :

The ObjectAid UML Explorer is an agile and lightweight code visualization tool for the Eclipse IDE. It shows your Java source code and libraries in live UML class and sequence diagrams that automatically update as your code changes.

L’utilisation de l’outil est triviale. Un tutoriel est disponible ici.

Dans le meilleur des mondes, on devrait faire des diagrammes de classes lors de la phase de conception, écrire le code (ou encore mieux : le générer) et continuer à garder une cohérence entre les diagrammes et le code au fur et à mesure que le projet avance et qu’on fait du refactoring ou que l’on repense certains modules. Dans les faits, on ne fait pas souvent les diagrammes de classes originels et on les garde encore moins souvent à jour. ObjectAid ne permet pas de répondre à la première problématique mais répond complètement à la seconde puisque ses diagrammes se mettent à jour quand on modifie les fichiers sources associés.

Je suis bien content d’avoir trouvé cet outil, il sera très pratique pour donner une meilleure vision d’ensemble de bibliothèques ou de projets, en montrant de manière graphique les liens entre les classes. Juste pour l’exemple, j’ai fait un petit projet avec 3 classes, dont 2 implémentent une interface :

objectaid - project

Et voici le diagramme montrant l’interface et les 2 classes d’implémentation (je n’ai pas ajouté la 3e classe au digramme car je suis libre de mettre les classes que je souhaite, je ne suis pas obligé de mettre tout le projet Eclipse !) :

objectaid - diagramme classes


Builder un projet Keil uVision en ligne de commande

J’utilise souvent Keil uVision (4 et 5) dans le cadre du travail. Aujourd’hui, j’ai souhaité pouvoir builder mon projet Keil depuis Eclipse pour pouvoir automatiser le déploiement de mon applicatif sur la carte. Il y a plusieurs étapes dans ce processus :

  1. Compiler mon application Java pour générer un fichier objet à destination de Keil.
  2. Builder le projet Keil pour obtenir un fichier exécutable ELF.
  3. Découper mon fichier ELF en deux fichiers binaires, un pour la flash interne, l’autre pour la flash externe.
  4. Programmer ma carte avec ces 2 fichiers binaires grâce au ST-Link Utility. Cette étape est en fait double car il faut programmer la mémoire interne puis la mémoire externe en sélectionnant à chaque fois le bon fichier.

La première étape est un bête launch configuration d’Eclipse. Les étapes 3 et 4 étaient déjà automatisées grâce à des scripts Ant. Il me restait donc cette étape 2 qui m’obligeait à quitter Eclipse pour aller dans Keil et à cliquer sur le bouton Build.

Pour automatiser cela, il suffisait de trouver la bonne ligne de commande pour appeler Keil et lui dire de builder mon projet. Le site de Keil dédie une page à l’utilisation en ligne de commandes : Keil uVision User’s Guide: Command Line. J’avais donc besoin de l’option -b pour demander de builder le projet. Mon projet ne contient qu’une seule target mais dans le doute (ou histoire de faire bien), je l’ai quand même précisé. La target Ant résultante ressemble à ceci (les noms des propriétés sont explicites, je ne pense pas avoir besoin de vous les montrer) :

<target name="build" description="build Keil project">
	<echo>Building Keil project...</echo>
    <exec executable="${keil.dir}/UV4/UV4.exe">
    	<arg line="-b ${keil.uvprojfile} -t&quot;${keil.target}&quot;"/>
    	<!-- You may add the -j0 option to the above argument line to hide Keil's UI -->
    </exec>
</target>

J’ai eu un problème dont la résolution mérite d’être retenue. Lors de l’appel à ce script, tous les fichiers du projet étaient recompilés même si rien n’avait changé. Normalement, c’est l’option -r qui devrait avoir cet effet. Cette discussion sur le forum Keil m’a aidé à résoudre le problème. La personne avait un problème similaire car le fichier de dépendance de son projet était en lecture seule dans le gestionnaire de sources. Il se trouve que mon projet était dans un dépôt Git et donc ce fichier était versionné, mais il n’était pas en lecture seule. Je l’ai ajouté à l’ignore list et le problème a disparu.

J’avais presque fini : il ne me restait plus qu’à faire un launch group dans Eclipse pour enchainer mes 3 launch configurations (1 programme Java et 2 programmes Ant). J’ai mis un petit moment à comprendre qu’il me fallait choisir Wait until terminated pour empêcher les 2 scripts Ant de s’exécuter en parallèle après avoir sagement attendu que l’application Java soit exécutée complètement.

build keil - launch groupEt voilà ! Je builde un 2 clics maintenant 🙂

J’en profite pour vous dire de toujours automatiser au maximum vos builds ! On a souvent l’impression que trouver un moyen d’automatiser va être plus long que le temps cumulé à réaliser les étapes manuellement. On se dit qu’après tout, on ne devrait pas le faire si souvent, que le projet ne devrait pas être trop long et que ce sera supportable. C’est faux ! Au-delà du fait que réaliser plusieurs étapes manuellement est atrocement pénible, c’est un risque de se tromper et perdre du temps. Ensuite, vous passerez plus de temps que vous ne le pensez à builder à la main. Enfin, ce que vous avez fait pour de précédents projets sera sûrement utilisé pour les projets suivants et vous passerez de moins en moins de temps à automatiser. J’ai souvenir d’un projet où, au bout d’un mois, j’ai écrit un script pour automatiser un processus similaire à celui décrit plus haut, où tout était manuel : ça a changé ma vie et j’ai regretté de ne pas l’avoir plus tôt !

N’hésitez plus, scriptez, automatisez, simplifiez vous la vie !


Eclipse Installer avec Oomph

Avant, quand on voulait installer Eclipse, on allait sur la page de téléchargement, on choisissait la version d’Eclipse qui nous intéressait. On téléchargeait un ZIP et on le mettait, où on voulait, à la main.

Mais ça, c’était avant. Maintenant, on peut utiliser l’Eclipse Installer. Cet installateur vient du projet Oomph, qui fait lui-même partie du projet Mars, la future version d’Eclipse. Oomph n’est pas qu’un installateur pour Eclipse, il a pour but de faciliter les choix d’options et de préférences. Vous pouvez lire cet article paru dans la newletter Eclipse pour plus d’info. L’installateur est assez gros (43 Mo) et facilite l’installation d’Eclipse. Un magnifique splash-screen tente de nous distraire pendant que l’application se lance (ça reste Eclipse hein !) :

oomph - 1 - splash

Une fois l’application chargée, on arrive sur l’écran d’accueil où on peut choisir la déclinaison d’Eclipse à installer :

oomph - 2 - main

Pour l’exemple, choisissons la version pour les développeurs C et C++. On peut alors choisir des options d’installation, comme la version d’Eclipse, le dossier où on souhaite l’installer, le JRE qu’on souhaite utiliser, etc :

oomph - 3 - example

Quand on clique sur Install, la licence est montrée, on l’accepte et l’installation commence :

oomph - 4 - installing

L’installateur télécharge ce dont vous avez besoin et met tout ça au bon endroit. Quand c’est terminé, il n’y a plus qu’à lancer !

oomph - 5 - installed


Utiliser les save actions d’Eclipse

Certains disent du mal d’Eclipse. On dira ce qu’on veut, cet IDE propose énormément de fonctionnalités et vos collègues auront toujours de nouvelles astuces à vous faire découvrir. Une astuce que j’aime partager est l’utilisation des save actions pour automatiser des actions « pénibles » par un simple appui sur CTRL+S. Pour les activer, il suffit d’aller dans Window / Preferences… et de taper « save actions » dans le champ de recherche. Vous constaterez que chaque éditeur est configuré séparément. Pour l’exemple, je m’intéresse ici à l’éditeur Java car c’est l’éditeur que j’utilise principalement dans Eclipse. Généralement, quand je démarre un nouveau projet, je travaille comme ça :

save actions - 1 - window pref

S’il s’agit d’un projet existant, alors je choisis de ne formater que les lignes éditées. En effet, on risque de provoquer énormément de changements et donc rendre impossible la comparaison des versions du fichier dans un système de contrôle de sources. Cela ne devrait pas être le cas dans un projet bien organisé car tout le monde devrait travailler le même formateur de code et formater son code avant chaque commit dans le gestionnaire de versions des sources, mais la réalité est souvent différente.

Pour vous montrer l’intérêt, voici un bout de code taper « à la main », sans utiliser l’auto-complétion (car l’auto-complétion permet de rajouter automatiquement les imports) :

save actions - 2 - before

Si je l’enregistre en activant les save actions comme montré dans la première capture d’écran, le code ressemble à ça :

save actions - 3 - code after

C’est pas mieux ? La Javadoc a été remise en forme, les espaces et tabulations ont été correctement ajoutées ou enlevées (y compris en fin de ligne, comme le montre la ligne en bleu), les accolades se mettent aux bons endroits, les imports manquant se rajoutent et résolvent les erreurs de compilations.

Vous gagnerez beaucoup de temps en utilisant les save actions. Vous pouvez être sûr de toujours avoir un code formaté correctement, conformément aux paramètres du formateur courant de l’éditeur Java. Dans la première capture d’écran, vous pouvez voir que la dernière checkbox est « Additional actions ». Vous aurez accès à encore plus d’actions !

CTRL+S, c’est la vie, et pas seulement pour ne pas perdre ce qu’on vient de faire !