[delphi] optimiser le contenu de vos zips

Dernière mise à jour le par cs_grandvizir .

= == Alors que Codes-Sources.com fait face à un problème de place sur ses disques durs de plus en plus cruel, il convient d'indiquer aux habitués de DelphiFr.com comment alléger les Zips qu'ils envoient. En effet, parfois 75% des fichiers sont complètement inutiles. ===

Contenu: === ===
== = I) Les fichiers de sauvegarde (*.~*) ===

II) Les applications (*.exe)

III) Les unités compilées (*.dcu)

IV) Les informations de compilation (*.dof ; *.cfg)

V) Les fichiers ressource (*.res)

VI) Si on résume...

==== Ces fichiers sont reconnaissables à leur extension commençant par un tilda: .~dp, .~pa, ~.df... Ils sont créés automatiquement par Delphi, mais peuvent également ne pas être générés. Il faut pour cela aller dans les options de l'éditeur et de décocher la case " Créer des fichiers de sauvegarde ". =
=== === Ces fichiers contiennent la toute dernière version d'un fichier avant le nouvel enregistrement.
=== === Ce système de copie automatique existait déjà avec Turbo Pascal, bien qu'il existe également avec d'autres compilateurs, mais il semblerait manifestement que ce procédé n'est intéressant que pour ceux qui n'effectuent pas d'enregistrements fréquents. Ainsi, ils retrouvent rapidement la dernière sauvegarde. Mais les professionnels de la sauvegarde ne trouvent aucun intérêt via de tels fichiers puisque leur historique est excessivement limité, d'autant plus qu'une sauvegarde par un Zip du dossier-projet est plus organisé (on peut dater et classer les Zip comme on veut) et surtout Delphi permet d'annuler jusqu'à plusieurs centaines d'opérations si bien sûr l'option "Défaire après enregistrement" est activée. En plus, ces fichiers sont mêlés dans le dossier-projet et ne sont donc pas évidents à extraire, et encore, si votre projet est très lourd, ces copies ne font qu'alourdir encore plus le dossier. =
=== === Par ailleurs, ces fichiers tilda n'ont aucune influence sur la compilation du projet, et sont donc complètement inutiles dans les Zips envoyés sur DelphiFr.com.

II) Les applications (*.exe)</souligne> == = === Les codes-sources de DelphiFr.com étant principalement destinés aux utilisateurs de Delphi, il est inutile de fournir des applications complètes de 400 ko. Elles seront vite écrasées par les compilations nouvelles des utilisateurs. On peut également croire que ce sont des sources à virus, bien que l'intérêt du membre CS ne réside a priori pas en ces choses.
=== === Plus les versions de Delphi augmentent et plus les gadgets s'accumulent: cela alourdit en conséquence les applications. Par comparaison, un simple >
Fichier > Nouvelle application entre les versions 3 et 7 aligne 185 ko de différence dans la taille des applications alors qu' n'a été généré (177 ko pour D3, 289 ko pour D5 et 362 ko pour D7). En effet, les composants étant meilleurs de version en version, ils implémentent des fonctionnalités nouvelles non forcément exploitées par l'utilisateur, mais quand même compilées au sein de l'application. Delphi, bien qu'optimisant les applications de manière assez irréprochable, ne peut pas toujours faire la part des choses et se contente donc de compiler les composants.=== === Une solution d'allègement des applications consiste à créer les applications à la manière du C++. Dans les options du projet, dans l'onglet >
Paquets, il y a une case à cocher permettant d'activer les appels à ressources. Mais, pour optimiser au mieux ces appels, il faut décocher les paquets inutiles. Si vous n'utilisez pas de composants pour bases de données, alors décochez les paquets correspondants. Faites de même avec d'autres paquets. Cela a aussi l'avantage d'épurer la palette à composants de l'EDI (=Environnement de Développement Intégré) . == = === Mais finalement, cette technique n'est pas bonne non plus. En effet, un membre ne connaissant pas Delphi mais quand même intéressé par le code source en Delphi se voit confronté au problème de l'existence ou non d'une application. Si l'application est autonome (version lourde), alors cela est en contradiction avec l'esprit d'envoyer des Zips légers. Mais si l'application est en appel à ressources (version légère), le membre remarque une erreur du type: « Ne peut pas trouver le paquet VCL50 ». En effet, ne pas implémenter toutes les ressources dans l'application sous-entend que les fragments ignorés soient existants sur le PC de l'utilisateur, ici via des paquets de la VCL de Delphi. Par exemple, on ne peut pas exécuter un jeu en 3D si aucun moteur 3D n'est installé sur l'ordinateur de l'utilisateur. De plus, Borland fait face à deux problèmes ennuyeux: 1) les paquets recherchés dépendent de la version de Delphi qui a généré l'application et <gras>2) ces paquets ne sont pas distribués sur les nouveaux PC. Même pour ceux qui ont Delphi, l'application légère n'est déjà pas forcément compatible. </gras> =
=== === Au final, les EXE ne servent non plus à rien... sauf si le code source pointe vers un lien URL permettant de télécharger l'application autonome.

III) Les unités compilées (*.dcu) == = === Ces fichiers correspondent au fichier PAS, mais en version compilée. Un tel fichier a le même comportement qu'un PAS, mais a l'avantage supplémentaire de ne pas être modifiable. En revanche, leur inconvénient est qu'ils ne sont pas compatibles entre les versions de Delphi.
=== === Des DCU fournis en guise de code-source sont inutiles puisque illisibles. Ils n'ont pas d'intérêt. On pourrait dire que ce sont des fragments de code qui seront assemblés au fil de la construction du fichier EXE.

IV) == = === Ces fichiers indiquent à Delphi certains paramètres pour la compilation du projet. Via des directives de compilation, il est possible d'interagir sur le processus de compilation. Par exemple
{$I +/-} gère les erreurs d'entrée-sortie des fichiers, {$R} indique quels fichiers ressource seront inclus à l'application mais peut aussi interdire ces incorporations, et avec d'autres on peut gérer les erreurs de division par zéro... etc...=== === Ces options peuvent être paramètrées dans les options du projet. Elles sont alors inclues dans un fichier DOF et/ou CFG. Mais comme toutes les directives ne sont pas modifiées, certaines sont donc redondantes et on ne sait pas lesquelles ont été changées. Delphi a gardé les directives dans la même valeur par défaut pour presque toutes ses versions.
=== === Il est donc plus judicieux d'implémenter directement les directives modifiées au sein du fichier projet DPR. On voit alors directement quelle configuration spéciale l'application doit adopter afin de mieux agir en conséquence. Les composants sont bien forcés d'ajouter les directives au fichier PAS du composant, et alors pourquoi donc une application ne ferait-elle pas de même dans son DPR ? Pour une application console, on ajoute
{$APPTYPE Console} dans le DPR alors que cela est réglable dans les options du projet...=== === Les CFG et DOF ne servent à rien... Certaines versions de Delphi ne gèrent même pas les CFG. Alors pourquoi se surcharger si elles n'en ont pas besoin ?
=== === On peut également enlever les fichiers DDP.

V) Les fichiers ressource (*.res) == = === La plupart du temps, ils ne comportent que l'icône de l'application et c'est même parfois celle par défaut de votre version de Delphi. L'icône qui fait joli est inutile. Mieux vaut l'ajouter dans le Zip en tant que fichier ICO sans l'incorporer au projet. Sinon, ça ferait un fichier ICO, une icône dans le fichier RES et une icône dans l'application EXE.
=== === Le fichier RES contient également les informations de version de l'application, souvent non remplies dans le cadre de DelphiFr.com. Pour remplir ces informations (et pour autoriser ou non leur apparition dans les propriétés de l'application), il faut aller dans les options du projet.
=== === La suppression du fichier RES entraîne un message « Fichier ressource recréé » mais n'a aucune conséquence sur le fonctionnement de l'application, sauf si le RES était dans un cas exceptionnel un fichier contenant réellement quelque chose d'intéressant. Dans ce cas, il fallait garder le fichier.

VI) Si on résume == = === En conclusion, un fichier Zip pour DelphiFr.com doit se résumer à quelques fichiers:

1) le fichier projet DPR

2) les fichiers PAS

3) les fenêtres DFM

4) à un fichier explicatif: catégorie, ReadMe, info de droit d'auteur...

5) les fichiers RES [si c'est vraiment utile *

Attention: Ne pas se tromper dans l'élimination des fichiers. Il serait stupide de supprimer un fichier PAS. === === Le but essentiel de ce petit tutorial est de pousser les membres à envoyer des fichiers Zip épurés de tout fichier <gras>vraiment inutile... tout en gardant le bonheur de programmer sans erreur ! Je ferais mes modifications en temps utile afin d'être cohérent vis-à-vis de mes écrits.

Tanguy ALTERT,
http://altert.family.free.fr/

Adresse d'origine

Ce document intitulé « [delphi] optimiser le contenu de vos zips » issu de CodeS SourceS (codes-sources.commentcamarche.net) est mis à disposition sous les termes de la licence Creative Commons. Vous pouvez copier, modifier des copies de cette page, dans les conditions fixées par la licence, tant que cette note apparaît clairement.
[delphi] installer des composants
Base de registre windows: lecture et écriture
Rejoignez-nous