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

[Invité]

Bonjour Roland,

Oui excusez-moi je n'ai pas répondu à votre première proposition. J'ai regardé. Ce qui est décrit fonctionne. Mais je ne trouve pas le lien avec l'intégration du "répertoire" dans le code.

La deuxième proposition, je l'ai lue justement en me documentant sur votre première proposition.

Code :

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

1
2
3
4
5
6
7
8
9
10
uses
  Classes, Dialogs; uses
  Dialogs,
 
begin
  if ParamCount > 0 then
    ShowMessage (ParamStr (1))
  else
    ShowMessage ('No project active');
end.

Comment cela passe un uses de uses ? En enlevant le deuxième use OK... Mais, si j'ai bien compris, cela revient au final grosso-modo à ce que je faisais en Lazarus... A un moment, il faut passer le répertoire sources en dur.

Donc actuellement, j'ai 3 approches possibles

• La plus satisfaisante serait d'intégrer une variable dynamique... puisque la variable GetSourcePath n'existe pas. Je ne sais pas faire et donc je sollicite le forum.
• La deuxième est de créer une variable statique... Il faut la changer à chaque fois que l'on change le répertoire du projet... mais cela fonctionne et c'est très simple. Comme il est tout aussi simple d'oublier de changer la variable.
• La troisième est de conserver systématiquement la même structure Win32/debug... Win64/debug... Il est donc facile de récupérer 2 répertoires en-dessous pour obtenir le répertoire racine des sources... Elle me plait bien cette structure. Elle ressemble à celle que j'utilise (utilisais) en Qt... Faute de mieux, je la retiendrai.

Mais, quelque soit la solution retenue je ne sais pas si cette approche sera transposable à Mac OS X. La cross-compilation ne m'a jamais inspiré et reste pour moi un sujet assez mystérieux. Je laisse la discussion dans l'état. Chaque solution de développement a ses avantages et ses inconvénients... Et franchement, ce n'est pas vraiment un problème.

[SergioMaster]

Mais, quelque soit la solution retenue je ne sais pas si cette approche sera transposable à Mac OS X. La cross-compilation ne m'a jamais inspiré et reste pour moi un sujet assez mystérieux. Je laisse la discussion dans l'état. Chaque solution de développement a ses avantages et ses inconvénients... Et franchement, ce n'est pas vraiment un problème.

de toute façon , sur mac , tu ne compiles pas (du moins avec delphi ) la compilation reste sous windows, les sources aussi et l'application compilée est envoyé au mac (à moins que je me trompe :koi) . Bon sauf si on chipote avec un windows en console virtuelle bien sûr n.b. je suis d'humeur chipoteuse aujourd'hui

[Invité]

Bonjour Serge,

Oui, oui, j'ai lu cela. Je n'ai pas répondu... Mon cas est partiellement défendable... si tu utilises le connecteur sur 2 bases différentes. Pour l'autre, je préfère une redondance qu'un oubli... qui pourrait être réglé simplement en ayant le courage d'aller lire la doc. Mais tu as raison.

Je reprends demain et je suis à la ramasse !

J'en parlais ce midi avec un Javaîen (dont je t'ai parlé récemment)... Je dis toujours qu'ils sont enfermés dans leur Machine Virtuelle et que les liens avec l'extérieur de la JVM sont compliqués et naturellement lents ... Alors qu'avec nos langages compilés, on est à l'air "libre". Le fait que le compilateur ne puisse pas "intégrer" dans la compilation le répertoire des sources l'a fait rigoler. Cela ne m'a pas fait rigoler en Qt... J'y ai perdu mon latin ! Et sans Qt je n'aurais même pas poser la question.

[Roland Chastain]

Pour le code de la deuxième proposition, moi j'ai fait plutôt comme ça (pour pouvoir facilement copier le chemin) :

Code :

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

1
2
3
4
procedure TForm1.FormCreate(Sender: TObject);
begin
  Edit1.Text := ParamStr(1);
end;

Mais effectivement ça ne répond exactement à votre demande.

Cependant, on pourrait imaginer un autre outil qui au lieu d'afficher le chemin à l'écran, irait l'écrire quelque part, dans un fichier de configuration ou même directement dans le fichier source.

[Invité]

Oui visiter le .dproj ? On peut le lire et l'ouvrir à partir du code du projet ? Je regarde.
Non.

Code :

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

1
2
3
4
 
nameDProj := 'SQLiteTest02.dproj';
AssignFile(F,nameDProj);
Reset(F);

Cela cherche le fichier SQLiteTest02.dproj dans le répertoire de l'exécutable (E:\DelphiProjects\VCL\SQLiteTest02\Win32\Debug) et non dans celui des sources (E:\DelphiProjects\VCL\SQLiteTest02). On en revient au même problème.

Pour lire ce fichier, il faudrait nameDProj := GetSourcePath + 'SQLiteTest02.dproj'; Mais si j'ai le SourcePath je n'ai pas besoin d'aller lire le fichier.dproj pour savoir où est le SourcePath Mais l'idée m'a effleurer. Un fichier du SourcePath aurait pu être référencé par une variable... Mais je n'en ai pas trouvé.

Bon on va laisser refroidir un peu... la solution 3 est pour l'instant la meilleure et on peut la modifier suivant l'arborescence retenue.

[skywaukers]

Bonjour,

je n'ai surement pas bien compris le problème, mais ceci devrait donner le résultat recherché :

Code :

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

AssignFile( F, ExtractFilePath( ParamStr(0)) + '..\..\MyLibrary\MyFile');

ou encore :

Code :

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

AssignFile( F, System.IOUtils.TPath.GetLibraryPath + '..\..\MyLibrary\Myfile');

@++
Dany

[Andnotor]

Mais pourquoi vouloir lire un fichier source alors qu'on a tout sous la main par le compilateur

Ce que tu veux faire est vraiment de la pré(post)-compilation. Si tu veux créer un répertoire et y copier un fichier:

Code :

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

1
2
mkdir "$(PROJECTDIR)\$(Platform)\$(Config)\DLL"
copy /Y "c:\sources\sourcedll.dll" "$(PROJECTDIR)\$(Platform)\$(Config)\DLL"

Tu peux aussi te faire une fois pour toute un batch qui testera la config, la plateforme, le SGBD et fera les copies en conséquence. Voilà par exemple un batch que j'utilise en post-compilation pour renommer un fichier.exe (64 bits) en fichier64.exe avant de signer le code. En 32 bits, il passe en plus par UPX pour y subir une compression avant signature. Un seul batch avec appel identique pour tous mes projets 32 et 64. En Delphi, il suffit de lancer la compilation et tout est automatique.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
rem Depuis Delphi post-compilation, appeler:
rem T:\Release_PostCompile.bat $(CONFIG) $(PLATFORM) $(OUTPUTDIR) $(OUTPUTNAME) $(OUTPUTEXT)
rem ----------------------------------------------------------------------------------------
 
@Echo off
if %2==Win32 goto :Win32
 
rem ----------------------------------------------------------------------------------------
:Win64
 
copy /Y "%3%4.*" "%3%464.*"
IF ERRORLEVEL 1 Exit /B 1
 
Del /F "%3%4.*"
IF ERRORLEVEL 1 Exit /B 1
 
"Z:\Code signing\CodeSigning.bat" "%3%464%5"
IF ERRORLEVEL 1 Exit /B 1
 
goto :eof
 
rem ----------------------------------------------------------------------------------------
:Win32
 
rem if %1==Release "C:\Progra~2\UPX\upx.exe" --best "%3%4%5"
rem IF ERRORLEVEL 1 Exit /B 1
 
"Z:\Code signing\CodeSigning.bat" "%3%4%5"
IF ERRORLEVEL 1 Exit /B 1

N'oublie pas non plus que tu peux avoir autant de configuration de construction que tu le souhaites, pas uniquement debug et release. Si tu veux en ajouter qui s'appellent MariaDB, SLQLite3, etc. et spécifiant des paramètres différents, libre à toi

[Invité]

Doucement, doucement...
J'appelle comment votre batch à partir de mon outil de compilation ? Je le précise où dans l'IDE ? Outil->Options ? Projet->Options ? Peut-être Evènements de construction...Pré-construction ?

[Andnotor]

Comme déjà expliqué ici

• Option du projet -> Evénement de construction
• choisir la cible (par exemple debug Windows 32)
• Evénement post-construction -> Commandes

[Invité]

En effet, cela fonctionne très bien. Merci beaucoup.

Après plusieurs essais, voici la procédure utilisée. L'ordre des choses est important.


Voici le CR :
Je décide de partager la string GetSourcePath qui contiendra l'adresse du répertoire source placée dans l'unité uGetSourcePath

1. Menu Projet >> Options >> Cible : Choisir sa cible (ex. Debug configuration - Toutes les plates-formes)

2. Toujours dans le même menu (Projet >>Option >> Evènements de construction >> Evènements post-construction >> Commandes >> Valeur de 'Toutes les configurations les plates-formes"
saisir le code

Code :

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

1
2
3
4
5
6
7

	

	
Code  :
	
Sélectionner tout -
	Visualiser dans une fenêtre à part
	
(echo unit uGetSourcePath;&echo interface&echo const GetSourcePath = '$(PROJECTDIR)';&echo implementation&echo end.) > $(PROJECTDIR)\uGetSourcePath.pas

3. Une petite vérification (lecture plus lisible)

4. Compilation pour créer la nouvelle unité)
5. C'est seulement à ce stade qu'on intègre la nouvelle unité dans les uses de la Form qui l'utilise.

J'ai changé le répertoire des sources. Je relance le programme après reconstruction :

[Barbibulle]

Comme déjà expliqué ici

• Option du projet -> Evénement de construction
• choisir la cible (par exemple debug Windows 32)
• Evénement post-construction -> Commandes

C'est clairement un problème qui ne peut être résolu que lors de la pré-compilation.

Il existe aussi l'outil de l'outil de déploiement. Qui sera plus adapté dès lors qu'on va vouloir compiler sous autre chose que du windows. (la commande DOS de copy ne fonctionnera pas pour un test sur MAC)

Toujours dans le menu Projet/Déploiement. On peut ajouter la copie de fichier dans le répertoire de destination selon la cible win32/64/release/debug etc.

Sinon il me semblait que les Gexperts permettait de récupérer un certain nombre de path liés au source en pré-compilation c'est peut être possible de récupérer une de ces macro pour affecter une constante dans le code ?

http://www.gexperts.org/tour/index.html?to_do_list.html