Packages (Delphi)
Remonter à Bibliothèques et packages - Index
Les packages sont typiquement la méthode préférée d'exportation des éléments autres que les procédures simples et les fonctions. Les bibliothèques doivent seulement être considérées quand l'interopérabilité avec d'autres programmations est une exigence.
Les rubriques suivantes décrivent les packages et divers éléments impliqués dans leur création et leur compilation.
- Déclarations et fichiers source de packages
- Noms des packages
- La clause requires
- Eviter les références de package circulaires
- Références de package dupliquées
- La clause contains
- Eviter les utilisations redondantes de code source
- Compilation de packages
- Fichiers générés
- Directives de compilation spécifiques aux packages
- Commutateurs du compilateur en ligne de commande spécifiques aux packages
Sommaire
Présentation des packages
Un package est une bibliothèque compilée spécialement et utilisée par des applications, par l'EDI ou par les deux. Les packages vous permettent de réorganiser l'emplacement du code sans affecter le code source. On appelle parfois cela le partitionnement d'application.
Les packages d'exécution fournissent des fonctionnalités lors de l'exécution d'une application par un utilisateur. Les packages de conception sont utilisés pour installer des composants dans l'EDI et pour créer les éditeurs de propriétés spéciaux de composants personnalisés. Un même package peut fonctionner à la fois en conception et en exécution, les packages de conception faisant souvent référence à des packages d'exécution dans leurs clauses requires.
Sur Win32, les noms des fichiers package ont l'extension .bpl (Borland package library).
Généralement, les packages sont chargés de manière statique au démarrage d'une application. Vous pouvez cependant utiliser les routines LoadPackage et UnloadPackage (définies dans l'unité SysUtils) pour charger des packages dynamiquement.
Remarque : Quand une application utilise des packages, le nom de chaque unité packagée doit quand même apparaître dans la clause uses de tous les fichiers source qui y font référence.
Déclarations et fichiers source de packages
Chaque package est déclaré dans un fichier source séparé qui doit être enregistré sous l'extension .dpk pour éviter la confusion avec d'autres types de fichier contenant du code Delphi. Le fichier source d'un package ne contient pas de déclarations de type, de données, de procédure ou de fonction. Il contient à la place :
- le nom du package.
- une liste des autres packages nécessaires au nouveau package. Le nouveau package est lié à ces packages.
- une liste des fichiers unité contenus (contains) par ou liés dans le package lors de sa compilation. Le package sert essentiellement d'enveloppe à ces unités de code source, qui fournissent les fonctionnalités du package compilé.
La déclaration d'un package a la forme suivante :
package packageName; requiresClause; containsClause; end.
où packageName est un identificateur valide. requiresClause et containsClause sont facultatifs. Par exemple, le code suivant déclare le package DATAX :
package DATAX;
requires
rtl,
contains Db, DBLocal, DBXpress, ... ;
end.
La clause requires liste les autres packages externes utilisés par le package qui est déclaré. Elle est constituée de la directive requires, suivie d'une liste, délimitée par des virgules, de noms de packages, suivie d'un point-virgule. Si un package ne fait référence à aucun autre package, il n'a pas besoin de la clause requires.
La clause contains identifie les fichiers unité à compiler et à rassembler dans le package. Elle est constituée de la directive contains, suivie d'une liste délimitée par des virgules de noms d'unités, suivie d'un point-virgule. Chaque nom d'unité peut être suivi du mot réservé in et du nom, entre apostrophes, d'un fichier source avec ou sans chemin de répertoire. Le chemin d'accès peut être relatif ou absolu. Par exemple :
contains MyUnit in 'C:\MyProject\MyUnit.pas';
Remarque : Les variables locales thread (déclarées avec threadvar) d'une unité packagée ne peuvent être accessibles aux clients qui utilisent le package.
Noms des packages
La compilation d'un package génère plusieurs fichiers. Par exemple, le fichier source du package DATAX est le fichier DATAX.DPK, sa compilation génère un exécutable et une image binaire appelés
DATAX.BPL et DATAX.DCP
DATAX est utilisé pour faire référence au package dans la clause requires d'autres packages ou pour utiliser le package dans une application. Les noms de packages doivent être uniques dans un projet.
La clause requires
La clause requires liste les autres packages externes, utilisés par le package en cours. Elle fonctionne comme la clause uses d'un fichier unité. Un package externe listé dans la clause requires est automatiquement lié lors de la compilation dans toute application utilisant le package en cours et l'une des unités contenues dans le package externe.
Si les fichiers unité contenus dans un package font des références à d'autres unités packagées, les autres packages doivent être inclus dans la clause requires du premier package. Si d'autres packages sont omis dans la clause requires, le compilateur charge les unités référencées à partir des fichiers .dcu.
Références de package circulaires
Les packages ne peuvent pas contenir de référence circulaire dans leur clause requires. Cela signifie :
- Qu'un package ne doit pas se référencer lui-même dans sa clause requires.
- Qu'une chaîne de références doit se terminer sans référencer un package de la chaîne. Si le package A requiert le package B, alors le package B ne peut pas requérir le package A ; si le package A requiert le package B qui requiert le package C, alors le package C ne peut pas requérir le package A.
Références de package dupliquées
Le compilateur ignore les références dupliquées dans la clause requires d'un package. Néanmoins, dans un souci de clarté et de lisibilité des programmes, il est souhaitable de retirer les références dupliquées.
La clause contains
La clause contains identifie les fichiers unité à lier dans le package. N'incluez pas d'extensions de noms de fichiers dans la clause contains.
Eviter les utilisations redondantes de code source
Un package ne peut apparaître dans la clause contains d'un autre package, ni dans la clause uses d'une unité.
Toutes les unités indiquées directement dans la clause contains d'un package, ou indirectement dans la clause uses de ces unités, sont liées dans le package lors de la compilation. Les unités contenues (directement ou non) dans un package ne peuvent pas être contenues dans d'autres packages référencés dans la clause requires de ce package.
Une unité ne peut pas être contenue (directement ou non) dans plus d'un des packages utilisés par une même application.
Compilation de packages
Les packages sont généralement compilés dans l'EDI en utilisant les fichiers .dpk générés par le gestionnaire de projets. Vous pouvez aussi compiler des fichiers .dpk directement depuis la ligne de commande. Quand vous construisez un projet contenant un package, le package est automatiquement recompilé, si c'est nécessaire.
Fichiers générés
Le tableau suivant liste les fichiers produits par la compilation réussie d'un package.
Fichiers d'un package compilé
| Extension de fichier | Contenu |
|---|---|
|
DCP |
Une image binaire contenant un en-tête de package et la concaténation de tous les fichiers .dcu (Win32) du package. Un seul fichier .dcp ou .dcp est créé par package. Le nom de base du fichier est le nom de base du fichier source .dpk. |
|
BPL |
Le package d'exécution. Sur Win32, ce fichier est une DLL ayant des fonctionnalités spécifiques à RAD Studio. Le nom de base du package est le nom de base du fichier source dpk. |
Directives de compilation spécifiques aux packages
Le tableau suivant liste les directives de compilation spécifiques aux packages qui peuvent être insérées dans le code source.
Directives de compilation spécifiques aux packages
| Directive | Utilisation |
|---|---|
|
{$IMPLICITBUILD OFF} |
Empêche un package d'être implicitement recompilé ultérieurement. Utilisez-la dans les fichiers .dpk lors de la compilation de packages fournissant des fonctionnalités de bas niveau, qui changent rarement entre deux builds, ou dont le code source ne sera pas distribué. |
|
{$G-} ou {$IMPORTEDDATA OFF} |
Désactive la création de références aux données importées. Cette directive augmente les performances d'accès à la mémoire, mais empêche l'unité dans laquelle elle apparaît d'être référencée dans d'autres packages. |
|
{$WEAKPACKAGEUNIT ON} |
Réalise un packaging "faible" des unités. |
|
{$DENYPACKAGEUNIT ON} |
Empêche l'incorporation de l'unité dans un package. |
|
{$DESIGNONLY ON} |
Compile le package pour l'installation dans l'EDI. Cette directive se place dans un fichier .dpk. |
|
{$RUNONLY ON} |
Compile le package à l'exécution seulement. Cette directive se place dans un fichier .dpk. |
L'inclusion de la directive {$DENYPACKAGEUNIT ON} dans le code source, empêche le fichier unité d'être packagé. L'inclusion de {$G-} ou {$IMPORTEDDATA OFF} peut empêcher l'utilisation d'un package dans la même application avec d'autres packages.
Il est possible d'inclure les autres directives de compilation, quand c'est nécessaire, dans le code source d'un package.
Commutateurs du compilateur en ligne de commande spécifiques aux packages
Les commutateurs suivants spécifiques aux packages sont utilisables avec le compilateur en ligne de commande.
Commutateurs du compilateur en ligne de commande spécifiques aux packages
| Commutateur | Utilisation |
|---|---|
|
-$G- |
Désactive la création de références aux données importées. L'utilisation de cette option améliore l'efficacité de l'utilisation de la mémoire, mais empêche les packages compilés, en l'utilisant, de faire référence aux variables définies dans d'autres packages. |
|
LE chemin |
Spécifie le répertoire où placer le fichier package compilé. |
|
LN chemin |
Spécifie le répertoire où placer le fichier package dcp ou dcp. |
|
LUpackageName [;packageName2;...] |
Spécifie d'autres packages d'exécution à utiliser dans une application. S'utilise pour la compilation d'un projet. |
|
Z |
Empêche un package d'être implicitement recompilé ultérieurement. S'utilise lors de la compilation de packages qui fournissent des fonctionnalités de bas niveau, qui changent rarement entre deux builds, ou dont le code source ne sera pas distribué. |
L'utilisation du commutateur -$G- empêche un package d'être utilisé dans la même application avec d'autres packages.
Il est possible d'inclure d'autres options en ligne de commande, quand c'est nécessaire, lors de la compilation de packages.