BerndPol IanWadham Ce chapitre ne traite que des projets compilés, tels que les projets C++, &Java; ouFortran. Les projets concernant les langages de scriptage comme Python et PHP fonctionnent de manière très différente. Vous trouverez ici des informations sur : Le résumé du &automanag; contenant une vue d'ensemble initiale du &automanag;, Le document Fonctionnement du gestionnaire Automake décrivant les bases du travail avec le &automanag;, Dans le chapitre Systèmes de construction, nous avons donné un rapide aperçu des systèmes de construction couramment utilisés sur les systèmes &UNIX;. Dans les sections suivantes, nous étudierons ce point plus en détail. Il règne une certaine confusion sur la manière de nommer ce genre de choses. &GNU; parle de « systèmes de construction » lorsqu'il décrit Automake, Autoconf et Libtool. QMake se définit lui-même comme « un outil pour écrire des Makefiles pour différents compilateurs et plates-formes ». Dans &kde; on emploie souvent le terme « systèmes de gestion de projet ». Nous utiliserons ce terme dans un sens plus large pour décrire les environnements intégrés dans &kdevelop; qui servent à organiser et à construire vos projets. Dans le contexte de cette section, toutefois, nous étudierons principalement les « systèmes de construction automatisés ». Si vous avez un programme « Bonjour tout le monde » simple, écrit en C, vous pouvez le compiler et le lier en utilisant &gcc; -o bonjour bonjour.c, puis l'exécuter à l'aide de la commande ./hello : vous n'avez même pas besoin d'un Makefile. Si vous avez une application C comportant plusieurs modules et fichiers d'en-tête et que vous ne l'exécutez que sur votre propre machine (&cad; qu'il s'agit d'une application domestique), il ne vous faut qu'un Makefile simple, qui est assez facile à écrire à la main (consultez info Make pour en savoir plus). Les complications commencent quand : votre code source, la documentation, les graphiques, les sons, les traductions, les fichiers de données, &etc;, se trouvent dans plusieurs dossiers, vous avez une hiérarchie de dossiers et de sous-dossiers, vous utilisez des bibliothèques qui ne font pas partie de l'ensemble &UNIX; traditionnel, comme la bibliothèque Object de &Qt; ou les bibliothèques Desktopde &kde;, vous faites appel à un préprocesseur, pour générer une partie de votre code source, tel que le précompilateur MOC de Qt, vous projetez de distribuer votre application dans le monde entier, à des utilisateurs qui peuvent ne pas avoir les mêmes système, logiciels et matériel &UNIX;/&Linux; que vous, vous exigez une fonction Install et Uninstall automatisée, vous envisagez que votre application fasse partie de l'ensemble du Bureau &kde;. Si vous êtes dans une, ou toutes les situations décrites ci-dessus, vous avez certainement besoin d'un système de construction. Dans l'exemple précédent, nous avons utilisé &gcc; pour compiler et construire le programme « Hello World », mais tous les compilateurs C ne sont pas appelés « &gcc; ». Par conséquent, si vous distribuez votre application à quelqu'un qui utilise un autre compilateur C, votre Makefile doit d'une façon ou d'une autre employer le nom du compilateur de cette personne, sinon votre application ne pourra pas compiler — il ne s'agit là que d'un exemple simple de ce qui peut poser problème. Un système de construction résoudra ces différences à votre place. Il vérifiera que les bibliothèques dont vous avez besoin sont présentes sur chaque machine de destination. recherchera automatiquement dans tous vos dossiers d'application les fichiers à prétraiter, compiler ou installer et installera les composants de votre application dans les dossiers corrects, en s'assurant que les dossiers sont créés dans la machine de destination comme exigé. En bref, un système de construction offre des méthodes fiables et sécurisées pour que votre application soit compilée et installée correctement sur n'importe quelle machine de destination. Comme nous l'avons montré auparavant dans le chapitre consacré à la vue d'ensembles desSystèmes de gestion de projet, &kdevelop; offre trois systèmes de construction automatisés et la possibilité de créer votre propre Makefile, en bref (cliquez sur les noms des projets pour obtenir plus d'informations) : Les projets automake qui utilisent les outils de développement standard de &GNU;. Les projets QMake qui utilisent le gestionnaire de projets QMake Trolltech. Les projets ANT qui utilisent le gestionnaire de projet Apache ANT pour le développement &Java;. Les projets personnalisés qui exigent que vous mainteniez vos propres Makefiles. Du fait qu'une de ces quatre alternatives doit être choisie lorsque vous créez un projet et que le choix est difficile à modifier ultérieurement, vous devrez y accorder beaucoup d'attention avant de démarrer. Il y a plusieurs tutoriels disponibles sur le système de construction de &GNU; (Autoconf, Automake et Libtool) qu'utilise l'&automanag;. Un court tutoriel autoconf écrit par Christopher W. Curtis est disponible sur la page d'accueil de &kdevelop;. Il se concentre sur quelques étapes de base pour modifier un Makefile. Vous trouverez un tutoriel plus détaillé dans un plus grand éventail de tutoriels dans « Developing software with GNU ». Et citons pour finir le célèbre « Goat Book », intitulé « Autoconf, Automake, and Libtool ». Il s'agit d'une introduction facile à lire, concise, de tous les aspects principaux des Autotools de &GNU;. L'&appwizard; a configuré quelques fichiers Makefile.am initiaux lorsque vous avez créé un Nouveau projet d'un type qui utilise le système de construction de &GNU;, comme C++ KDE Fenêtre de l'application. Au cours du développement, l'&automanag; crée les autres fichiers Makefile.am pour les projets qui utilisent le système de construction de &GNU; et les maintient tous, y compris ceux créés à l'identique par l'&appwizard; et l'&automanag;. Il y aura un seul fichier Makefile.am dans chaque dossier de votre projet à contenir des fichiers à compiler ou à installer. Il contiendra vos spécifications pour la compilation, la construction et l'installation de fichiers, ainsi qu'une référence à tout sous-répertoire ayant aussi un fichier Makefile.am et, éventuellement, à quelques fichiers à compiler, construire et installer. Les dossiers et les fichiers sources de votre projet peuvent être structurés à n'importe quelle profondeur : vous pouvez aussi préférer une structure de projet plate avec tous les sous-dossiers au premier niveau. Le but du système de construction de &GNU; est de produire des structures de fichiers de code source qui peuvent être compilés, construits et installés sur n'importe quel système &UNIX; ou &Linux; à des commandes simples : ./configure make make install # Habituellement en tant que « root ».. et désinstallés par la commande make uninstall (habituellement en tant que « root »). Comment ceci fonctionne-t-il  ? configure est un script qui règle les points de détail quel que soit le système dans lequel il se trouve, tels que le compilateur et les bibliothèques à utiliser, où elles se trouvent, puis crée des fichiers Makefile récursifs en complétant les substitutions dans les fichiers Makefile.in correspondants. Les fichiers Makefile.in sont des fichiers « d'entrée » — des modèles qui fournissent des informations de base pour les Makefiles qui en résulteront en complétant certaines informations en fonction du système. Ils sont générés par l'utilitaire Automake à partir des fichiers Makefile.am. Le processus qui consiste à partir d'un Makefile.am (.am désigne des modèles de fichiers « Automake ») vers des fichiers Makefile est géré automatiquement par le &promanag; de &kdevelop;, à l'aide de l'utilitaire Autoconf, des macros M4 et autres complexités dans lesquelles il n'est pas nécessaire de se lancer ici. Par conséquent, quand make s'exécute, il choisit automatiquement les éléments qu'il faut dans l'environnement actuel, comme les compilateurs et les bibliothèques. De la même manière, make install place les composants de votre application, comme les exécutables, la documentation et les fichiers de données dans les endroits qui conviennent pour cet environnement. Si vous distribuez votre application sous forme de « tarball » (un seul fichier compressé que &kdevelop; peut créer pour vous), il inclut les fichiers Makefile.in et le fichier de script configure, de façon à ce que le destinataire puisse compiler, construire et installer votre application sans avoir Automake, Autoconf ou &kdevelop; sur sa machine. Les fichiers Makefile.am sont également inclus, juste au cas où le destinataire ait besoin d'une modification quelconque du code source. Les règles sont plutôt différentes si vous distribuez via un référentiel de code sur le Web tel que &cvs; de &kde;. Il génère des fichiers Makefile.am dans des sous-dossiers qu'il connaît en tant que « sous-projets ». Il met à jour les fichiers Makefile.amau fur et à mesure que la structure du projet change. Il met à jour les fichiers Makefile.am au fur et à mesure que des fichiers sont ajoutés ou supprimés du projet. Il accepte des définitions sur la manière dont les divers fichiers doivent être compilés ou installés, et modifie le Makefile.am en conséquence. Il accepte les paramètres utilisés lors de la construction ou de l'installation (&pex;, les noms des bibliothèques) et s'assure qu'elles sont utilisées dans les étapes requises de compilation et de construction. Un fichier Makefile.am comporte des lignes contenant des noms de variables suivis d'un signe égale et d'une liste de fichiers ou de valeurs de paramètres. Les « variables » ont des noms en deux parties, comme bin_PROGRAMS, monapp_SOURCES ou kdelnk_DATA. La seconde partie est appelée primaire et représente un élément à construire ou à installer. La première partie est appelée préfixe et représente : un dossier dans lequel effectuer l'installation (&pex;, bin), un qualificateur pour la primaire (&pex;, monapp pour SOURCES, indiquant que les fichiers souces répertoriés après monapp_SOURCES vont construire monapp), un préfixe spécial noinst (abrégé pour « no installation »), habituellement utilisé pour répertorier les fichiers d'en-têtes du programme (.h), ou le préfixe spécial EXTRA, pour tous les éléments dépendants de la configuration. Pour plus d'informations sur les fichiers Automake et Makefile.am, consultez la page info Automake. Avant tout, &automanag; crée et met à jour les noms de variables et les listes de fichiers ou de paramètres. Reportez-vous à l'exemple suivant d'un Makefile.am pour une application classique, appelée monapp. ## Makefile.am pour monapp # voici le programme en cours d'installation. Son nom est utilisé pour toutes # les autres variables de Makefile.am bin_PROGRAMS = monapp # définissez le chemin des inclusions pour X, qt et KDE INCLUDES = $(all_includes) # le chemin de recherche des bibliothèques. monapp_LDFLAGS = $(KDE_RPATH) $(all_libraries) # les bibliothèques auxquelles se lier. monapp_LDADD = $(LIB_KFILE) $(LIB_KDEPRINT) # les sources qui devront être compilées pour monapp monapp_SOURCES = main.cpp monapp.cpp monappvue.cpp # voici les en-têtes pour votre projet noinst_HEADERS = monapp.h monappvue.h # demandez à automoc de gérer tous les fichiers sources META (moc) METASOURCES = AUTO KDE_ICON = monapp # voici l'endroit où s'insérera le fichier kdelnk kdelnkdir = $(kde_appsdir)/Utilities kdelnk_DATA = monapp.desktop # voici l'endroit où s'insère le fichier de ressources XML-GUI rcdir = $(kde_datadir)/monapp rc_DATA = monappui.rc AM_CXXFLAGS = -DMY_C++_PREPROCESSOR_OPTION Comme vous pouvez le constater, nombre des éléments du côté droit sont des symboles de la forme $(xxx). Ce sont des variables d'environnement qui sont définies dans l'environnement &kde; proprement dit et substituées par des valeurs réelles quand ./configure génère les fichiers Makefile finaux dans la machine de destination. De plus, quelque temps après avoir démarré avec &kdevelop;, il est judicieux d'exécuter la commande ./configure --help qui affiche la liste des éléments que vous pouvez changer au moment de la construction et de l'installation, comme pour un environnement de test. En particulier, la commande : ./configure --prefix=/where/you/wish redirigera l'installation entière vers une structure de dossiers de votre choix, en modifiant la variable interne $(prefix) vers la valeur /où/vous/le/souhaitez. Vous trouverez dans ce chapitre une description minimale des éléments du gestionnaire Automake et de leur utilisation. Il couvre : La fenêtre du gestionnaire Automake : décrit la structure de base de la fenêtre principale du gestionnaire Automake. La fenêtre d'affichage global : décrit les éléments de la sous-fenêtre supérieure. La fenêtre d'affichage détaillé : décrit les éléments de la sous-fenêtre inférieure. Navigation dans la gestionnaire Automake : répertorie quelques opérations fondamentales que vous pouvez exécuter dans le gestionnaire Automake. Menus contextuels dans le &automake; : décrit les fenêtres qui apparaissent lorsque vous choisissez une action dans le &automake;. Le gestionnaire Automake s'exécute dans une fenêtre scindée. La partie supérieure est appelée Vue globale et la partie inférieure Vue détaillée. Entre les deux, se trouve un barre étroite que l'on peut faire glisser avec la souris pour ajuster la taille des affichages. En mode IDEAl, vous pouvez aussi faire glisser le côté de la fenêtre scindée pour en changer la largeur. Sur la partie supérieure de chaque fenêtre, on trouve une barre d'outils dont les boutons seront activés lors de la sélection d'un élément dans cette vue. Celle-ci offre un moyen d'accéder aux actions prévues pour cet élément d'affichage. L'autre concerne les menus contextuels qui apparaissent lorsqu'on clique avec le bouton droit de la souris comme nous le verrons ci-après. En mode IDEAl, il y a deux petits boutons supplémentaires sur le côté gauche de la barre de titre de la fenêtre de l'&automanag; — une flèche droite de forme triangulaire et un bouton à point. Le bouton fléché sert à fermer la fenêtre. Le bouton à point quant à lui gardera la fenêtre ouverte même si une autre fenêtre &kdevelop; a été sélectionnée. (Sinon, la fenêtre de l'&automanag; se fermera automatiquement chaque fois qu'une autre fenêtre obtient le focus d'entrée.) La fenêtre globale d'affichage offre une liste arborescente de tous les dossiers de votre projet qui contiennent des fichiers de programme, de la documentation ou des données. Chaque dossier de ce type contenant un fichier Makefile.am est connu dans l'&automanag; en tant que sous-projet. Il y a trois sous-projets typiques dans un projet basé sur &kde;, comme représenté dans l'illustration ci-dessus : src — les fichiers de code source de votre application, doc — votre manuel utilisateur, po — extraits de chaînes dans vos fichiers de code source qui exigent d'être traduits dans d'autres langages humainement compréhensibles (&pex;, des titres de fenêtres, des noms de menus, des étiquettes de boutons, le texte des boîtes de dialogue et des messages de différentes sortes). Notez que le sous-projet doc comporte toujours un sous-projet en que vous pouvez voir si vous cliquez sur le symbole + à côté du mot doc. Ceci est dû au fait que la langue de base de toute la documentation de &kde; est en anglais (en). Si votre application devient partie intégrante de &kde;, les équipes de traduction de &kde; peuvent traduire votre documentation de l'anglais vers d'autres langues, et les traductions s'intégreront dans d'autres sous-projets, comme fr (le français), de (l'allemand). Les chaînes inclues dans le sous-projet po sont également susceptibles d'être traduites et enregistrées dans d'autres fichiers en po, ce qui permet à votre application d'être utilisée par des personnes qui ne connaissent pas l'anglais. Les sous-projets doc et po servent différents objectifs. doc contient de la documentation, comme un manuel utilisateur, po contient des chaînes de texte traductibles de l'interface utilisateur, qui est intégrée dans le code source de cette application. La fenêtre globale d'affichage sert — entre autres choses — d'outil de navigation. Si vous sélectionnez un sous-projet dans le fenêtre globale d'affichage, les détails correspondant seront affichés dans la fenêtre d'affichage détaillée. La vue détaillée contient une liste arborescente de tous les fichiers du sous-projet actuellement sélectionné dans la vue globale, ainsi que les règles de compilation, de construction et d'installation de ce sous-projet. Ainsi, les deux vues ensemble peuvent vous donner accès à tous les composants de votre application et à toutes les informations sur la manière de compiler, construire et installer celle-ci. La liste arborescente de la vue détaillée comporte deux niveaux. Le premier niveau consiste en ce qu'on appelle les cibles du &automanag; et le second niveau contient des listes de fichiers qui vont composer chaque cible. Ce concept d'une cible du &automanag; diffère quelque peu de ce qu'est d'ordinaire une cible Makefile. En bref : La définition de la manière dont il faut compiler, construire ou installer un ensemble de fichiers est connu en tant que cible dans le &automanag;, mais comme variable dans Automake lui-même. Une cible dans make prend souvent différents aspects : paramètre d'une commande make (&pex;, make install, make clean). Cependant, certaines variables Makefile.am représentent une sous-cible sous-jacente dans make. Dans la vue globale et la vue détaillée, un clic gauche sur le signe + ou - situé à côté d'un sous-projet ou d'un nom de cible permet de développer ou de réduire la vue arborescente. La même chose avec un sous-projet dans la vue globale affiche ou masque les sous-projets au prochain niveau inférieur (s'il y a lieu). SI vous le faites avec une cible dans la vue détaillée, vous affichez ou masquez la liste de fichiers qui vont dans cette cible. Ouverture d'un fichier pour édition Un clic avec le &BGS; sur le nom d'un fichier dans la vue détaillée fait s'ouvrir le fichier correspondant dans la fenêtre d'édition de &kdevelop;. Activation des boutons de barre d'outils du &automanag; Un clic avec le &BGS; sur le nom d'un sous-projet dans la vue globale ou d'une cible dans la vue détaillée permet de mettre son nom en surbrillance et ainsi d'activer certains boutons de la barre d'outils dans la partie supérieure de cette vue. Il est recommandé d'utiliser le bouton droit de la souris et les menus contextuels au lieu des boutons de la barre d'outils car il est beaucoup plus facile de voir et de comprendre ce que vous faites. Les opérations sur les sous-projets et les cibles ont des effets considérables sur la structure, la compilation, la construction et l'installation de votre application. Sélection des actions / Menus qui apparaissent Un clic avec le &BDS; sur le nom d'un sous-projet, d'une cible ou d'un fichier fait apparaître un menu, et vous pouvez alors sélectionner des actions à exécuter sur le sous-projet, la cible ou le fichier, comme ajouter une cible au sous-projet, ajouter un fichier à une cible ou supprimer logiquement le fichier sélectionné de sa cible. Les sections suivantes décrivent brièvement quelles opérations les menus rendent disponibles, lesquels appraîtront lors de clics avec le bouton droit de la souris dans la fenêtre du &automanag;. Elles sont exclusivement destinées à la vue globale. Vous trouverez des descriptions détaillées de la plupart des opérations dans un chapitre ultérieur. Lorsque vous cliquez avec le &BDS; sur un nom de fichier dans la vue détaillée, le menu suivant apparaît, vous permettant de sélectionner une des quelques opérations à effectuer sur ce fichier. Dans l'illustration présentée sous hi-16app-monapp.png, le fichier d'icône a été sélectionné à partir de la cible Icônes dans monapp du sous-projet monapp/src. L'élément principal du menu contextuel d'un fichier est Supprimer le fichier de sa cible (&cad; qu'il ne sera plus utilisé pour compiler, construire ou installer cette cible). L'élément CVS offre une diversité d'opérations via CVS sur la fichier. L'élément Ouvrir avec vous permet d'ouvrir le fichier avec divers éditeurs ou n'importe quelle autre application (&pex;, vous pouvez ouvrir le fichier d'icône de notre exemple avec KIcon). L'élément Perforce est employé pour des opérations similaires à celles de CVS avec le système commercial de contrôle de versions « Perforce ». Un clic droit sur une cible dans la vue détaillée fait apparaître le menu suivant, vous permettant de sélectionner une des quelques opérations à effectuer dessus. Dans l'illustration présentée sous la cible monapp (programme dans bin), la cible du sous-projet monapp/src a été sélectionnée. L'élément Options pour une cible ne s'applique qu'aux fichiers de code source. Dans la boîte de dialogue correspondante, vous pouvez spécifier les drapeaux d'éditeur de liens et les chemins qui devront servir à repérer les bibliothèques et fournir une liste des bibliothèques réelles à lier dans votre application. L'élément Créer un nouveau fichier fait aparaître une boîte de dialogue dans laquelle vous pouvez définir le nom et le type de fichier à générer (à partir d'une liste déroulante). L'élément Ajouter les fichiers existants fait apparaître une boîte de dialogue dans laquelle vous pouvez ajouter un fichier déjà existant à cette cible. L'élément Supprimer pour une cible vous permet de supprimer logiquement la cible et tous ses fichiers de la structure de projet. L'élément Construire la cible active ne s'applique qu'aux cibles contenant des fichiers de code source. Les nouveaux fichiers seront toujours ajoutés à ce type de cible active. L'élément Construire la cible appelle toutes les opérations de compilation et de « make » nécessaires pour construire le code pour cette cible exclusivement. Lorsque vous cliquez avec le &BDS;. sur un sous-projet dans la fenêtre globale d'affichage, le menu suivant apparaît, vous permettant d'apporter des changements majeurs à la structure de votre projet et à la manière dont il est compilé, construit et installé. Vous pouvez l'utiliser pour développer ou modifier la structure de base du projet que l'&appwizard; a créé. L'élément Options pour un sous-projet contrôle la manière dont le sous-projet sera compilé, construit et installé. La boîte de dialogue qui apparaît comporte des onglets pour le compilateur, les inclusions, les préfixes et l'ordre de construction. L'élément Ajouter un sous-projet crée un nouveau dossier et un un fichier de squelette Makefile.am. L'élément Ajouter une cible fait apparaître une boîte de dialogue dans laquelle vous pouvez définir des règles pour compiler, construire ou installer un groupe de fichiers au sein de votre sous-projet. Ajouter un service (... à écrire ...) Ajouter une application (... à écrire ...) Ajouter un sous-projet existant (... à écrire ...) L'élément Supprimer un sous-projet dans le menu contextuel pour un sous-projet est le moyen approprié de supprimer un sous-projet. Son rôle est d'ajuster les fichiers Makefile.am en conséquence. Cette option vous offre également la possibilité de supprimer tous les fichiers (ou les liens) dans le sous-dossier correspondant. Bien évidemment, cette fonctionnalité devra être utilisée avec prudence. L'élément Construire appelle toutes les opérations de compilation et de « make » nécessaires pour construire le code de ce sous-projet exclusivement. Forcer la réédition (... à écrire ...) Nettoyer (... à écrire ...) Installer (... à écrire ...) Installer (utilisateur « root ») (... à écrire ...) autoproject &automake; &autoconf; &libtool; (... à écrire ...) script configure script config.status Makefile.in config.h.in Makefile.in en Makefile prefix = @prefix@ INSTALL = @INSTALL@ build_triplet = @build@ CXX = @CXX@ prefix = /home/bernd/kde3 INSTALL = /usr/bin/ginstall -c -p build_triplet = i686-pc-linux-gnu CXX = g++ config.h.in en config.h /* Précisez si vous avez libz */ #undef HAVE_LIBZ /* La taille d'un « int », comme calculé par sizeof. */ #undef SIZEOF_INT /* Précisez si vous avez libz */ #define HAVE_LIBZ 1 /* La taille d'un « int », comme calculé par sizeof. */ #define SIZEOF_INT 4 (... à écrire ...)

-rpath PIC static modules externes  non indéfinis Makefile build.xml (... à écrire ...) (... à écrire ...) (... à écrire ...)