Discussion :

[Invité]

Bonjour,

System.IOUtils.TPath.GetLibraryPath donne le répertoire de compilation. Par exemple suivant le mode compilation choisi :

Y a-t-il un moyen (à partir du mode Debug) d'obtenir (d'introduire) directement le répertoire des sources du programme en cours (donc ici E:\DelphiProjects\VCL\SQLiteTest02\) ? Je suppose que non, compte tenu de la mécanique de compilation de Delphi... mais on ne sait jamais.
Merci.

[Invité]

On pourrait éventuellement le récupérer par un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ShowMessage(System.SysUtils.GetEnvironmentVariable('PROJECTDIR'));

en créant une variable utilisateur attachée à la compilation Win32-Debug... Le problème, c'est que je ne veux pas être obligé à chaque fois de préciser le chemin en dur du projet. Il faudrait donc récupérer et charger la variable dynamiquement (une sorte de %cd%) et l'introduire avant la compilation... puisqu'avec Delphi on ne peut utiliser -à priori- que des variables statiques. (Donc ici un %CD% renverra un '%CD%'. De toute façon, s'il était interprété dynamiquement, il serait inutile ici puisqu'il renverrait probablement le path du compilateur... enfin c'est à voir).

Et on fait cela comment (i.e. précharger la variable avant la compilation) ? Pour être plus exact, on interface cela comment (et où dans l'IDE) avec le compilateur ? C'est un problème que j'ai rencontré en Qt et qui m'a donné une fois réglé, une énorme souplesse de "fabrication" de mes exécutables dont je ne dispose pas en Delphi... pour l'instant.

[Roland Chastain]

Bonjour ! J'ai testé (avec XE2) l'astuce qui est donnée dans cette page :

Explore your project directory

[Andnotor]

System.IOUtils.TPath.GetLibraryPath donne le répertoire de compilation

D'après l'aide, simplement le répertoire de l'exe (équivalent à ExtractFilePath(Application.Exename)).

Même si je ne comprends pas vraiment la finalité, tu peux le faire en générant automatiquement un fichier.pas en pré-compilation (Options, événements de construction):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(echo unit ProjectDir;&echo interface&echo const Dir = '$(PROJECTDIR)';&echo implementation&echo begin end.) > $(PROJECTDIR)\ProjectDir.pas

Tu n'as plus ensuite qu'à ajouter le fichier ProjectDir.pas dans les uses (même s'il n'existe pas encore)

[Invité]

Bonjour,

D'après
l'aide, simplement le répertoire de l'exe (équivalent à ExtractFilePath(Application.Exename)).

Je ne crois pas. Mes sources sont dans /ProjectPath
et mes exécutables dans /ProjectPath/win32/debug, /ProjectPath/win32/release, /ProjectPath/win64/debug, /ProjectPath/win64/release... et c'est ce sur quoi pointe ExtractFilePath(Application.Exename).

La finalité en mode debug est d'accéder à des utilitaires, des librairies voire même des portions de codes additionnelles (des includes) stockées dans le même répertoire que les sources... et qui ne sont évidemment pas intégrées dans les releases. Un poistionnement équivalent dans tous les projets me permet d'autre part de "soulager" le paramétrage de mon Mercurial. J'ai procédé comme cela en Qt et j'en suis ravi. Mais compte-tenu de la structure, je peux redescendre de 2 sous-répertoires à partir de PathLibray. Je voulais simplement par curiosité me rendre compte des capacités de chaque environnement.

De toute façon, je n'ai pas encore touché à mac Os X... mais je crains le pire avec ces méthodes qui pourtant découlent de mes habitudes de programmation multi-OS (Qt et Lazarus).

[Andnotor]

Le répertoire de l'exe, pas des sources.

Le répertoire de sortie par défaut est réglé sur .\$(Platform)\$(Config). Puisque ce sont des chemins relatifs et si ton projet source est sous quelquechose\ProjectPath, l'exe se retrouvera sous quelquechose\ProjectPath\Win32\Debug pour une application Windows 32 bits en mode debug

Je n'ai que XE3 et System.IOUtils.TPath.GetLibraryPath n'existe pas encore mais ce n'est certainement qu'une encapsulation de GetModuleName ou GetModuleFileName.

[Andnotor]

La finalité en mode debug est d'accéder à des utilitaires, des librairies voire même des portions de codes additionnelles (des includes) stockées dans le même répertoire que les sources... et qui ne sont évidemment pas intégrées dans les releases

dans ces conditions, ce serait simplement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
{$IFDEF Debug}
  {$I MonFichier.inc}
{$ENDIF}

Le fichier inc devrait même être défini dans tous les cas mais conditionné à l'intérieur ainsi la release n'aurait besoin d'aucune modification:

Source debug ou release

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

{$I MonFichier.inc}

et dans inc:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
procedure Proc;
begin
{$IFDEF Debug}
  // Code exécuté en debug uniquement
{$ENDIF}
end;

Le compilateur se chargeant d'optimiser tout cela

[Invité]

Oui pour les includes basiques mais les miens font souvent appel à des drivers ou des dlls externes... Mais en tous cas, le problème reste entier pour les librairies.

Ce qui m'intéresse c'est d'obtenir l'adresse du répertoire qui contient project.dproj dans lequel figurent mes sous-répertoires perso "utilitaires". Donc par exemple
\141103\monprojet.dpr
\141103\monprojet.dproj
\141103\dlls\
\141103\driver\

Soyons plus clair. J'ai souvent 3 types de bases de données dans chacun de mes projets : pgSQL, mariaDB et désormais SQLite3. Je travaille sous 5 OS différents : Win32, Win64, Linux32, Linux64 et Mac OS X. Pour le dernier c'est plus épisodique. Toutes les librairies clientes sont placées dans le répertoire Drivers des sources puis ensuite classées dans des sous-répertoires Win32, Win64, Lin32, Lin64...
En debug, le programme répertorie les "bonnes" dll du répertoire du projet en piochant dans les sources et les place aux bons endroits du répertoire de sortie. Evidemment, je ne peux pas le faire en release. J'ai commencé à utiliser cette méthode avec Lazarus. Elle est devenue nécessaire avec Qt : sa compilation dynamique impose une ribambelle de librairies propriétaires... Et pire, j'ai dû différencier les Win32 puisque le compilateur compatible avec XP est celui de VS2008 (et pas les suivants)... ou MingGw32 alors qu'évidemment pour les autres versions de Windows (Vista, Seven), on utilise des compilateurs plus récents.

Quand même pour info, en pgSQL, il faut fournir entre 5 et 8 ou 9 dll suivant la version de pg...

J'ai entièrement automatisé cette approche en Qt 5 et évidemment la structure de mes programmes et de ses dlls est la même en Qt, Lazarus et j'espère Delphi. Avant Qt, en Lazarus, j'appelais un programme externe fait en Lazarus et compilé dans chaque OS pour assurer la ventilation, les répertoires étant précisés en dur... La révolution pour moi cela a été QMake. La seule chose que je n'ai pas réussi à faire en Qt est de placer les sources sur un serveur... les stations de développement travaillant dans leurs OS respectifs à partir des sources du serveur, les exécutables évidemment étant générés sur les stations de développement. Le problème était visiblement un problème de droits : les serveurs sont des Windows serveur 2012. Je n'ai jamais pu utiliser cette méthode avec un poste de développement sous Nux et leurs client samba. Et je ne dispose pas de serveur Nis. J'aurais bien voulu essayer. Une telle configuration fonctionnelle serait vraiment intéressante .

[Roland Chastain]

Pardon si jamais je suis hors-sujet mais j'ai trouvé encore ceci qui me paraît répondre au moins partiellement au problème :

Outil qui affiche le chemin du projet actuel