Re: pragma Debug / projet GPR

Le 5 juil. 2021 à 19:39, Thomas De Contes via Ada-france a écrit :

> Pour améliorer le débogage, j'ai ajouté un "pragma Debug" à la procédure Debug


> 1
> Est ce que ce "pragma Debug" est la meilleure chose à faire ?

Je suppose que, quand c'est approprié, la réponse est "oui".


À propos :
https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gnat_ugn/Debugging---A-Special-Case.html
"Note that a pragma is not a statement, so in contexts where a statement sequence is required, you can’t just write a pragma on its own. You have to add a null statement."

J'ai constaté le contraire :
http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/src/tki/mcc_tki/mcc-msg.adb?view=markup&pathrev=230
(l 81 - ça marche)

Où est l'erreur ?


Pendant que j'y suis, à propos de la doc de GNAT :
Je vois que ça parle encore de GNU make :
https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gnat_ugn/Using-the-GNU-make-Utility.html

Vu le contenu, je suppose que ce chapitre a très majoritairement été rendu obsolète par GPRbuild.
Dans ce cas, je recommande un nettoyage.

Si je me trompe et qu'il y a encore des gens à qui c'est utile,
je suggère de completer "4.7.2 Automatically Creating a List of Directories" avec ma fonction `function-nested_DIRS` l 182 :
http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/bin/makefile-Main.mk?view=markup&pathrev=230
(Ce qui est délicat, c'est de bien comprendre comment marche la fonction `call` pour un usage avec boucle récursive, parce qu'elle est très mal documentée.)




Pour les questions suivantes, j'ai trouvé une solution partielle :


En détail :
http://svn.savannah.gnu.org/viewvc/rapid?view=revision&revision=231
Et si vous voulez tester, il faut exécuter `make develop` et `make debug` alternativement.


En resumé :

   package Naming is
      case Build_Mode is
         when "Debug" =>
            for Implementation ("mcc.Globals") use "mcc-globals--verbose.adb";
         when others =>
            null;
      end case;
   end Naming;

$ cat mcc-globals--verbose.adb
package body mcc.Globals is
begin
   Verbose := True;
end mcc.Globals;

   procedure Debug (Msg : String) is
   begin
      if mcc.Globals.Verbose then
         Put_Line (Msg);
      end if;
   end Debug;


> 2
> Je voudrais recompiler "mcc-msg.adb" à chaque fois que je change de mode (mais pas tout, seulement ce fichier).

Ça ne recompile pas tout, mais tout ce qui dépend de "mcc-globals.ads", quand même.

C'est très curieux :
Ces paquetages (par exemple "mcc-msg.adb") dépendent de "mcc-globals.ads" mais pas de "mcc-globals.adb" (j'ai bien vérifié que même dans ces circonstances, si je modifie "mcc-globals.adb" ça ne recompile pas les autres paquetages).

Alors je devine que ces recompilations forcées permettent de garantir la bonne cohérence des exécutables à la fin, et je suis bien d'accord qu'il vaut mieux en faire un peu trop qu'un peu pas assez !
Mais je me demande si c'est bien nécessaire de recompiler /complètement/ tous les paquetages qui dépendent de "mcc-globals.ads".
Est ce qu'à l'avenir, ça pourrais être optimisé en modifiant le .ali pour le brancher sur le bon .o suivant, mais sans modifier le .o qui en principe n'a pas besoin de changer (d'après mes connaissances, qui sont très minces dans ce domaine - j'ai remarqué que là, il a changé de contenu) ?

Si je met l'initialisation de Verbose dans "mcc-globals--verbose.ads" au lieu de "mcc-globals--verbose.adb", je crois que la recompilation /complète/ de tous les paquetages qui en dépendent est obligatoire, puisque le compilateur n'a pas les moyens de savoir quelle partie du code a réellement changé.

Est ce que je devrais faire ça ("mcc-globals--verbose.ads") pour simplifier mon code, puisque ça recompilera toujours la même chose de toutes façon ?
Ou est ce qu'il vaut mieux que je laisse comme ça ("mcc-globals--verbose.adb"), pour profiter automatiquement d'une optimisation future ?


> 3
> Est il possible de ne pas re-fabriquer tous les exécutables quand on change de mode, s'il n'y a que "mcc-msg.adb" qui est re-compilé, et de ne le faire que si du code a changé ?

J'ai vu l'option -c, utile quand on est en train de corriger les styles et qu'on ne veut pas tester les exécutables.

Mais dans le cas où on a modifié du code qui n'impacte pas tous les exécutables, je trouverais pratique d'avoir une option pour re-fabriquer (relier ?) seulement ceux qui dépendent du code modifié, pas ceux qui dépendent seulement du changement de mode.
(Et dans ce cas là, je veux évidemment que ceux qui sont reliés le soient avec la bonne version de `mcc.Globals`.)


> 4
> Je voudrais bénéficier des assertions en mode Develop, mais les messages de débogage commencent déjà à m'agacer, j'aimerais ne les avoir qu'en mode Debug.

Cette partie là par contre, ça marche parfaitement bien (puisque je me suis détaché du "-gnata").




> 5

> Est il possible d'avoir les avantages de "-gnatv" sans ses inconvénients ?
> Ses inconvénients, c'est tout ce que ça affiche en supplément (par rapport à pas d'option) quand il n'y a rien à signaler.

Je suppose que la réponse est "non".


-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

_______________________________________________
Ada-france mailing list
[email protected]
https://mail.ada-france.org/cgi-bin/mailman/listinfo/ada-france