Libelektra: génération de code pour les erreurs

Personnellement, je préfère l'option 1. Les codes d'erreur ne devraient changer que très rarement, ce qui rend négligeable l'effort supplémentaire d'écriture manuelle du code C et de synchronisation des autres langues. L'effort initial devrait également être moindre par rapport à la mise en place de toute forme de génération automatique.

Pourquoi pas l'option 2 ?

Les modèles de moustache doivent être fournis avec les données d'entrée d'une manière ou d'une autre. Soit nous devons utiliser un exécutable personnalisé qui est compilé au moment de la construction. Dans ce cas, nous nous débarrasserions simplement des std::cout << ... dans le code C++, mais rien d'autre ne changerait. L'autre option consiste à utiliser l'exécutable moustache par défaut, qui est un script Ruby et nécessite donc l'installation de Ruby.

De plus, kdb gen ne peut pas être réutilisé, car cela nécessiterait de compiler d'abord kdb , ce qui nécessite kdberrors.h .

Pourquoi pas l'option 3 ?

La génération du code C peut fonctionner dans CMake, mais des langages plus complexes peuvent avoir des problèmes avec l'utilisation de CMake.

Si nous décidons d'utiliser une forme de génération de code, nous ne devrions générer que les parties qui doivent absolument être générées. Par exemple, le kdberrors.h actuel contient beaucoup de code qui est complètement statique et indépendant des erreurs que nous avons réellement. Ce code ne doit pas être généré, nous devrions le #include à partir d'un fichier statique.

Je préfère également l'option 1 en raison des codes d'erreur stables. L'ajout de la génération de code ajoute également une complexité inutile au code global qui est à nouveau sujet aux erreurs.

@kodebach merci pour votre élaboration sur l'option 2

Je pense qu'il est assez clair que nous optons pour l'option 1,

Pour les fixations, cela signifie que peu de changements.

Ce qui serait bien si nous avions un tutoriel d'écriture contraignant, décrivant :

1. quelles parties des fixations Elektra ont un sens (application, plugin, outils, ...)
2. comment intégrer les liaisons dans CMake (si possible et utile)
3. quelles parties des reliures peuvent et doivent différer pour chaque langue. Ceci comprend:
   
   
   
   • itérateurs
   
   
   • conversion en types natifs (strings, int, ...)
   
   
   • surcharge de l'opérateur (si disponible)
   
   
   • d'autres intégrations de langage de programmation (flux, hash-codes, identité, ...)
   
   
   • a renvoyé des erreurs des fonctions kdb (de quoi parle ce problème ici)
   
   

J'espère que nous pourrons étendre ce tutoriel pour les différentes situations que nous voyons dans différentes langues. @Piankero pouvez-vous s'il vous plaît commencer à écrire le tutoriel, en particulier la section de gestion des erreurs (comment implémenter l'héritage, ...)

Tutoriel : #2875
Décision de conception : # 2872