Herezh++

J'ai tenté hier soir de compiler Herezh. Je ne peux(veux?) pas le faire sous mac. L'OS est trop ancienne et je ne pourrai pas la mettre up-to-date (ordi ancien). A plus ou moins court terme, je n'aurai plus que du linux, c'est ma seule possibilité de faire quelque chose de pérenne.

Sur linux, j'ai essayé de compiler la branche master et la branche V7.028. A chaque fois, message d'erreur ou nécessité de supprimer des fichiers du .cbp car disponibles nulle part. Après de nombreux tests, je me suis dit qu'il valait mieux voir avec toi si tu peux m'aider. J'ai été un peu dans tous les sens, donc pas évident à synthétiser par mail.
Donc, j'essaye aujourd'hui de reposer les choses : mettre en place ce qu'il me semble être une arborescence correcte depuis la branche V7.028. Puis je te tiens au courant des pb rencontrés.

normalement tous les fichiers nécessaires sont dans l'arborescence de la version V 7.028 car c'est exactement ce que j'utilise sur ma version linux : le même fichier de paramètres, le même répertoire avec tous les fichiers récupérés via git sur le serveur d'Herezh.
Par contre il faut regarder les chemins ... pour Herezh et également pour gcc, les bibliothèques etc.
J'utilise apt-get et le gestionnaire de paquet synaptic. Avec ce dernier en recherchant une bibliothèque tu peux voir où elle est installée.

J'ai reconstruit mon arborescence avec récupération des sources 7.028 et des divers librairies "third party".

Avant toute chose, je n'ai pas récupéré la version 2.2.5 de muparser (demandé aux lignes "../../Herezh_source/MuParser/muparser-2.2.5_GR/". J'ai remplacé tous ces chemins par la version 2.3.4. Est-ce que ça posera problème ?

Je n'ai pas tenté une compilation. Je voudrais déjà faire le point sur :
1) les fichiers/repertoires manquants
2) les options en début de fichier (le bloc <Build> ... </Build>)
3) un fichier étrange (conflict!!)

1) fichiers/répertoires manquants :
source Herezh :
- repertoire Herezh_dev/comportement/loi_visco_plastiques
- repertoire Herezh_dev/G_Var_precompile/Normals
- repertoire Herezh_dev/NRC
- repertoire Herezh_dev/G_Var_precompile/en_debug_OSXunix

third party :
- fichier muparser-2.3.4/include/muParserStack.h
- fichier SparseLib++/1.7/src/iohb.cc (NB : il existe un fichier SparseLib++/1.7/src/iohb.c => Faut-il juste changer l'extension en .cc ???)

et également les 2 répertoires suivants :
- repertoire /home/rio/bin/Herezh/
- repertoire ../../Herezh_source/Herezh_develop/Herezh_dev
Mais ces deux-là, je peux juste les supprimer non ?

2) options du bloc <Build> ... </Build>
dans cette partie, je dois mettre mes propres chemins pour accueillir les exécutables/objets qui seront créés ?
partie "Debug" :
<Option output="bin/Debug/Herezh"
<Option object_output="obj/Debug/" />

partie "Release" :
<Option output="bin/Release/Herezh"

et également, je ne sais pas trop quoi mettre ici concernant "Debug" :
<Option working_dir="../tickets_herezh/191/Test_R_BPL1" />

3) fichier étrange :
il y a le fichier suivant dans les sources Herezh :
Herezh_dev/Enumeration/Enum_ddl (copy/ conflict on 2017-11-21).h

est-ce normal ? ou un fichier qui traine et qui devrait être supprimé de git ?

Avant toute chose, je n'ai pas récupéré la version 2.2.5 de muparser (demandé aux lignes "../../Herezh_source/MuParser/muparser-2.2.5_GR/". J'ai remplacé tous ces chemins par la version 2.3.4. Est-ce que ça posera problème ?

je pense que c'est ok, (à moins qu'il y ait eu des changements que je n'ai pas vu), je n'ai pas touché les sources de cette librairie

1) fichiers/répertoires manquants :
source Herezh :
- repertoire Herezh_dev/comportement/loi_visco_plastiques

dans le .cbp tu remarqueras qu'il n'y a pas le source des fichiers de la loi, mais seulement le chemin: pour l'instant j'ai retiré la loi de Norton, donc à ne pas ajouter (mais c'est déjà le cas via le fichier .cbp !)

- repertoire Herezh_dev/G_Var_precompile/Normals

oui

- repertoire Herezh_dev/NRC

a servi mais maintenant ne sert plus, pas de fichier utilisé dans ce répertoire (cf. le .cbp)

_- repertoire Herezh_dev/G_Var_precompile/en_debug_OSXunix

idem, a servi mais maintenant ne sert plus
_

third party :
- fichier muparser-2.3.4/include/muParserStack.h

à si celui-là il sert (il est indiqué dans le .cbp )

- fichier SparseLib++/1.7/src/iohb.cc (NB : il existe un fichier SparseLib++/1.7/src/iohb.c => Faut-il juste changer l'extension en .cc ???)

si tu regardes le .cbp tu y as:

<Unit filename="../../Herezh_source/Partie_2/algebre_lineaire/sparselib++/sp1_5c/src/iohb.c">
            <Option compilerVar="CC" />
            <Option compile="0" />
            <Option link="0" />
        </Unit>

les option compile="0" et link="0" veulent dire que cela ne sert pas

au début j'ai récupéré des choses qui se sont avérés inutilisées donc que j'ai supprimé ensuite

_ et également les 2 répertoires suivants :
- repertoire /home/rio/bin/Herezh/
- repertoire ../../Herezh_source/Herezh_develop/Herezh_dev
Mais ces deux-là, je peux juste les supprimer non ?
_

ce sont les répertoires que j'utilise pour mettre les binaires et pour mettre les sources, donc tu peux évidemment adapter à ce qui t'arrange

2) options du bloc <Build> ... </Build>
dans cette partie, je dois mettre mes propres chemins pour accueillir les exécutables/objets qui seront créés ?
partie "Debug" :
<Option output="bin/Debug/Herezh"
<Option object_output="obj/Debug/" />

oui

et également, je ne sais pas trop quoi mettre ici concernant "Debug" :
<Option working_dir="../tickets_herezh/191/Test_R_BPL1" />

c'est un chemin de fichier que j'ai utilisé pour débugger, donc toi tu mets ce que tu veux en fct des fichiers que tu vas exécuter

_3) fichier étrange :
il y a le fichier suivant dans les sources Herezh :
Herezh_dev/Enumeration/Enum_ddl (copy/ conflict on 2017-11-21).h

est-ce normal ? ou un fichier qui traine et qui devrait être supprimé de git ?_

oui effectivement, c'est des fichiers qui n'ont pas lieu d'être, ils ne sont pas utilisés (cf. le .cbp) , j'ai oublié de les désélectionner lorsque j'ai fait les grands push ... il faut dire qu'il y a beaucoup de fichiers !!
Ceci étant ce n'est pas un pb pour la compilation et l'édition de lien avec le cbp qui est fourni.

bon du coup je suis revenu à la version muParser 2.2.5 à l'endroit où muParserStack.h était demandé (existe dans la version 2.2.5, n'existe plus dans la version 2.3.4 ??? pas une bonne nouvelle pour le futur...)

je suis revenu à la version 1.5 de SparseLib++ au lieu de 1.7 (sinon à la compilation le type COMPLEX renvoie l'erreur "COMPLEX does not name a type"). Même remarque que précédemment pour le futur...

à la compilation, j'ai également une erreur dans le fichier gmres.h de la lib IML++ :
la "void" ApplyPlaneRotation est appelée avant d'être définie. J'ai donc à la main modifié ce fichier pour placer la déclaration de cette subroutine avant la subroutine GMRES qui appelle ApplyPlaneRotation.
ça se complique, je ne sais pas trop ce que je fais là.

Et au final, j'en suis arrivé à des erreurs dans muparser-2.3.4/src/muParser.cpp :
aux lignes du genre : DefineFun(_T("sum"), MathImpl<value_type>::Sum);
j'ai le message : ‘Sum’ is not a member of ‘mu::MathImpl<double>
il y en a pas mal de ce genre (sur Avg, Min, Max, etc...)

donc retour à la version 2.2.5 de muParser partout pour voir :
cette fois, c'est une erreur sur : /usr/bin/ld : ne peut pas trouver -lcblas : Aucun fichier ou dossier de ce nom
et pourtant j'ai blas

c'est une vraie guerre de tranchée...
et je ne sais pas si ce ticket est fait pour ça...

houla, j'ai juste remplacé -lcblas par -lblas et ça a compilé !!

Enfin j'ai obtenu une version Debug (mais 9 erreurs pour la version fast, la lutte continue)

Le lecteur à l'oeil aiguisé remarquera un COUCOU dans ce lancement de Herezh :) C'est un premier pas...

1. #
2. | | ==== === ==== ==== | | | | #
3. | | | | | | / | | | | #
4. |====| |=== === |=== / |====| ------- ------- #
5. | | | | \ | / | | | | #
6. | | ==== | \ ==== ==== | | | | #
7. # #######################################################################
8. Herezh++ is distributed under GPL 3 license ou ultérieure. #
9. Copyright (C) 1997-2022 Université Bretagne Sud (France) #
10. AUTHOR : Gérard Rio #
11. E-MAIL : gerardrio56@free.fr #
12. Certification IDDN.FR.010.0106078.000.R.P.2006.035.20600 #
13. # #######################################################################
14. (version avec le plus de verifications pendant le calcul et les I/O )
    version 7.028
    -- initialisation de l'entree des donnees
    pb en ouverture en lecture du fichier : ancien , on continu quand meme
    entrer la racine du nom du fichier .info :
    ou repondre 1 pour une entree via le fichier base-info
    COUCOU <= et oui COUCOU
    ou repondre 2 pour une entree via un serveur base-info
    ou repondre x pour la creation d'un schema XML pour creer
    un fichier de commade: Herezhpp.xsd
    ou repondre n pour la construction d'un nouveau fichier de commande

toujours échec pour la version Release

message erreur :
Herezh_dev/Resolin/Matrices_externes/MV++/iotext_GR.h|32|error: ‘MV_Vector_double’ has not been declared|

succès pour créer une version fast
il a fallu :
- modifier les options de compilation (en reprenant celles proposées dans Herezh_dev/fichiers_makefile)
- sans le savoir, c'est g++ qui était utilisé malgré le choix de gcc dans le .cbp. J'ai imposé gcc via les settings de codeblocks directement
- j'ai été obligé de désactiver la compilations des sources suivantes :

Herezh_dev/comportement/Hyper_elastique/HyperDN.cc

toutes celles dans Herezh_dev/Resolin/Matrices_externes/MV++/ sauf mvvdio.cc (sans le savoir!)
liste des fichiers désactivés dans MV++ :
iotext_GR.h
mvblas_GR.h
mvmtp_GR.h
mvvind_GR.h
mvvrf_GR.h
mvvtp_GR.h

c'est surtout iotext_GR.h qui coinçait (type MV_Vector_double inconnu)
J'ai désactivé les autres dans la foulée, mais ils passent peut-être

bon, j'ose pas tester un calcul, histoire de pas me gacher le week-end. Je reste sur une victoire