Re: GprBuild et GNATColl.Memory

On 4/5/21 13:49, Stéphane Rivière via Ada-france wrote:
> Bonjour à toutes et tous,
> 
> 
> 
> * Contexte
> 
> Pour un projet en libre GPL v3 (gestion de cluster de serveurs avec HA -
> en multi site et réseau privé, ça nous a déjà bien servi avec l'incendie
> de SBG2 d'OVH d'ailleurs), on a monté une petite biblio généraliste pour
> des progs en mode texte.
> 
> Comme c'est aussi pour des services qui vont tourner 365/24, j'ai voulu
> utiliser le package gnatcoll.memory pour observer la conso des objets
> créés :
> 
> - créer dans le chemin des sources un s-memory.adb selon un modèle
> - rajouter with "gnatcoll" en haut du projet GprBuild
> - utiliser avec un with gnatcoll.memory
> - appeler les quelques fonctions du package pour 'mesurer'.
> 
> C'est simple à utiliser et cerise sur le gâteau : /on peut laisser la
> manip dans la version PROD/ car c'est activable par un Boolean quand on
> le souhaite sans consommation de ressource quand c'est inactif.
> 
> C'est donc un bon complément de Valgrind pour partir à la recherche des
> octets perdus - quand on ne dispose par d'un full GNAT Pro...
> 
> Et ces mesures peuvent être activées au moment d'une exception non
> récupérable et écrite dans un fichier d'erreur, ce que fait, entre
> autres, cette petite biblio.
> 
> 
> 
> * Problème
> 
> J'ai pas tout compris sur le build.
> 
> D'après la doc GNATColl AdaCore, il suffit de :
> 
> - poser un with "gnatcoll" en haut du projet GprBuild,
> - créer dans le chemin des sources un s-memory.adb selon un modèle
> 
> Sauf que, sur une install fraîche de GNAT CE 2020, après un build,
> toutes les valeurs ci-dessus sont à 0. Dans le répertoire de build,
> s-memory.o n'est pas créé et on en déduit que le with "gnatcoll" a
> incité GPRBuild à utiliser la lib précompilée...
> 
> ... donc le s-memory.adb n'a même pas été considéré puisque toutes les
> dépendances étaient satisfaites avec la lib GNATColl.
> 
> J'ai donc
> 
> - Viré le  with "gnatcoll"  du projet;
> 
> - Ajouté les sources de GNATColl
> "/home/sr/opt/gnat-2020/include/gnatcoll" dans les chemins de sources
> 
> - Ajouté le C avec for Languages use ("Ada", "C"); (y'a du C dans GNATColl)
> 
> Et là les dépendances de GNATColl sont compilées (voir ci-dessous les
> fichiers gnatcoll concernés, plus de C que de Ada en fait), avec le
> s-memory.adb personnalisé et je retrouve mes stats de mémoire...
> 
> --------------------------------------------------
> gprbuild -d -P/home/sr/Seafile/Sowebio/informatique/dev/ada/prj/v20a/v20.gpr
> Compile
>    [Ada]          test.adb
>    [C]            link_max.c
>    [C]            set_std_prefix.c
>    [C]            executable_path.c
>    [C]            objlist_file.c
>    [C]            update_path.c
>    [C]            run_path_option.c
>    [C]            gnatcoll_support.c
>    [C]            separate_run_path_option.c
>    [C]            getRSS.c
>    [C]            terminals.c
>    [Ada]          gnatcoll.ads
>    [Ada]          gnatcoll-memory.adb
>    [Ada]          v20.adb
>    [Ada]          v20-cfg.adb
>    [Ada]          v20-log.adb
>    [Ada]          v20-prg.adb
>    [Ada]          v20-tio.adb
>    [Ada]          v20-vst.adb
>    [Ada]          s-memory.adb
> Bind
>    [gprbind]      test.bexch
>    [Ada]          test.ali
> Link
>    [archive]      libv20.a
>    [index]        libv20.a
>    [link]         test.adb
> [2021-03-31 20:01:53] process terminated successfully, elapsed time: 02.24s
> --------------------------------------------------
> 
> 
> Ce qui est gênant en l'état c'est que j'ai une chaîne en dur dans mon
> projet dépendante de mon organisation de chemins... ce n'est pas propre
> je trouve...
> 
>    for Source_Dirs use
> ("src-tests","src/**","/home/sr/opt/gnat-2020/include/gnatcoll");
> 
> 
> Je souhaiterais supprimer cette chaîne pour quelque chose de plus
> "générique" (genre tous les include de l'install courante de GNAT)
> 
> Comme fait actuellement le  with "gnatcoll"  qui va chercher ses
> références (si j'ai bien compris) dans /home/sr/opt/gnat-2020/share/gpr
> (un répertoire qui contient tous les gpr des libs installées)
> 
> 
> 
> - Était-ce la bonne manière de faire (j'en doute, vu le niveau
> d'abstraction de GprBuild) ?
> 
> - Le with "gnatcoll"; ne fait pas prendre en compte la recompilation de
> GNATColl via le .gpr de GNATColl ? J'ai oublié quoi pour le forcer à
> recompiler ? Pour lui indiquer que je souhaite recompiler s-memory.adb
> et donc toute la chaîne de dépendances associées ?
> 
> 
> Le projet est là : https://stef.genesix.org/pub/ada/v20-0.3.zip avec le
> .gpr, la doc, faut juste ajuster le chemin des sources
> "/home/sr/opt/gnat-2020/include/gnatcoll"...
> 
> 
> 
> Idées bienvenues...
> 
> Merci d'avance :)
> 
> 
> 
> 
> PS Actuellement, mes chemins GNAT sont ainsi : gnat ls -v
> 
> --------------------------------------------------
> GNATLS Community 2020 (20200429-93)
> Copyright (C) 1997-2020, Free Software Foundation, Inc.
> 
> Source Search Path:
>    <Current_Directory>
> 
> /home/sr/opt/gnat-2020/lib/gcc/x86_64-pc-linux-gnu/9.3.1/rts-native/adainclude
> 
> 
> Object Search Path:
>    <Current_Directory>
> 
> /home/sr/opt/gnat-2020/lib/gcc/x86_64-pc-linux-gnu/9.3.1/rts-native/adalib
> 
> 
> Project Search Path:
>    <Current_Directory>
>    /home/sr/opt/gnat-2020/lib
>    /home/sr/opt/gnat-2020/x86_64-pc-linux-gnu/lib/gnat
>    /home/sr/opt/gnat-2020/x86_64-pc-linux-gnu/share/gpr
>    /home/sr/opt/gnat-2020/share/gpr
>    /home/sr/opt/gnat-2020/lib/gnat
> --------------------------------------------------
> 
> 
> 
> 


Salut,

le composant gnatcoll est considéré comme externe à ton projet, il n'est pas recompilable,
cf. l'attribut Externally_Built du composant gnatcoll (share/gpr/gnatcoll.gpr) qui est à True.

De notre côté, on gère ce genre de besoin par le déploiement de runtime Ada personnalisées.
Ici, il s'agirait de packager une runtime Ada qui contienne votre version personnalisée de s-memory.adb
	- tout les autres composants GPR du projet ayant une dépendance sur s-memory.adb devront aussi être repackagé pour prendre en compte cette nouvelle runtime. Cela est assez lourd à
gérer.
	- au build l'option '--RTS=custom' devra être utilisé (le runtime étant ici /lib/gcc/x86_64-pc-linux-gnu/9.3.1/rts-custom)

Mais dans certain cas, créer un nouveau composant (i.e gnatcoll_custom avec le gestion personnalisé du s-memory.adb au build) peut convenir,
cela dépend aussi;
	- du mode du bind de l'application principal et des autres composants GPR avec la rutime Ada ('-shared' ou '-static')
	- du mode library_kind '-static' ou '-relocatable' des composants GPR
	- de l'acceptabilité ou pas que l'application utilise des implémentations runtime différentes

All the best !


-- 
David SAUVAGE

Software Agile Architect, Director
AdaLabs Ltd - Mauritius
https://adalabs.com
+230 542 818 32
BRN C10097052
_______________________________________________
Ada-france mailing list
[email protected]
https://mail.ada-france.org/cgi-bin/mailman/listinfo/ada-france