FR2965078A1 - Procede et dispositif de compilation pour applications logicielles dependantes - Google Patents

Abstract

L'invention a notamment pour objet la compilation automatique d'applications logicielles dépendantes, notamment d'une première application élémentaire dépendante d'une seconde application élémentaire, ces applications élémentaires étant liées à une même application, dans un système de traitement de données centralisé (112) relié à une base de données (110) comprenant un fichier source associé à la première application élémentaire, la seconde application élémentaire et des directives de compilation de la première application élémentaire. Après avoir identifié un domaine contrôlé de travail d'une version prédéterminée de ladite application, le fichier source est obtenu à partir de la base de données. La seconde application élémentaire est alors accédée à partir du domaine contrôlé de travail. Le fichier source associé à la première application élémentaire est ensuite compilé selon lesdites directives de compilation.

Description

La présente invention concerne la compilation d'applications logicielles et plus particulièrement un procédé et un dispositif de compilation pour applications logicielles dépendantes. Les applications logicielles sont généralement développées dans un langage source, par exemple en langage C. Elles comprennent souvent un ensemble d'applications élémentaires ou d'outils indépendants ou partiellement dépendants. Typiquement, un développeur ou une équipe de développeurs écrit des fichiers en langage source puis compile ces fichiers, selon une cible particulière correspondant à un environnement d'exécution, avec les fichiers nécessaires, notamment des fichiers d'en-tête et des fichiers comprenant des directives de compilation. La compilation permet d'obtenir un ensemble de fichiers exécutables représentant une application élémentaire ou un outil de l'application visée. Après compilation, l'application élémentaire ou l'outil peut alors être testé. Si une erreur est détectée ou si certains aspects doivent être améliorés, les fichiers sources sont modifiés.

Pour compiler et tester des applications élémentaires ou des outils, il est souvent nécessaire d'installer au préalable d'autres applications élémentaires ou outils permettant de résoudre des liens de dépendance de l'application élémentaire visée. A titre d'illustration, le noyau d'un système d'exploitation pour ordinateur est typiquement constitué de plusieurs outils dépendants. Par conséquent, pour compiler une partie de ce noyau, il est généralement nécessaire de disposer d'autres outils de ce dernier. A titre d'illustration, la compilation d'un noyau Linux (appelé kernel en terminologie anglo-saxonne, Linux est une marque) nécessite généralement certains outils tels que 'mkinitrcf pour créer une image d'amorçage (appelé boot en terminologie anglo-saxonne) qui est chargée en mémoire vive (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) ou 'depmod qui permet de créer un arbre de dépendances et des chemins des modules (notamment des pilotes ou drivers en terminologie anglo-saxonne). Dans la version Red Hat de Linux (Red Hat est une marque), il existe un outil de gestion d'applications appelé RPM (sigle de Red Hat Package Manager en terminologie anglo-saxonne) permettant notamment d'installer et de mettre à jour des applications à l'aide de commandes simples. Un RPM comprend un ensemble de fichiers constituant une application. Pour une application, il existe généralement plusieurs RPMs correspondant à différentes versions de celle-ci.

Chaque RPM est réalisé à partir d'un RPM source, comprenant un ensemble de fichiers sources, permettant de générer l'application selon différents environnements d'exécution. Le RPM source comprend non seulement les fichiers sources, par exemple des fichiers de code (*.c) et des fichiers d'en-tête ou de définition (*.h) permettant de compiler l'application correspondante, mais également un ensemble de fichiers utilisés pour la compilation dont certains définissent l'ordre de compilation des fichiers sources ainsi que des fichiers permettant l'installation de l'application. Ainsi, lors du développement d'applications basées sur plusieurs applications élémentaires ou outils, les développeurs créent leurs propres RPMs représentant une ou plusieurs applications élémentaires, c'est-à-dire une partie de l'application visée, dans un espace de production de programmes qui leur est propre pour tester les codes qu'ils développent. Cependant, l'espace de production de programmes évolue généralement de façon continuelle car certains RPMs sources requièrent la présence d'autres RPMs aux fins de compilation pour des raisons de dépendance. L'espace de production de programmes utilisé pour la compilation est donc « pollué » par ces RPMs qui ne sont pas nécessairement validés. Lorsque les applications élémentaires sont développées, les RPMs ou les RPMs sources correspondants sont transmis à un gestionnaire de projet ou un intégrateur avec une référence de version. Lorsque celui-ci a reçu tous les RPMs ou tous les RPMs sources de toutes les applications élémentaires correspondant à une version donnée de l'application visée, il peut créer une structure fonctionnelle pour permettre l'installation de cette application, par exemple une image d'installation pouvant être stockée sur un disque d'installation de type CD-ROM. En raison de nombre d'intervenants dans la conception d'une application et des délais de conception généralement réduits pour la délivrance de celle-ci, il est difficile de gérer un espace de production correspondant à une version donnée d'une application et permettant une intégration rapide de celle-ci. L'invention permet de résoudre au moins un des problèmes exposés 10 précédemment. L'invention a ainsi pour objet un procédé de compilation automatique d'au moins une première application élémentaire dépendante d'au moins une seconde application élémentaire, lesdites au moins une première et seconde applications élémentaires étant liées à une même application, ce procédé étant 15 mis en oeuvre dans un système de traitement de données centralisé relié à au moins une base de données comprenant au moins un fichier source associé à ladite au moins une première application élémentaire, ladite au moins une seconde application élémentaire et des directives de compilation de ladite au moins une première application élémentaire, ce procédé comprenant les étapes 20 suivantes, - identification d'un domaine contrôlé de travail d'une version prédéterminée de ladite application ; - obtention dudit au moins un fichier source à partir de ladite au moins une base de données ; 25 - accès à ladite au moins une seconde application élémentaire à partir dudit domaine contrôlé de travail ; et, - compilation dudit au moins un fichier source associé à ladite au moins une première application élémentaire selon lesdites directives de compilation. 30 Le procédé selon l'invention permet ainsi d'effectuer des compilations de fichiers sources de façon centralisée. Il permet la résolution automatique des dépendances respectant l'intégrité de l'espace de production de programmes utilisé. Ce dernier n'est pas pollué par l'installation de produits nécessaires à la compilation de fichiers sources, les fichiers nécessaires à la compilation étant accédés dynamiquement selon les relations de dépendance. De façon avantageuse, ladite au moins une seconde application élémentaire est disponible sous forme d'au moins un fichier source, appelé au moins un second fichier source, le procédé comprenant en outre une étape de compilation de ladite au moins une seconde application élémentaire, mémorisation d'un résultat de compilation de ladite au moins une seconde application élémentaire et définition d'au moins un lien, dans ledit domaine contrôlé de travail, vers ledit résultat de compilation. Le procédé selon l'invention offre ainsi la possibilité de compiler un ensemble de fichiers sources à tout moment en s'affranchissant des dépendances entre eux. Il offre également la possibilité de tester une compilation entière dans un autre environnement (test en avance de phase par exemple), ce qui permet notamment d'estimer un taux de réussite de compilation. Le procédé selon l'invention permet également d'anticiper des problèmes de compilation et d'installation car les développeurs peuvent livrer à tout moment une version, même non finalisée, de leur produit. En outre, l'accès dynamique aux fichiers nécessaires aux compilations permet de localiser les produits dépendants pour trouver, en particulier, des fichiers de type librairie (libs) et des fichiers de déclaration (includes) d'autres produits. Le procédé comprend en outre, de préférence, une étape de création dudit domaine contrôlé de travail. Avantageusement, celle-ci comprend une étape d'établissement d'un lien avec héritage avec un domaine contrôlé de travail préalablement créé pour le développement d'une version de ladite application antérieure à ladite version prédéterminée. Ainsi, il est possible de livrer un ensemble d'applications cohérentes compilées dans un seul environnement correspondant, par exemple, à un environnement installé chez un client.

Selon un mode de réalisation particulier, ladite base de données comprend une table de livraison de fichiers sources, ladite étape d'obtention comprenant une étape préalable de vérification de disponibilité dudit au moins un fichier source dans ladite table de livraison. Ainsi, il est possible de contrôler l'exécution de compilation de fichiers sources selon leur disponibilité. De façon avantageuse, le procédé comprend en outre une étape de consultation périodique de ladite table de livraison, ledit au moins un fichier source étant automatiquement compilé lorsque ledit au moins un fichier source et ladite au moins une seconde application élémentaire sont disponibles. Ainsi, des fichiers sources peuvent être compilés automatiquement selon leur disponibilité et la disponibilité des fichiers sources ou des applications dont ils dépendent.

Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de création d'une image d'installation de ladite application comprenant lesdites au moins une première et une seconde applications élémentaires. Le procédé permet ainsi de gérer dynamiquement des images d'installation d'applications. En particulier, des images, notamment des images ISO, peuvent être générées automatiquement. Le procédé comprend en outre, de préférence, une étape d'installation de ladite application à partir de ladite image créée et une étape de test de ladite application installée. Le procédé permet ainsi de tester l'installation, dans une machine virtuelle ou physique, d'images générées automatiquement afin de dépister d'éventuels problèmes d'installation. L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur ainsi qu'un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment. Les avantages procurés par ce programme d'ordinateur et ce dispositif sont similaires à ceux évoqués précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, 30 au regard des dessins annexés dans lesquels : - la figure 1 illustre schématiquement un exemple d'environnement mettant en oeuvre l'invention pour créer une structure fonctionnelle permettant l'installation d'une application basée sur des applications élémentaires dépendantes ; - la figure 2 illustre schématiquement le principe d'héritage d'un domaine contrôlé de travail d'un espace de production de programmes, mis en oeuvre conformément à l'invention ; - la figure 3 illustre un exemple de certaines étapes mises en oeuvre dans le système de traitement de données illustré sur les figures 1 pour compiler des fichiers sources et intégrer les résultats de compilation dans une structure fonctionnelle permettant l'installation de l'application correspondante ; - la figure 4 illustre schématiquement une structure de bases de données pouvant être utilisées pour stocker les données relatives à une version d'une application en cours de développement et permettre une compilation automatique des fichiers sources et une intégration des résultats de compilation dans une structure fonctionnelle permettant l'installation de l'application correspondante ; et, - la figure 5 illustre un exemple d'architecture d'un calculateur adapté à mettre en oeuvre l'invention, notamment l'algorithme décrit en référence à la figure 3. L'invention a notamment pour objet un système automatique pour obtenir et compiler des fichiers sources ou partiellement compilés d'applications élémentaires dépendantes d'une version donnée d'une application basée sur ces dernières, ainsi que pour intégrer ces applications élémentaires dans une structure fonctionnelle permettant l'installation de cette application. La gestion de fichiers sources, leur compilation et la création d'une structure fonctionnelle permettant d'installer une application basée sur ces fichiers sources sont, de préférence, réalisées de façon centralisée. La figure 1 illustre schématiquement un exemple d'environnement mettant en oeuvre l'invention pour créer une structure fonctionnelle permettant l'installation d'une application basée sur des applications élémentaires dépendantes. L'environnement de développement 100 permet à un gestionnaire de projet 102 de définir l'architecture de l'application développée, à des développeurs 104 de développer les fichiers sources nécessaires, à un intégrateur 106 d'intégrer des applications élémentaires et à un vérificateur 108 de vérifier l'application développée. Toutes les données sont ici mémorisées de façon centralisée dans un système de stockage 110. Il s'agit par exemple de bases de données dans un serveur de stockage. La gestion des fichiers sources, leur compilation et l'intégration des résultats de compilation sont réalisées de façon centralisée dans un système 112. L'application créée peut être installée et testée sur un système dédié 114 tandis que son image peut être utilisée pour graver un disque d'installation 116 de cette application.

Le gestionnaire de projet 102 définit l'architecture de l'application développée et transmet (étape 150) cette architecture, avec des numéros de version, à l'intégrateur 106 qui créé ou met à jour (étape 152) des règles de compilation de fichiers sources et d'intégration des résultats de compilation. L'intégrateur 106 crée également un espace mémoire dans lequel les développeurs peuvent stocker les fichiers sources correspondant à la version de l'application développée préalablement définie. Parallèlement, le gestionnaire de projet 102 informe (étape 156) les développeurs des fonctionnalités requises, des numéros de version correspondant, des délais de développement, etc..

Les développeurs peuvent alors développer les fichiers sources à la base de l'application visée pour permettre la compilation automatique de ces fichiers dans un domaine contrôlé de travail, aussi appelé SDB (sigle de sandbox en terminologie anglo-saxonne), d'un espace de production de programmes, aussi appelé PDP dans la suite de la description, du système 112. Contrairement à l'espace de production de programmes, le domaine contrôlé de travail de l'espace de production de programmes du système 112 est lié à la version de l'application développée. Comme décrit ci-dessous, chaque développeur hérite d'un domaine contrôlé global de travail. Ce domaine hérité lui est propre mais contient toutes les données dont il a besoin pour lui permettre ses développements. En d'autres termes, un mécanisme de conservation de résultats de compilation est utilisé pour, ensuite, exporter des variables de localisation de ces résultats et, ainsi, permettre aux applications qui en sont dépendantes d'utiliser ces variables pour localiser les fichiers dont elles ont besoin pour leur propre compilation. Pour permettre leur compilation automatique, les fichiers sources d'une application élémentaire doivent être mémorisés (étape 158) dans l'espace mémoire correspondant à la version de l'application développée. Les fichiers sources peuvent être transmis en tant que tels, sous forme de RPM sources ou, dans certains cas, sous forme de fichiers RPM binaires préalablement compilés. Simultanément, les développeurs indiquent au système 112 la disponibilité des fichiers sources. A ces fins, un indicateur de livraison peut être transmis (étape 160) au système 112. L'indicateur de livraison comprend, de préférence, une référence à la version de l'application pour laquelle les fichiers sources ont été transmis. Ces indicateurs peuvent être mémorisés dans une table associée à la structure de l'application visée de telle sorte qu'en comparant les fichiers sources disponibles à la structure de l'application, il soit possible de déterminer si, en raison des règles de dépendance, les fichiers sources peuvent être compilés. Les fichiers sources peuvent alors être accédés (étape 162) par le système 112 qui peut ainsi effectuer leur compilation (étape 164), en utilisant, le cas échéant, d'autres applications élémentaires comme décrit ci-dessous.

Dès que les fichiers sources sont accessibles ou de façon périodique, par exemple toutes les nuits, le système 112 identifie les fichiers sources disponibles pouvant potentiellement être compilés, c'est-à-dire la présence ou non de tous les fichiers sources contribuant à l'application élémentaire développée. Un tel mode de compilation est, dans la suite de la description, appelé compilation continue. Pour ces fichiers, le système 112 détermine alors s'ils peuvent effectivement être compilés, c'est-à-dire si tous les éléments requis à leur compilation, par exemple la présence d'autres applications élémentaires dépendantes, sont présents. Les fichiers sources identifiés pouvant effectivement être compilés le sont.

Le résultat de la compilation, c'est-à-dire le RPM associé à ces fichiers sources, est alors transmis (étape 166) à l'espace mémoire correspondant à la version de l'application développée. De façon avantageuse, les fichiers sources sont compilés dans plusieurs environnements différents, selon plusieurs cibles, et mémorisés de façon distincte. Lorsque tous les RPMs constituant l'application développée ont été compilés, le système 112 peut les intégrer (étape 170) pour former une structure fonctionnelle permettant l'installation de l'application développée. L'image de cette structure fonctionnelle peut notamment être utilisée pour créer (étape 172) le CD-ROM d'installation 116, réel ou virtuel. L'intégration des RPMs peut être testée (étape 172) sur le système dédié 114 ou sur une machine virtuelle d'un système non dédié. De même, la procédure d'installation de l'application développée peut être testée (étape 174) à partir du CD-ROM 116. Selon un mode de réalisation particulier, chaque opération réalisée par le système 112 donne lieu à l'établissement (étape 176) d'un rapport transmis à l'intégrateur 106 qui peut alors suivre l'évolution du développement de l'application. Ainsi, l'intégrateur 106 peut notamment suivre les étapes de compilation des RPMs et d'intégration de l'application. Ces rapports peuvent être automatiquement transmis, au moins partiellement, par courrier électronique. Après intégration et test, la version développée de l'application est gelée c'est-à-dire qu'elle est placée dans un état interdisant toute modification. Un environnement de travail correspondant à une nouvelle version est alors créé pour permettre la modification des RPMs. A ces fins, l'environnement de travail de la version développée de l'application ainsi que toutes les données correspondantes mémorisées dans l'espace mémoire correspondant à la version de l'application développée sont placés dans un mode de lecture seule. Un mécanisme d'héritage est mis en oeuvre pour permettre le développement de nouvelles versions de l'application en repartant de l'environnement de travail et des données de la dernière version. La figure 2 illustre schématiquement le principe d'héritage d'un domaine contrôlé de travail d'un espace de production de programmes, mis en oeuvre conformément à l'invention. L'espace de production de programmes 200 comprend ici des bases de données 205 où sont notamment stockés les fichiers sources et les directives de compilation, un système de traitement de données 210 comprenant un système d'exploitation, un compilateur, un noyau de système d'exploitation et les outils nécessaires à la compilation d'applications développées ainsi qu'une interface 215, par exemple une interface graphique de type web, permettant d'administrer les règles de compilation de fichiers sources et la définition de variables de domaines contrôlés de travail. Plus précisément, l'interface 215 permet notamment, après authentification, d'accéder à un domaine contrôlé de travail particulier et d'accéder aux bases de données utilisées pour ajouter, modifier, déplacer ou effacer des entrées Pour développer les fichiers sources, chaque développeur utilise un domaine contrôlé de travail qui lui est propre. Ce dernier dérive d'un domaine contrôlé de travail géré par le système de traitement de données 210. Un domaine contrôlé de travail est un environnement de compilation, dans un espace de production de programmes, comprenant typiquement un lien vers les bases de données liées à l'application développée et une cible, c'est-à-dire une spécification de l'environnement d'exécution de l'application développée. Les développeurs, dans leur domaine contrôlé de travail, peuvent mettre en oeuvre un mécanisme de compilation continue similaire à celui décrit ici, pour leurs propres fichiers sources, de façon locale, afin de tester la compilation de leur produits ou tester une compilation avec une dépendance nouvelle non encore livrée au système central de compilation continue (test en avance de phase). Selon un mode de réalisation particulier, des tables d'une base de 25 données peuvent être utilisées pour mémoriser les références des domaines contrôlés de travail. Lorsqu'une application a été intégrée selon une version donnée, le domaine contrôlé de travail ayant servi à cette intégration n'est plus modifiable, il est placé dans un état appelé état de maintenance. 30 Cependant, un domaine contrôlé de travail placé dans un état de maintenance peut être utilisé pour générer un domaine similaire aux fins de mettre à jour l'application, par exemple pour corriger une erreur détectée après son intégration. Ainsi, par exemple, le domaine contrôlé de travail 225 peut être créé et lié par héritage au domaine contrôlé de travail 220. Le domaine contrôlé de travail 225 peut alors être modifié. Ce dernier peut à nouveau être utilisé par un utilisateur pour créer un nouveau domaine contrôlé de travail qui lui sera lié par héritage. L'utilisateur pourra alors travailler dans celui-ci, référencé ici 230. Pour chaque nouvelle version de l'application développée, un nouveau domaine contrôlé de travail est créé. Ainsi, par exemple, lorsque le domaine contrôlé de travail 220 a été placé dans l'état de maintenance, un nouveau domaine contrôlé de travail 235 a été créé. De façon similaire, lorsque le domaine contrôlé de travail 235 a été placé dans l'état de maintenance, un nouveau domaine contrôlé de travail 240 a été créé. Si le domaine contrôlé de travail 235 est lié, par héritage, à un nouveau domaine contrôlé de travail pour permettre la modification de l'application, ici le domaine contrôlé de travail 245, ce dernier est placé dans l'état de maintenance lorsque l'intégration de l'application correspondante est validée. Cependant, celui-ci peut à nouveau être lié, par héritage, à un nouveau domaine contrôlé de travail (domaine contrôlé de travail 250) pour permettre des correctifs. Celui-ci est alors lié à un nouveau domaine contrôlé de travail par un développeur (domaine contrôlé de travail 255) qui effectue les corrections nécessaires. Lorsqu'un développeur travaille sur la dernière version de l'application en cours de développement, il hérite du dernier domaine contrôlé de travail, ici le domaine contrôlé de travail 240. En d'autres termes, le domaine contrôlé de travail utilisé par un développeur, par exemple le domaine contrôlé de travail 260, est lié, par héritage, lors de sa création, au dernier domaine contrôlé de travail lié à l'application en cours de développement. Comme illustré, des développeurs peuvent également hériter du domaine contrôlé de travail d'un autre développeur (références 265 et 270). Un tel mécanisme d'héritage selon lequel les domaines contrôlés de travail sont gelés lorsque l'intégration d'une application a été validée et liés, par héritage, à de nouveaux domaines contrôlés de travail pour permettre à chaque développeur de poursuivre le développement de l'application permet de bénéficier d'un domaine contrôlé de travail stable dans le temps tout en conservant les domaines contrôlés de travail des versions passées de l'application. En d'autres termes, les développeurs peuvent se créer des domaines contrôlés de travail qui leur sont propres à partir de domaines contrôlés de travail préalablement créés, selon leur besoin, c'est-à-dire selon qu'ils travaillent sur la version en cours de développement ou sur une correction d'une version antérieure. La figure 3 illustre un exemple de certaines étapes mises en oeuvre dans le système de traitement de données 112 illustré sur les figures 1 pour compiler des fichiers sources et intégrer les résultats de compilation dans une structure fonctionnelle permettant l'installation de l'application correspondante. Une première étape (étape 300) a pour objet d'identifier les fichiers sources pouvant être compilés, c'est-à-dire les fichiers sources présents dans les bases de données et représentatifs d'une application élémentaire ou d'un outils. A ces fins, le système de traitement de données peut analyser une table de livraison comprenant des références des fichiers sources accessibles, c'est-à-dire des fichiers sources précédemment transmis par des développeurs. Cette étape permet également, le cas échéant, d'identifier les applications élémentaires pouvant être intégrées dans l'application finale, par exemple si les fichiers sources correspondants ne sont pas disponibles ou ont déjà été compilés. Une étape suivante (étape 305) vise à déterminer, parmi les fichiers sources identifiés, ceux qui peuvent être compilés. A ces fins, les références des fichiers sources identifiés sont comparés aux règles d'intégration liées à l'application développée préalablement définies et mémorisées dans une base de données. Comme décrit précédemment, de telles règles sont par exemple déterminées par les développeurs, parfois avec l'aide d'intégrateurs. Ainsi, les fichiers sources d'une application élémentaire non liée à une autre application élémentaire peuvent être compilés. De même, les fichiers sources d'une application élémentaire liée à une autre application élémentaire dont les fichiers exécutables (ou objets) sont disponibles peuvent être compilés. Il en est de même si seuls les fichiers sources de cette autre application élémentaire sont disponibles et peuvent être compilés. Les fichiers sources ainsi déterminés sont ensuite accédés (étape 310) dans la base de données comprenant les données relatives à l'application 5 développée. Les directives de compilation sont alors générées en fonction des fichiers sources disponibles et des règles d'intégration (étape 315). Les fichiers sources déterminés sont alors compilés (étape 320) dans le domaine contrôlé de travail selon les directives de compilation 10 déterminées. Les fichiers exécutables (et/ou objets) sont mémorisés dans les bases de données, dans un espace relatif à l'application en cours de développement. Une indication de compilation des fichiers sources déterminés est, de préférence, mémorisée. Cette indication peut notamment être utilisée pour déterminer si une application peut être intégrée ou si une application 15 élémentaire dépendante de celle-ci peut être compilée. Les applications élémentaires nécessaires à la compilation des fichiers sources déterminés sont, le cas échéant, également compilées lors de cette étape pour permettre la compilation de ces derniers. Les résultats de compilation des applications élémentaires nécessaires à la compilation des 20 fichiers sources déterminés sont mémorisés et des variables liant ces résultats de compilation au domaine contrôlé de travail utilisé sont définies. Ces variables ainsi définies permettent d'accéder aux résultats mémorisés afin de compiler les fichiers sources déterminés. Ainsi, par exemple, si une application élémentaire ayant la référence 25 A doit être compilée et que sa compilation requiert la présence d'une application élémentaire ayant la référence B, cette dernière doit, si elle ne l'a pas déjà été, être préalablement compilée, le résultat de la compilation doit être sauvegardé et des variables doivent être définies (ou exportées vers cette sauvegarde de résultat) pour permettre d'établir un lien avec celle-ci. 30 L'application élémentaire ayant la référence A est alors compilée. A ces fins, les fichiers nécessaires liés à l'application élémentaire ayant la référence B sont localisés et retrouvés à l'aide des variables définies lors de la compilation de l'application élémentaire ayant la référence B. Il est observé que si l'application élémentaire ayant la référence B n'est pas disponible en tant que telle, elle est compilée, en déclenchant, le cas échéant la compilation d'autres applications élémentaires dont elle dépend directement ou indirectement. Un test est ensuite effectué (étape 325) pour déterminer si tous les fichiers sources de l'application développée ont été compilés. Cette étape comprend, par exemple, la comparaison des indications de compilation préalablement mémorisées avec les données d'architecture de l'application en cours de développement. Si tous les fichiers sources n'ont pas été compilés, les étapes précédentes sont répétées (étapes 300 à 325). Comme indiqué précédemment, la compilation automatique peut être lancée par un opérateur, par exemple l'intégrateur, ou de façon automatique, par exemple toutes les nuits. Ainsi, si tous les fichiers sources ne sont pas disponibles et/ou ne peuvent pas être compilés à un instant donné, la compilation se poursuit conformément à l'algorithme illustré sur la figure 3 lorsqu'il est réactivé de façon manuelle ou automatique. Si, au contraire, tous les fichiers sources ont été compilés, la liste des applications élémentaires liées à l'application en cours de développement peut être établie (étape 330) en utilisant, par exemple, les données d'architecture de l'application en cours de développement. Comme suggéré par les traits en pointillé, cette étape n'est pas toujours nécessaire. En effet, la liste des applications élémentaires nécessaires peut être prédéterminée et codée dans les données liées à l'application en cours de développement. Les applications élémentaires sont ensuite intégrées dans une structure fonctionnelle permettant l'installation de l'application en cours de développement et basée sur ces applications élémentaires (étape 335). La structure fonctionnelle créée est, de préférence, conforme au standard ISO (acronyme d'International Organization for Standardization en terminologie anglo-saxonne). L'image de la structure fonctionnelle créée peut être gravée sur un disque d'installation de type CD-ROM.

Comme indiqué précédemment, les applications élémentaires sont compilées selon une cible particulière, par exemple une cible LUSTRE (LUSTRE est un langage synchrone) ou une cible IB (sigle d'InfiniBand en terminologie anglo-saxonne, InfiniBand est une marque). Une cible est ici définie comme un groupement cohérent de RPM, aussi appelés composants. Elle peut être représentée par une image ISO. Il est observé que la cible ne joue pas de rôle dans le processus de compilation mais uniquement dans la création de la structure fonctionnelle permettant l'installation des applications. Une image est créée pour chaque cible visée.

Enfin, l'image d'installation créée peut être utilisée pour installer automatiquement l'application développée et effectuer des vérifications (étape 340). A nouveau, comme illustré par les traits en pointillé, cette étape est optionnelle. La figure 4 illustre schématiquement une structure de bases de données pouvant être utilisées pour stocker les données relatives à une version d'une application en cours de développement et permettre une compilation automatique des fichiers sources et une intégration des résultats de compilation dans une structure fonctionnelle permettant l'installation de l'application correspondante. L'architecture illustrée permet d'intégrer une application pour créer une structure fonctionnelle permettant son installation. Toutes les références aux sources de données (notamment aux fichiers sources et aux fichiers exécutables) sont mémorisées dans ces bases de données avec les informations nécessaires à la compilation. A titre d'illustration, ces bases de données contiennent les 25 informations suivantes liées les unes aux autres selon les liens représentés sur la figure 4, - RCVARS : variables génériques d'environnement, à déclarer dans le fichier de build appli.rc, nécessaires à la compilation ; - RELEASE DELIVERY : définition des cibles des applications 30 élémentaires et leurs fichiers sources non propriétaires, délivrées ; - RELEASE PROPRIETARY : définition de la cible des fichiers sources d'applications élémentaires de type propriétaire, délivrée ; - RELEASE INPUT : version de l'application pour laquelle les sources des applications élémentaires doivent être téléchargées (appelé upload en terminologie anglo-saxonne) dans les bases de données utilisées ; - SOURCE: table principale contenant les détails et les règles de compilation de chaque source ; - DEPENDENCY: liens de dépendance (de compilation), pour chaque source, avec une ou plusieurs applications élémentaires ; - EXPORTVARS : variables temporaires nécessaires à la compilation du fait des dépendances, permet de pointer vers le contenu, mémorisé, de la compilation d'une application élémentaire, du fait de dépendance vers elle ; - SPECMODIF : modifications devant être apportées à un fichier de directives avant la compilation d'une application élémentaire, par exemple l'ajout de variables permettant d'aller chercher des librairies (fichiers de type lib) ou des fichiers de définition (fichiers de type include) d'une application élémentaire déjà compilée, du fait de dépendance vers elle ; - ACTION : actions, par exemple des commandes de type shell ou des définition de variables, devant être effectuées avant et après la compilation ; - UNWANTED : applications élémentaires devant être ignorées pour une application en raison d'une volonté de ne pas les délivrer ; - OWNER : responsable de l'application (il peut s'agir, par exemple, de son adresse électronique qui pourra être utiliser pour lui adresser rapports constitués automatiquement lors des phases de compilation et/ou d'intégration) ; - RELEASE OUTPUT : version de l'application en sortie de la compilation continue, elle contient en général la même version que celle définie en entrée dans la table RELEASE_INPUT mais avec un suffixe propre à la compilation en cours ; - CD SUBDIR : ensemble des répertoires du média à délivrer comprenant l'application ; - TYPE SUBDIR : types de répertoires utilisés ; - FUNC INSTALLATION : contient tous les différents profils d'installation de l'application ; - RPM INSTALLATION RULES : règles d'installation (position dans la structure arborescente des fichiers, mode de mise à jour, appartenance à des groupes d'installation, etc.) de chaque application élémentaire compilée automatiquement ; et, - RPM INSTALLATION RULES TO SOURCE : lien entre une application élémentaire et sa source. Ces bases de données sont référencées dans une base de données d'administration. A chaque référence de bases de données sont associés la cible visée, le domaine contrôlé de travail et l'espace de production de programmes utilisés. Un exemple d'architecture d'un calculateur adapté à mettre en oeuvre l'invention, notamment l'algorithme décrit en référence à la figure 3 est illustré sur la figure 5. Le dispositif 500 comporte ici un bus de communication 502 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 504 (ou CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 506 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter les programmes "Prog" ; - une mémoire vive ou mémoire cache 508 (RAM) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et, - une interface de communication 510 adaptée à transmettre et à recevoir des données. De préférence, le dispositif 500 dispose en outre d'un disque dur 512 pouvant comporter les programmes "Prog" précités et des données traitées ou à traiter selon l'invention.

Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 500 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 500 directement ou par l'intermédiaire d'un autre élément du dispositif 500. Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 512 ou en mémoire morte 506. Selon une variante, le code exécutable des programmes peut être reçu, au moins partiellement, par l'intermédiaire de l'interface de communication 510, pour être stocké de façon identique à celle décrite précédemment.

De manière plus générale, le ou les programmes peuvent être chargés dans un des moyens de stockage du dispositif 500 avant d'être exécutés. L'unité centrale 504 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 512 ou dans la mémoire morte 506 ou dans tout autre élément de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 512 ou la mémoire morte 506, sont transférés dans la mémoire vive 508 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

Claims (10)

1. REVENDICATIONS1. Procédé de compilation automatique d'au moins une première application élémentaire dépendante d'au moins une seconde application élémentaire, lesdites au moins une première et seconde applications élémentaires étant liées à une même application, ce procédé étant caractérisé en ce qu'il est mis en oeuvre dans un système de traitement de données centralisé (112) relié à au moins une base de données (110) comprenant au moins un fichier source associé à ladite au moins une première application élémentaire, ladite au moins une seconde application élémentaire et des directives de compilation de ladite au moins une première application élémentaire, et en ce qu'il comprend les étapes suivantes, - identification d'un domaine contrôlé de travail d'une version prédéterminée de ladite application ; - obtention (310) dudit au moins un fichier source à partir de ladite au moins une base de données ; - accès à ladite au moins une seconde application élémentaire à partir dudit domaine contrôlé de travail ; et, - compilation (320) dudit au moins un fichier source associé à ladite au moins une première application élémentaire selon lesdites directives de compilation.
2. 2. Procédé selon la revendication précédente selon lequel ladite au moins une seconde application élémentaire est disponible sous forme d'au moins un fichier source, appelé au moins un second fichier source, le procédé comprenant en outre une étape de compilation de ladite au moins une seconde application élémentaire, mémorisation d'un résultat de compilation de ladite au moins une seconde application élémentaire et définition d'au moins un lien, dans ledit domaine contrôlé de travail, vers ledit résultat de compilation.
3. 3. Procédé selon la revendication 1 ou la revendication 2 comprenant en outre une étape de création dudit domaine contrôlé de travail.
4. 4. Procédé selon la revendication précédente selon lequel ladite étape de création dudit domaine contrôlé de travail comprend une étape d'établissement d'un lien avec héritage avec un domaine contrôlé de travail préalablement créé pour le développement d'une version de ladite application antérieure à ladite version prédéterminée.
5. 5. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite base de données comprend une table de livraison de fichiers sources, ladite étape d'obtention comprenant une étape préalable de vérification de disponibilité dudit au moins un fichier source dans ladite table de livraison.
6. 6. Procédé selon la revendication précédente comprenant en outre une étape de consultation périodique de ladite table de livraison, ledit au moins un fichier source étant automatiquement compilé lorsque ledit au moins un fichier source et ladite au moins une seconde application élémentaire sont disponibles.
7. 7. Procédé selon l'une quelconque des revendications précédentes, le procédé comprenant en outre une étape de création (335) d'une image d'installation de ladite application comprenant lesdites au moins une première et une seconde applications élémentaires.
8. 8. Procédé selon la revendication précédente comprenant en outre une étape d'installation (340) de ladite application à partir de ladite image créée et une étape de test de ladite application installée.
9. 9. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté sur un ordinateur.
10. 10. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 8.