Si "chemin de bibliothèque" doit-il indiquer les fichiers source des packages? Delphi 7 Documentation dit oui. Mais d'autres personnes disent non: "Le chemin" La "bibliothèque" devrait conduire à des fichiers compilés (.dcp, .dcu) et (si nécessaire) des fichiers de ressources (.RES, .DFM) uniquement ".
mise à jour:
La chose est que si vous n'ajoutez pas le chemin d'accès à vos packages dans le "chemin de la bibliothèque", chaque fois que vous créez un nouveau projet DPR, vous devez collecter manuellement le chemin d'accès à vos packages (nombreux) et entrez-les dans le projet. Option "Parcourir" Boîte, sinon vous obtiendrez "fichier xxx.dcu introuvable". Cela ne sonne pas ça agréable. Pendant des années, j'avais l'habitude d'ajouter tous mes chemins dans la bibliothèque et je n'ai jamais eu à ajouter manuellement les chemins à chaque fois que j'ai créé un nouveau projet.
Delphi 7 est un tel gâchis lors de la définition des chemins et une documentation officielle est 0. :(
mise à jour:
J'ai fait le changement. Ça marche, mais il n'est même pas parfaitement parfait (ou au moins élégant): Comment supprimer des ressources en double (res, DFM) tout en utilisant Delphi avec des chemins de bibliothèque non spécifiques?
6 Réponses :
Je dis non, car il est plus rapide de compiler l'application car les DCU sont déjà compilés.
La chose est que si vous n'ajoutez pas le chemin d'accès à vos packages dans le "chemin de la bibliothèque", chaque fois que vous créez un nouveau projet DPR, vous devez collecter manuellement le chemin d'accès à vos packages (nombreux) et entrez-les dans le projet. Option "Parcourir" Boîte, sinon vous obtiendrez "fichier xxx.dcu introuvable". Cela ne sonne pas ça agréable.
Eh bien, cela dépend - s'ils sont des forfaits à utiliser dans tous les projets, par exemple. Composants tiers, vous pouvez ajouter le chemin DCU aux paramètres de la bibliothèque globale. Sinon, si c'est un package utilisé uniquement dans certains projets, vous les ajouteriez individuellement à chaque projet.
Je suggère d'utiliser le chemin de la bibliothèque «global» uniquement sur vos bibliothèques «globales». Si .DCU sont trouvés avant .pas, ils seront utilisés sans recompiler le code source. Sans que vous modifiez souvent votre code source de bibliothèque, je l'éviterais et je ne le polluerais pas. La DCU spécifique à l'application IMHO ne doit pas être placée dans la trajectoire de la bibliothèque "globale". Vous pouvez facilement utiliser le "répertoire de sortie de l'unité" pour stocker DCU dans un répertoire commun par application
"Si .dcu trouve-t-il avant .pas" - Comment faire ça? Vous voulez dire le DCU de la DPR ou le DCUS de l'emballage (s)?
AFAIK Lorsque Delphi cherche une unité s'il trouve un fichier .DCU approprié avant un .pas, il l'utilisera (sauf si vous forcez une construction). Pour obtenir, il suffit d'avoir le chemin .DCu avant le chemin .pas (ou pour éviter le chemin .pas entièrement). C'est l'une des raisons de garder .PAS et .DCu dans différents dossiers, en particulier pour les bibliothèques, pour éviter une construction pour compiler des bibliothèques. Pour les packages, cela dépend de la façon dont vous les utilisez. Si vous utilisez des packages d'exécution, la liaison utilisera des fichiers .DCP, pas .DCu. Si vous utilisez vos paquets, d'ajouter des composants à l'IDE, puis de lier statiquement, vous aurez besoin de packages .DCU
Chaque projet doit avoir ses propres chemins de sortie . Si vous faites cela, alors lorsque vous pointez votre chemin de la bibliothèque sur les fichiers source, les fichiers binaires seront dans un dossier spécifique au projet et peuvent donc Oh, et Aussi, J'utilise des chemins relatifs dans tous mes projets. Je sais que certaines personnes ont souffert de cela, mais je n'ai jamais rencontré un problème. Peut-être parce que je n'ouvre jamais de fichiers en double-cliquant sur l'Explorateur Windows, mais toujours à partir de l'IDE ou éventuellement par glisser-déposer de l'explorateur pour afficher une version (version précédente de) sans faire partie d'un projet. Les chemins relatifs rendent les charges et les charges plus faciles à effectuer des copies d'un projet, ont un nombre quelconque d'espaces de travail (perforce) et de passer entre eux sans avoir à "fixer" les chemins de la DPR.
Tout ce qui précède sont des pratiques que j'ai ramassées avec de nombreux projets différents, qui devaient régulièrement changer entre versions de notre propre code, ce qui implique souvent de passer aussi bien entre les versions de la bibliothèque.
"Je n'ai même pas besoin de ré-compiler les packages de composants". Eh bien, dangereux, si votre changement d'impact sur le temps de conception jusqu'à ce que vous recompiliez les paquets, ils utilisent toujours un code ancien. Votre façon de travailler avec DFM nécessite beaucoup de soins. Trop beaucoup, Imho :)
@IDSANDON: En réalité, non, parce que je ne repose pas sur le comportement du temps de conception. Je ne me soucie pas beaucoup de ce qu'un contrôle semble au moment de la conception. Il est mis en place et personnalisé en code. Le DFM est principalement utilisé à des fins de présentation et à connaître des événements (si nous sommes trop paresseux pour le faire en code). Et non ma façon de travailler avec DFMS ne nécessite pas beaucoup de soins. Je ne vérifie pas le DFM, soit le revenir immédiatement. De plus, c'est mon / notre pratique standard d'examiner Toutes les modifications avant de les soumettre à la SVC, de sorte que tout changement par inadvertance sur des fichiers enregistrés (DFM, PAS, INC, DPR) ne glisse pas.
«Je ne me soucie pas beaucoup de ce qu'un contrôle ressemble au temps de conception» - je pense que vos formulaires ne sont pas assez complexes. S'ils sont, alors je ne vois pas le point d'utiliser Delphi. Il défait son but (rad-sons familiers?). En outre, j'ai perdu des fichiers et des projets à ouvrir / travailler avec. Ne pas pouvoir utiliser des actions Windows standard (telles que double clic) Just pour utiliser (les pistes relatives dangereuses) ..... trop pour un programmateur paresseux comme moi.
@Altar: Ils sont complexes complexes au moment de l'exécution. Juste pas au moment de la conception. Nous réduisons la complexité en utilisant des formes séparées et beaucoup de cadres qui utilisent à son tour d'autres images, etc.
@Altar: De plus, si vous pensez que la seule raison d'utiliser Delphi sont ses caractéristiques de rad et son développement de formulaire GRAG-N-DROP, je suppose que vous n'avez pas encore construit d'applications de serveur client complexes réelles où le client UI est important mais une partie relativement petite de toute la suite d'applications.
@Altar: Bien, je suis sûr que vous savez mieux que ce que je fais ce qui est utile pour moi ...;)
@Marjan et @altar: me semble que vous parlez de choses différentes. Marjan utilise probablement un motif d'affichage à l'interface, qui est décomposé à l'aide de cadres - de cette façon, elle peut manifester son interface temporelle de conception très «morte» et tout fil de code - même avec du code pré-automatisé. C'est peut-être pourquoi elle n'utilise pas beaucoup de formulaire de formulaire. Delphi est beaucoup plus qu'un beau designer ;-)
@Fabricio: Merci, oui, même si nous n'utilisons pas de modèle de conception spécifique tel que MVC, MVP ou MGM, c'est essentiellement à quoi il se résume. Et oui, Delphi est beaucoup, beaucoup plus qu'un beau designer (UI). :)
La technique que je décris ci-dessous fonctionne bien pour nous car, pour la version de Delphi que nous utilisons, tous les projets utilisent la même version des bibliothèques.
Par exemple, nous avons une succursale construite (et toujours activement développée) à l'aide de DelphI 6. Notre coffre a été migrée vers Delphi 2009 il y a plus d'un an, puis a migré vers 2010 il y a quelques mois et sera bientôt migré à Delphi Xe. Mais tous les projets dans le coffre utiliseront la même version de Delphi et la même version de nos bibliothèques.
Les fournisseurs de composants tiers Vous permettent d'installer la source à un emplacement partagé, puis utilisez différents dossiers de sortie pour le code compilé. D'autre part, vous préférez installer une copie séparée de chaque bibliothèque tiers pour chaque version de Delphi installé. Si j'installe une "version 5.4" mise à jour de l'une de mes bibliothèques de composants préférées, je ne souhaite peut-être pas que l'installation unique s'applique à chaque version de Delphi que j'utilise. Donc, chaque bibliothèque de composants est installée séparément pour chaque version de Delphi installé. (Il s'agit d'une douleur lorsque la bibliothèque utilise un programme d'installation Windows "typique" qui ne veut pas installer le même produit plusieurs fois.)
Après avoir dit tout cela, notre parcelle de bibliothèque globale dans les outils | Options pointe vers les dossiers de sortie de toutes les bibliothèques tierces. De cette façon, chaque nouveau projet est prêt à aller sans travail supplémentaire et à compiler tout projet ne recompilant pas le code de bibliothèque tiers standard qui ne change pas en tant que changements de projet.
sur l'instance rare, nous avons besoin d'un correctif (remplacement de code source) dans une bibliothèque tiers, ceux qui entrent dans un dossier séparé et sont compilés à chaque fois que le projet est compilé. Une fois que la tierce partie libère une mise à jour avec le correctif incluse, nous supprimons notre copie du patch.
Nous utilisons des bibliothèques tierces qui contiennent beaucoup de code source, telles que ReportBuilder, les composants de la RATIAD, les produits TROUBOPOWER, etc. Je ne vois aucune raison de recompiler tout ce code que je "construit" mon projet. < / p>
L'OP dit dans un commentaire:
La chose est que si vous n'ajoutez pas le chemin d'accès à vos packages dans le "Chemin de la bibliothèque", chaque fois que vous créez un nouveau projet DPR, vous devez collecter manuellement le chemin d'accès à vos packages (nombreux) et entrez-leur. Dans la case "Parcourir" du projet, sinon vous obtiendrez "fichier xxx.dcu introuvable"
Pas vraiment. Vous devez créer une option de projet par défaut. Pour ce faire, chargez Delphi (je parle de D2010 ici, mais la même fonctionnalité est disponible dans, au moins, D7) et assurez-vous qu'il n'y a pas de projet chargé dans l'IDE.
Après cela, ouvrez un fichier (n'importe quel fichier) et accédez à Project / Par défaut Options / Delphi (ou C ++ Builder, vous aurez le choix de la personnalité). Cela ouvrira un écran d'options de projet de base. Configurez-le jusqu'à ce que vous soyez heureux et appuyez sur OK.
Fabriquez un nouveau projet avec une application Fichier / New / VCL Formulaires et consultez vos paramètres par défaut appliqués.
Edit: Depuis XE2, le projet par défaut a été substitué par le Option ensembles .
Aide Liens: Voir http://docwiki.embarcadero.com/RADStudio/en/IDE_Changes_for_XE2#Default_Checkbox_Removed_from_Project_Options_Pages http://docwiki.embarcadero.com/radstudio/en/Option_sets_-
_Créer, _appliquer, _editing, _and_dropeting - Voir plus à: http://codeverge.com/embarcadero.delphi.ide/project-options-default-xe2/1058015#sthash.oovbcggs.dpuf
Bien que les réponses fournies ici soient définitivement bonnes et correctes (tout le monde reçoit un vote), après avoir expérimenté un peu, j'ai décidé de garder mon précédent (Kiss) configuré. Cela a fonctionné depuis des années et cela fonctionnera pour beaucoup d'autres. Je sais, il négocie la vitesse (recompilation du code source) pour la stabilité, mais il conserve les "chemins, bibliothèques, sources, dossiers de navigation et de sortie" Madness à la baie. Je n'ai tout simplement pas à vous soucier des paramètres des chemins (sauf la première fois lorsque j'installe Delphi, mais cela peut être automatisé) ou pour quitter le projet DPR Delphi actuel et charger une bibliothèque DPK et la compiler à chaque fois que j'applique à cela. < / p>
Si vos packages sont «globaux» les mettent dans le chemin de la bibliothèque. Si vous pourrez mettre la source .pas à cela dépend de vous et dépend de la façon dont vous gérez et utilisez ces packages, si vous les éditez et les compilez séparément ou non. N'oubliez pas que si vous n'utilisez pas de packages de temps d'exécution, les applications compilées ne prennent pas soin de si un DCU provient d'un package ou non - la lieur ajoutera simplement le code nécessaire à l'exécutable et le compilateur compilera. Pas il doit, si cela peut le trouver.