|
||||||||||||||||||||||||||||||||||||||||||||||||||
|
L'environnement de développement ultime ? Initialement appelé Lattice, le compilateur SAC C atteint maintenant le numéro de version 6 et saute gaiement de l'appellation "compilateur" à "environnement de développement". Du neuf avec du vieux ou bien un réel travail d'amélioration ? Au moment où j'écris cet article, SAS 6 est déjà présent sur le marché de l'Amiga depuis environ neuf mois et le niveau de correctifs a atteint 6.3. Pourquoi avoir tant tardé dans la rédaction de ce test ? Parce qu'un environnement de développement complet, avec plusieurs centaines de pages de documentations et suffisamment d'utilitaires pour remplir trois-cent-soixante cinq soirées ne se teste pas sur un simple coup d'oeil. Au-delà des fonctions documentées, il faut aussi évaluer la robustesse et le confort d'utilisation de la bête. Me sentant suffisamment à l'aise maintenant, je me lance. Tour d'horizon d'un produit qui va marquer l'histoire de l'Amiga. Installation SAS travaille naturellement main dans la main avec Commodore (qui utilise leur compilateur de longue date) et c'est sans surprise que l'installation sur disque dur se fait via le célèbre Installer. Pas de risque de se tromper, tout est soigneusement expliqué et pour peu que vous avouiez au script d'installation votre ignorance totale du monde de l'Amiga, celui-ci limitera au strict minimum les questions à vous poser. Quelques mots sur la méthode de mise à jour : les correctifs sont librement distribuables. Autrement dit, quand SAS distribue une nouvelle version de correctifs, celle-ci est très rapidement déposée sur les BBS les plus connus (Bix, Compuserve, Usenet, Internet) et peut être demandée gratuitement auprès de SAS. Les correctifs sont appliqués à partir des disquettes originales. Ayez donc soin de les avoir toujours à disposition même si vous ne les utilisez que pour ça. L'opération est plutôt longue mais là encore, l'usage d'Installer limite considérablement les risques d'accident et le script est suffisamment intelligent pour analyser votre configuration et en déduire tout ce qu'il y a à faire sans vous demander autre chose que d'insérer les disquettes originales. Le compilateur J'utiliserai afin d'illustrer mon propos le petit source C suivant (hello.c) :
...incluant le fichier hello.h que voici :
La première chose que remarqueront les fidèles de Lattice est que tous les fichiers ont été renommés. Partout où figurait le "l" de Lattice figure désormais un "s". Le compilateur est ainsi devenu sc, le relieur slink, etc. Et au passage, ils ont tous été considérablement remaniés. Fondamentalement Désormais, le compilateur fonctionne entièrement à partir de bibliothèques partagées. L'intérêt de cette méthode est que seule la première compilation prend un peu plus de temps. Les compilations suivantes sont plus rapides car les bibliothèques sont gardées automatiquement en mémoire. Et comme toute bibliothèque qui se respecte, celles-ci seront automatiquement évacuées pour faire de la place si cette mémoire vous fait défaut. La syntaxe d'appel a également changé : elle se conforme désormais au format devenu standard avec le système 2.0 et sa fonction ReadArgs(). Pour compiler rapidement un petit programme, la ligne suivante suffit :
Ou encore, pour inclure des symboles pour un éventuel usage du débogueur :
Pour les habitués de la syntaxe de la version 5, un petit utilitaire est fourni qui fait la conversion automatiquement (lctosc) ou encore pour utiliser sc version 6 avec l'ancienne version (sc5). Même si cette syntaxe peut paraître longue, il ne faut pas perdre de vue les points suivants :
Figure 3 Figure 4 Les tables de symboles Les Global Symbol Tables (GST) sont une innovation majeure de SAS 6, et pas seulement d'un point de vue limité à l'Amiga mais dans le domaine des compilateurs. Lorsque vous demandez la création d'une telle table, un fichier est créé contenant tous les symboles définis dans les fichiers ".h" inclus. Si vous utilisez cette table lors de la prochaine compilation (avec l'option "gst=hello.gst" par opposition à "makegst=hello.gst" qui crée le fichier de symboles), le compilateur ignorera toutes les directives d'inclusion et utilisera directement ce fichier. Le résultat : des compilations qui vont deux fois plus vite (tests effectués aussi bien sur le fichier helloworld.c que sur un projet de plusieurs milliers de lignes). Naturellement, vous devez recréer votre fichier de symboles si vous apportez des changements à vos includes, mais c'est une opération somme tout relativement rare. Autre bonus Les tables de symboles sont lisibles par AmigaGuide. Un programme appelé HyperGST permet en effet de les consulter et est d'une aide appréciable pour retrouver un symbole perdu aux fins fonds de vos includes. Les figures 5, 6 et 7 illustrent la recherche du symbole "T test:" d'abord dans le menu Type-defs puis en cliquant sur le nom désiré, dont la définition vous est rappelée. Première conclusion Je conclurai en évoquant brièvement la qualité du code produit : celui-ci se compare sans honte au code généré par le compilateur gcc qui est sans conteste possible le meilleur compilateur dans ce domaine. Les partisans de DICE protesteront en affirmant que le compilateur de Matt Dillon produit un code encore meilleur, mais il faut garder à l'esprit que SAS fournit un optimisateur externe (go) : le compilateur ne fait donc que peu d'optimisations et si une véritable comparaison devait être faite, il faudrait la faire avec un exécutable qui serait passé au préalable par go. Voilà pour l'essentiel. Qu'il me suffise de vous dire que le compilateur comprend plus d'une centaine d'options et vous mesurerez l'étendue de ce qu'il est capable de faire... scmsg Voici une ouverture vers l'extérieur. Les développeurs de SAS ont acquis une maturité certaine avec leur compilateur, ce qui se traduit par des utilitaires fiables (débogueur), des innovations (les tables de symboles) et surtout le sentiment de ne pas posséder la vérité ultime et donc de laisser les utilisateurs choisir leurs programmes préférés. Et ceci est tout particulièrement vrai en ce qui concerne l'éditeur. On ne le répètera jamais assez : le meilleur éditeur est celui que vous utilisez le mieux. Même si se, l'éditeur qui vient avec le compilateur, est de bonne qualité et parfaitement intégré à l'environnement, vous ferez certainement grise mine si vous êtes obligé d'abandonner le vôtre pour pouvoir compiler vos programmes. Rassurez-vous donc : pour peu que votre éditeur possède un port ARexx, vous pourrez parfaitement l'utiliser en symbiose avec le compilateur. Le programme qui rend cette chose possible s'appelle scmsg. C'est lui qui fait la jonction entre le compilateur et votre éditeur. Le principe est simple : vous spécifiez l'option "ERRORREXX" au compilateur et celui-ci enverra les messages d'erreur à scmsg qui vous les affichera dans une petite fenêtre (fig. 8). scmsg à son tour vous propose plusieurs options (passer à l'erreur suivante, relancer la compilation) dont celle d'afficher votre source automatiquement positionné sur l'erreur. Et c'est là où scmsg donne toute sa puissance : toutes ces informations sont paramétrables. Par défaut, scmsg enverra à se (par l'intermédiaire de son port ARexx) les commandes nécessaires pour charger le fichier et sauter à la ligne incriminée, mais vous pouvez aisément y insérer des commandes spécifiques à votre éditeur. Tout ce que scmsg a besoin de savoir c'est le port ARexx de l'éditeur, la commande à exécuter pour lancer l'éditeur si celui-ci n'est pas présent, et les deux commandes ARexx pour demander à l'éditeur de charger un fichier et sauter à une ligne précise. Si vous désirez utiliser gnuemacs par exemple, vous donnerez comme port ARexx EMACS1, comme commande ARexx pour charger un fichier (find-file " %f"), etc. Pour substituer à gnuemacs CygnusEd, TurboText ou encore QED, un simple coup d'oeil à la documentation ARexx de ces éditeurs suffira. smake De son précédent nom, lmk, smake deviendra rapidement la commande que vous utiliserez le plus souvent pour lancer des compilations. Alors que l'utilisation de scopts est suffisante pour travailler sur un seul source, il devient très fastidieux de gérer des compilations multiples dans le cas où vous travaillez sur plusieurs modules. smake vous permet de lancer la compilation globale de votre projet en une seule commande tout en optimisant les appels au compilateur. Pour cela, vous créez un fichier Smakefile dans lequel vous indiquez les dépendances de vos différents sources ainsi que les commandes nécessaires pour les obtenir. smake ne compilera que les sources qui ont été modifiés depuis la dernière compilation. Je ne m'étendrai pas davantage sur smake : c'est un utilitaire courant qu'on retrouve dans tous les environnements de compilation. Celui de SAS est plutôt conventionnel tout en apportant quelques touches personnelles. Le débogueur Depuis sa première version, cpr n'a jamais cessé d'évoluer. D'abord fort contesté du fait de sa lenteur et des plantages qu'il subissait, il a été décrié dans ses premières versions. Ces reproches ne sont plus de mise avec la version actuelle : cpr est stable, rapide, et il commence à approcher de près la référence en la matière : gdb, utilisé sous Unix et écrit par la Free Software Foundation (GNU). cpr est un débogeur source. Autrement dit, il vous permet de travailler directement à partir de votre source C, et non pas uniquement assembleur (il permet même de mélanger les deux, c'est-à-dire de voir pour chaque ligne de C l'assembleur produit). Pour peu que vous ayez compilé votre programme avec les symboles ("DEBUG=FULL"), cpr se positionnera automatiquement sur la première ligne de votre main et attendra votre bon vouloir. Les deux fenêtres présentées initialement vous montrent votre listing et l'interprète de commande, qui va vous permettre de diriger cpr (fig. 1). Figure 1 Toutes les commandes données au débogueur peuvent être abrégées. La commande "dis" (display) est sans aucun doute celle que vous utiliserez le plus fréquemment : elle vous permet d'afficher n'importe quelle variable de votre programme, celle-ci fût-elle simple (entier, caractère, chaîne, etc.) ou complexe (structure, énumération, etc.).
Vous avez naturellement le contrôle absolu de ces variables : vous pouvez modifier leur valeur, les champs des structures, effectuer des calculs au vol, allouer de la mémoire, appeler des fonctions, manipuler de la mémoire (dump, memcpy, memcmp, memmove, memset), etc. C'est quasiment un interprète C que vous offre cpr ! Les points d'arrêt se manipulent avec les commandes bclear, bdisable, benable, blist. Ils offrent les fonctions classiques que l'on attend de tout débogueur (conditionnel, arrêt unique, arrêt après un certain nombre de passages, etc.).
Les commandes tasks, detach, catch et deactivate vous permettent d'utiliser cpr sur une tâche externe. Le contrôle de l'exécution se fait via les commandes trace, proceed, restart, return, ts. Les points de surveillance (watchpoints), qui vous permettent d'interrompre l'exécution de votre programme si la valeur d'une variable change, ne sont pas oubliés (wbreak, wclear, wdisable, wenable, wlist, etc.). Toutes ces commandes peuvent être stockées dans des fichiers et être exécutées comme de véritables petits programmes (y compris dans un fichier d'initialisation qui sera exécuté à chaque démarrage de cpr). Comme si cela ne suffisait pas, cpr dispose d'un port ARexx qui vous permettra de le piloter à partir d'une application externe (éditeur, Shell, etc.). Si jamais vous hésitez sur la syntaxe d'une commande, vous appuyez sur "Help" et une aide en ligne au format AmigaGuide apparaît (fig. 2). Figure 2 L'éditeur se (Sas Editor) est l'éditeur standard fourni pas SAS (fig. 9). Il a été conçu dans un but d'efficacité et de configurabilité. Autrement dit, vous ne trouvez pas dans se de puissantes fonctions pour manipuler des graphiques ou des textes de couleurs. En revanche, beaucoup de facilités vous sont offertes pour éditer des sources C. Figure 9 Figure 10 D'un point de vue strictement "éditeur de texte", se est assez conventionnel : il autorise l'édition multiple de fichiers, permet des recherches/remplacements de chaînes ou d'expressions régulières, autorise la définition de macros (très pratique pour des tâches répétitives), etc. Vous pouvez commander la compilation de votre fichier avec la touche F4. En cas d'erreur, se communique avec scmsg pour vous aider à vous déplacer dans vos différents sources. Autre point d'intérêt : se est complètement configurable. Sur simple demande, il vous affichera dans sa fenêtre de configuration une représentation du clavier. Si vous cliquez sur une touche, ou une séquence de touches, l'éditeur vous donnera la commande qui y est attachée (il s'agit de la commande ARexx correspondante). Par exemple, F4 est lié à la commande CO, qui déclenche la compilation du source en cours d'édition. Rien de plus facile que de redéfinir totalement votre clavier pour l'adapter à vos goûts. L'interface ARexx est riche d'environ soixante-dix commandes, dont soixante sont affectées à des combinaisons de touches. Personnellement, je trouve que se est le point faible de l'environnement. Il manque un peu de souplesse par quelques côtés et bizarrement, déroge par bien des côtés au guide du style de Commodore (notamment en ce qui concerne les menus "Fichier", qui sont quelque peu perturbants). Mais ce n'est nullement irréparable : les utilitaires tels scmsg vous laissent les mains complètement libres pour substituer à se l'éditeur de votre choix avec un minimum de perte de fonctions. Et le Workbench dans tout ça ? SAS a fait un effort particulier pour rendre leur produit utilisable par tout un chacun, et les réfractaires au Shell ne sont pas oubliés. Beaucoup de facilités sont offertes pour débuter un projet à partir de rien (création des fichiers de base, des icônes, etc.) ainsi que la possibilité de piloter tout le compilateur entièrement à partir de la souris. Conclusion Il est difficile de faire partager un énorme enthousiasme en quelques lignes. Jusqu'à cette version, je pensais avec une certaine honte que les environnements de développement sur Amiga faisaient pâle figure par rapport à leurs concurrents sur PC. La version 6 représente un progrès énorme par rapport à la précédente (ce qui n'était pas le cas de la version 5 par rapport à la version 4), à la fois d'un point de vue fiabilité et rapidité mais surtout dans le domaine des fonctions. L'équipe de SAS s'est livrée à un véritable de travail de recherche, anticipant sur certains points, accompagnant Commodore dans d'autres, laissant des portes de sortie pour offrir le maximum de choix à l'utilisateur (scmsg), fournissant une assistance sans failles et omniprésente sur Usenet, des facilités de mise à jour pour les anciens clients, etc. C'est en toute connaissance de cause que je reprendrai le cliché qui termine habituellement ce genre de test : SAS 6 est un incontournable pour tous les développeurs. Et pour finir, la petite cerise sur le gâteau : SAS a annoncé pour septembre 1993 leur propre compilateur C++ (qui n'a rien à voir avec le C++ 1.0 de Lattice d'il y a quelques années) qui sera compatible avec cfront version 3.0 sans les templates ni les exceptions. Ce nouveau produit portera la révision 6.5 et sera livré avec le compilateur C.
|