L'échec du test specload est assez explicite :

reason: : App '/home/jenkins/workspace/libelektra_master-Q2SIBK3KE2NBEMJ4WVGJXAXCSCB77DUBUULVLZDKHQEV3WNDXBMA/libelektra/obj-x86_64-linux-gnu/bin/elektra-specload-testapp' doesn't exist or is not executable

Pour quickdump , je ne peux pas dire exactement ce qui ne va pas, mais cela échoue quelque part dans elektraQuickdumpSet . Il devrait y avoir une erreur définie dans setKey , mais elle n'est pas enregistrée je pense (cela devrait probablement être changé).

Aucune idée, pourquoi gopts échoue. Puisqu'aucun message d'erreur n'a été imprimé, je soupçonne que le testapp elektra-gopts-testapp n'a pas pu être exécuté (c'est le seul cas où aucun message d'erreur ne serait imprimé). Cela correspondrait également à l'erreur specload .

L'échec du test specload est assez explicite :

Oui, mais il est faux de s'attendre à des fichiers binaires dans le répertoire de construction après l'installation de l'application. Les fichiers binaires doivent être installés et recherchés dans le répertoire de construction ou d'installation.

L'échec du test specload est assez explicite :

Oui, mais il est faux de s'attendre à des fichiers binaires dans le répertoire de construction après l'installation de l'application. Les fichiers binaires doivent être installés et recherchés dans le répertoire de construction ou d'installation.

Oh, j'ai raté que vous ayez installé Elektra. Cependant, cela n'explique pas l'échec quickdump , ses données de test sont correctement installées.

Je ne sais pas non plus comment résoudre ce problème. Bien sûr, nous pouvons installer les exécutables des applications de test, mais les exécutables de test réels devraient être modifiés pendant l'installation pour changer l'endroit où ils recherchent l'application de test.

C'est trop de travail pour rechercher les binaires (dans le répertoire de construction ou d'installation), nous pouvons également exclure les tests de l'installation.

Nous pourrions simplement utiliser un chemin relatif et nous assurer qu'il reste le même pendant l'installation, par exemple avoir les deux binaires dans le même répertoire.

Oui bonne idée.

Une solution plus générale serait d'avoir kdb <command> également disponible dans le répertoire de construction (ne fonctionne actuellement que si Elektra est installé). Ce serait un travail considérable car KDB_EXEC_PATH ne prend en charge qu'un seul chemin, mais les fichiers binaires sont dispersés dans de nombreuses parties différentes du répertoire de construction.

nous avons kdbdisponible aussi dans le répertoire build

Les tests peuvent facilement être exécutés via ctest et/ou make . Quant aux autres commandes, la plupart d'entre elles n'ont de toute façon de sens que pour une version installée d'Elektra.

Nous pourrions simplement utiliser un chemin relatif et nous assurer qu'il reste le même pendant l'installation, par exemple avoir les deux binaires dans le même répertoire.

Il s'avère que c'est plus difficile que prévu. La stdlib traiterait le chemin relatif comme relatif au répertoire de travail actuel, ce qui n'est pas utile et la résolution du chemin relatif au chemin de l'exécutable actuel n'est pas possible de manière indépendante de la plate-forme.

Ainsi, la méthode kdb <command> serait plutôt attrayante.

Pour l'installation il suffit de l'installer dans TARGET_TOOL_EXEC_FOLDER

Ce n'est que pendant la construction que nous avons besoin d'un moyen de combiner build_dir/bin build_dir/scripts source_dir/scripts et les répertoires actuels (peut-être aussi build+source).

@kodebach est-ce toujours ouvert ? Pouvons-nous détecter cette situation et laisser les tests ne pas fonctionner dans cette situation ?

Ou nous le corrigeons : KDB_EXEC_PATH autorise désormais plusieurs chemins, nous pouvons donc ajouter les dossiers dont nous avons besoin à partir du répertoire build/source. Ensuite, vous laissez simplement kdb faire le travail de recherche de l'exécutable.

AFAIK c'est toujours ouvert, oui.

Nous avons déjà la fonction srcdir_file pour les tests. Nous pourrions introduire un bindir_file similaire. bindir serait par défaut ${CMAKE_INSTALL_PREFIX}/${TARGET_TOOL_EXEC_FOLDER} , mais il y aurait un moyen de le remplacer. CTest serait configuré (via le add_test de CMake) de sorte que bindir soit défini sur ${CMAKE_BINARY_DIR}/bin lors de l'utilisation ctest .

Et simplement ajouter le bindir à KDB_EXEC_PATH et utiliser kdb <bin> ne fonctionne pas ?

Non, pour plusieurs raisons :

1. Ce sont des tests testmod_ , ils ne devraient pas s'appuyer sur kdb .
2. Comment pourrions-nous trouver kdb alors ? L'exécution de tests avec make run_all ne doit pas utiliser le kdb installé, mais celui de ${CMAKE_BINARY_DIR}/bin .
3. KDB_EXEC_PATH contiendrait toujours le dossier ${CMAKE_BINARY_DIR}/bin après l'installation kdb , ce qui pourrait causer différents problèmes.

Ce sont des tests testmod_, ils ne doivent pas s'appuyer sur kdb.

Oui je suis d'accord. C'est bien s'ils fonctionnent de manière autonome.

Comment pourrions-nous alors trouver kdb ? L'exécution de tests avec make run_all ne doit pas utiliser la kdb installée, mais celle de ${CMAKE_BINARY_DIR}/bin.

Les tests Shellrecorder utilisent déjà kdb, et ils fonctionnent à la fois pour Elektra installé et à partir du répertoire de construction (même si Elektra est installé).

KDB_EXEC_PATH contiendrait toujours le dossier ${CMAKE_BINARY_DIR}/bin, après l'installation de kdb, ce qui pourrait causer différents problèmes.

Non, KDB_EXEC_PATH n'est pas défini pour un kdb installé (sauf si l'utilisateur le définit)

Les tests Shellrecorder utilisent déjà kdb, et ils fonctionnent à la fois pour Elektra installé et à partir du répertoire de construction (même si Elektra est installé).

Cela fonctionne car les tests shell exécutent toujours "$KDB" et jamais kdb . Et aussi parce que make run_all et ctest utilisent par exemple des scripts testscr_check_meta.sh , alors que kdb utilise par exemple check_meta.sh . Dans le premier, nous définissons $KDB sur ${CMAKE_BINARY_DIR}/bin/kdb dans le second, il est simplement défini sur kdb (et donc résolu via $PATH ).

Non, KDB_EXEC_PATH n'est pas défini pour un kdb installé (sauf si l'utilisateur le définit)

Je viens de prendre la version principale d'Elektra et de l'installer. Le fichier /usr/local/lib/elektra/tool_exec/check_meta contient la ligne :

export KDB_EXEC_PATH="/home/klemens/libelektra/build/bin:$KDB_EXEC_PATH"

Bien sûr, cela n'affecte pas les tests testmod_* , mais c'est quand même faux. Je vais créer un nouveau sujet.

@petermax2 @kodebach quel est l'état de ce problème ? Est-ce que comme #3246 est corrigé maintenant (via #3409), le reste de ce problème ne concerne que des problèmes d'emballage ou y a-t-il quelque chose à implémenter ?

AFAIK, le problème d'origine avec specload existe toujours. TBH Je ne sais pas pourquoi nous avons même la possibilité d'installer des tests testmod_ . Cela n'a aucun sens. Ce sont des tests autonomes qui testent un seul plugin de manière isolée. S'ils s'exécutent réellement, leurs résultats seront les mêmes, qu'ils soient exécutés dans le répertoire de construction ou le répertoire d'installation.

TBH Je ne sais pas pourquoi nous avons même l'option d'installer testmod_ tests.

Pour le moment, nous n'avons pas d'option pour désactiver l'installation des tests, mais nous pourrions faire un remplacement local pour que add_plugintest n'installe pas les tests (comme INSTALL_TESTING mais pour add_plugintest ).

Cela n'a aucun sens. Ce sont des tests autonomes qui testent un seul plugin de manière isolée. S'ils s'exécutent réellement, leurs résultats seront les mêmes, qu'ils soient exécutés dans le répertoire de construction ou le répertoire d'installation.

:wink:, il y a beaucoup de différences, mais la plupart d'entre elles étaient liées au système de plugins lui-même (elles sont, espérons-le, toutes corrigées maintenant). Néanmoins, il existe un large éventail de problèmes de dépendance et de problèmes d'installation possibles, il est donc préférable d'exécuter les tests testmod à l'état installé que de ne rien exécuter. Mais vous avez raison de dire que s'il existe un test shellrecorder, le test testmod est inutile.

• [X] Donc pour quickdump c'est clair, le test testmod n'a pas besoin d'être installé.
• [ ] Pour specload, il y a un test mais il semble assez minime, peut-être bien mais mieux vaut vérifier à nouveau.
• [ ] Pour les gopts, nous pourrions laisser des exemples de programmes s'exécuter dans doc/tutorials/command-line-options.md ?

@kodebach pouvez-vous vérifier si ces tests peuvent être exclus en toute sécurité ?

@robaerd pouvez-vous les exclure dans l'un de vos PR CI ? (Avant ou où vous ajoutez le test des packages.)

@markus2330 Le problème de quickdump se produit-il toujours pour vous ? AFAIK, nous n'avons jamais compris ce qui n'allait pas là-bas. Je n'ai pas non plus pu le reproduire.

Pour gopts et specload voir #3618

Oui, se produit toujours :

kdb testmod_quickdump                                                                                                                                                                                                                    
QUICKDUMP     TESTS
==================

test varint
test basics
/home/jenkins/workspace/libelektra_master/libelektra/src/plugins/quickdump/testmod_quickdump.c:111: error in test_basics: call to kdbSet was not successful
zsh: segmentation fault (core dumped)  noglob kdb testmod_quickdump

Ou quand je l'appelle depuis la source:

```TESTS DE VIDANGE RAPIDE

variante de test
bases des tests
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:92 : erreur dans test_basics : l'appel à kdbGet n'a pas abouti
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:93 : erreur dans test_basics : la taille réelle de mmks2 était de 0
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:93 : erreur dans test_basics : Échec de la comparaison du jeu de clés, la taille des jeux de clés n'est pas égale à la taille (mmks1) : 8, taille (mmks2) : 0
mmks1 :
Clé 0x55a9efd438d0 : dir:/tests/bench/__112, chaîne : gQHLlzB36CqIFlf, meta:/meta/_35 : O6xNya6srhNhMFC, meta:/meta/_39 : ublVuvyh1DgfOKU, meta:/meta/_58 : 5Nyde2MHJODCBAT, meta:/meta/_79 : ZK2xlaRMfobquxp, meta:/meta/_90 : 0kCcc1pK7hOgY3F
Clé 0x55a9efd44250 : dir:/tests/bench/__114, chaîne : , meta:/binary :
Clé 0x55a9efd441a0 : dir:/tests/bench/__333, chaîne : SxTUAjM6OIpUV6s
Clé 0x55a9efd440f0 : dir:/tests/bench/__506, chaîne : cGqEvmXxUayNCf8
Clé 0x55a9efd44040 : dir:/tests/bench/__859, chaîne : rOI5aVFGlnjPLYJ
Clé 0x55a9efd43f90 : dir:/tests/bench/__863, chaîne : 8IBjbd5pzYBehrs
Clé 0x55a9efd43f20 : dir:/tests/bench/__868, chaîne : UVM0OPTf68yNXij
Clé 0x55a9efd43d90 : dir:/tests/bench/__911, chaîne : PgNbwPxfeqD30pH, meta:/meta/_35 : O6xNya6srhNhMFC
mmks2 :
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:111 : erreur dans test_basics : l'appel à kdbSet n'a pas abouti
zsh : erreur de segmentation (core dumpé) LD_LIBRARY_PATH=lib bin/testmod_quickdump

Stacktrace:

0 0x00007fa7c770ed74 dans _IO_getc (fp=0x0) à getc.c:37

1 0x000055a9ede54c58 dans compare_binary_files (filename2=0x55a9efd42a30 "/usr/local/share/elektra/test_data/quickdump/test.quickdump.out", filename1=0x55a9efd429e0 "/usr/local/share/elektra/test_data/quickdump/test.quickdump" )

at /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:31

2 test_basics() sur /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:113

3 0x000055a9ede545d7 dans main (argc=1, argv=0x7ffff28085f8) sur /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:278

0 0x00007fa7c770ed74 dans _IO_getc (fp=0x0) à getc.c:37

37 getc.c : Datei oder Verzeichnis nicht gefunden.
(gdb) bt

0 0x00007fa7c770ed74 dans _IO_getc (fp=0x0) à getc.c:37

1 0x000055a9ede54c58 dans compare_binary_files (filename2=0x55a9efd42a30 "/usr/local/share/elektra/test_data/quickdump/test.quickdump.out", filename1=0x55a9efd429e0 "/usr/local/share/elektra/test_data/quickdump/test.quickdump" )

at /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:31

2 test_basics() sur /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:113

3 0x000055a9ede545d7 dans main (argc=1, argv=0x7ffff28085f8) sur /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:278

(gdb) bt complet

0 0x00007fa7c770ed74 dans _IO_getc (fp=0x0) à getc.c:37

    result = <optimized out>

1 0x000055a9ede54c58 dans compare_binary_files (filename2=0x55a9efd42a30 "/usr/local/share/elektra/test_data/quickdump/test.quickdump.out", filename1=0x55a9efd429e0 "/usr/local/share/elektra/test_data/quickdump/test.quickdump" )

at /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:31
    f2 = 0x0
    c1 = <optimized out>
    f1 = 0x0
    result = 0
    c2 = <optimized out>
    f1 = <optimized out>
    f2 = <optimized out>
    result = <optimized out>
    c1 = <optimized out>
    c2 = <optimized out>
    end1 = <optimized out>
    end2 = <optimized out>

2 test_basics() sur /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:113

    conf = <optimized out>
    modules = 0x55a9efd43a00
    setKey = 0x55a9efd42bb0
    errorKey = <optimized out>
    plugin = 0x55a9efd43b00
    ks = <optimized out>
    infile = 0x55a9efd429e0 "/usr/local/share/elektra/test_data/quickdump/test.quickdump"
    outfile = 0x55a9efd42a30 "/usr/local/share/elektra/test_data/quickdump/test.quickdump.out"
    __func__ = "test_basics"

3 0x000055a9ede545d7 dans main (argc=1, argv=0x7ffff28085f8) sur /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:27

```

Ou quand je l'appelle depuis la source:

Lors de l'exécution directe des tests, veuillez utiliser ctest (par exemple ctest -R testmod_quickdump --ouptut-on-failure ) pour vous assurer que l'environnement, les arguments, etc. sont correctement définis.

Dans ce cas, je pense que LD_LIBRARY_PATH=lib bin/testmod_quickdump ../src/plugins/quickdump est ce dont vous avez besoin (si vous voulez déboguer avec par exemple gdb ).

/usr/local/share/elektra/test_data/quickdump/test.quickdump existe-t-il sur votre système et le processus a-t-il le droit d'écrire dans /usr/local/share/elektra/test_data/quickdump/test.quickdump.out ? (Peut-être avez-vous besoin sudo kdb testmod_quickdump )

Si oui, veuillez ajouter

output_error (setKey);
output_warnings (setKey);

dans testmod_quickdump.c:112 et publiez le résultat.

elektraQuickdumpSet a échoué, donc le fait que compare_binary_files échoue est tout à fait attendu. (Le message d'erreur pourrait bien sûr être meilleur et le segfault pourrait être évité, mais c'est un test _failed_ donc cela n'a pas vraiment d'importance)

Oui, le problème est que les cas de test essaient de créer des fichiers temporaires dans un dossier qui ne convient pas à cela. sudo kdb testmod_quickdump fonctionne sans problème. Il devrait donc suffire d'utiliser nos fonctions pour créer des fichiers temporaires au lieu d'utiliser "test_data/quickdump/test.quickdump.out"

Nous pouvons changer cela oui, mais de nombreux tests ne fonctionnent pas sans sudo toute façon, donc je ne vois pas vraiment cela comme un problème

De quels tests parles-tu ? J'exécute toujours toute la suite sans sudo (mais avec des autorisations d'écriture sur le chemin d'Elektra). testmod_quickdump est autant que je sache le seul test avec ce problème.

mais avec des autorisations d'écriture sur le chemin d'Elektra

D'accord, cela fonctionne aussi, mais sur un système standard, ces chemins ne sont qu'un accès root.

Je pense toujours que tout le concept d'exécution de tests unitaires dans une version installée d'Elektra est étrange et que le problème de quickdump est purement un problème de droits d'utilisateur et non un bogue, mais je changerai le chemin dans # 3618.

J'ai maintenant mis à jour le code dans #3618. J'ai également trouvé un code similaire dans testmod_dump et j'ai bien changé. Aucune idée, pourquoi cela n'a pas échoué pour vous. testmod_xmltool pourrait avoir un problème similaire (bien que le code soit différent donc je ne l'ai pas changé).

testmod_quickdump n'était qu'un seul de ceux qui utilisaient des fichiers binaires et n'utilisaient donc pas compare_line_files . Par conséquent, les autres ne seraient pas en erreur de segmentation, mais les tests devraient toujours échouer.

Et le problème de quickdump est purement un problème de droits d'utilisateur et non un bogue,

C'est une violation de FHS, les applications ne sont pas censées écrire sur /usr, il peut même être en lecture seule.

Pour l'écriture, nous ne devons utiliser que des fichiers temporaires et nous devons également les nettoyer une fois les tests terminés.