Je te le déconseille sauf si tu veux participer à l’aventure du développement, dans ce cas là je t’encourage. :)
Si tu veux aider à débuger XQF en connaissance de cause, bienvenue ! Voici quelques informations à savoir :
XQF est un projet vieux de 16 ans et qui a stagné entre 6 et 8 ans : les dernières modifications qui ont été faites il y a moins de 8 ans avant la reprise du développement ne touchent rien à la façon dont fonctionne le logiciel (ajoutent seulement des jeux par exemple).
Beaucoup de code encore utilisé a été écrit pour GTK+1, pour le moment tout ce qui a été fait a été de permettre que ce code compile encore avec GTK+2, mais il n’a pas été complètement réécrit pour GTK+2 ou 3. Le code ne compile qu’avec le switch -DGTK_ENABLE_BROKEN=1, qui veut dire ce que ça veut dire, ce n’est pas -DGTK_ENABLE_DEPRECATED=1 mais BROKEN, XQF utilise du code qui est considéré comme cassé, pas seulement obsolète.
Certaines parties sont en refonte complète et peuvent casser du jour au lendemain. Lorsque j’ai réécrit certaines parties, j’ai joué au chat et à la souris avec les obsolescences. Par exemple si XQF utilisait la fonction toto, la doc de toto disait « toto est obsolète, il faut utiliser toto_ng », mais la doc de toto_ng disait que cette fonctionnalité était elle-même rendue obsolète par la fonction tata elle-même rendue obsolète par la fonction tata_ng, etc. Et à chaque montée d’API, il faut prévoir des cassures dans les coins !
Je ne garantie pas la continuité des données en dehors des versions taggées. Il est arrivé par exemple que des versions de développement de XQF enregistre en cache une liste de serveur mal formée (due à des caractères spéciaux mal filtrés), ce qui signifie que même une version stable de XQF pouvait se prendre les pieds dans le tapis après avoir utilisé une version non stable, en relisant les listes. Autre exemple, lors du passage à $XDG_CONFIG_HOME, j’ai utilisé provisoirement un nom de chemin, puis finalement un autre. XQF ne prend en charge que la transition entre les noms de fichiers de configuration utilisés dans les versions stables.
Cependant, je préviens dans les tickets quand une intervention manuelle est nécessaire après la correction d’un bug qui peut être propagé par des fichiers écrits.
On vient de mettre en place un système d’intégration continue qui vérifie la compilation avec gcc et clang à chaque commit et qui permettra de faire des tests plus poussés. Mais pour le moment ça ne vérifie que le succès de la compilation, et ça ne garantit pas que le succès du programme lui-même.
À bientôt peut-être, effectivement ça peut être très amusant, et toucher un vieux code peut être quelque chose de très passionnant. :-)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Cool
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche XQF 1.0.6, la résurrection. Évalué à 9.
Je te le déconseille sauf si tu veux participer à l’aventure du développement, dans ce cas là je t’encourage. :)
Si tu veux aider à débuger XQF en connaissance de cause, bienvenue ! Voici quelques informations à savoir :
XQF est un projet vieux de 16 ans et qui a stagné entre 6 et 8 ans : les dernières modifications qui ont été faites il y a moins de 8 ans avant la reprise du développement ne touchent rien à la façon dont fonctionne le logiciel (ajoutent seulement des jeux par exemple).
Beaucoup de code encore utilisé a été écrit pour GTK+1, pour le moment tout ce qui a été fait a été de permettre que ce code compile encore avec GTK+2, mais il n’a pas été complètement réécrit pour GTK+2 ou 3. Le code ne compile qu’avec le switch
-DGTK_ENABLE_BROKEN=1, qui veut dire ce que ça veut dire, ce n’est pas-DGTK_ENABLE_DEPRECATED=1maisBROKEN, XQF utilise du code qui est considéré comme cassé, pas seulement obsolète.Certaines parties sont en refonte complète et peuvent casser du jour au lendemain. Lorsque j’ai réécrit certaines parties, j’ai joué au chat et à la souris avec les obsolescences. Par exemple si XQF utilisait la fonction
toto, la doc detotodisait «toto est obsolète, il faut utilisertoto_ng», mais la doc detoto_ngdisait que cette fonctionnalité était elle-même rendue obsolète par la fonctiontataelle-même rendue obsolète par la fonctiontata_ng, etc. Et à chaque montée d’API, il faut prévoir des cassures dans les coins !Je ne garantie pas la continuité des données en dehors des versions taggées. Il est arrivé par exemple que des versions de développement de XQF enregistre en cache une liste de serveur mal formée (due à des caractères spéciaux mal filtrés), ce qui signifie que même une version stable de XQF pouvait se prendre les pieds dans le tapis après avoir utilisé une version non stable, en relisant les listes. Autre exemple, lors du passage à
$XDG_CONFIG_HOME, j’ai utilisé provisoirement un nom de chemin, puis finalement un autre. XQF ne prend en charge que la transition entre les noms de fichiers de configuration utilisés dans les versions stables.Cependant, je préviens dans les tickets quand une intervention manuelle est nécessaire après la correction d’un bug qui peut être propagé par des fichiers écrits.
On vient de mettre en place un système d’intégration continue qui vérifie la compilation avec
gccetclangà chaque commit et qui permettra de faire des tests plus poussés. Mais pour le moment ça ne vérifie que le succès de la compilation, et ça ne garantit pas que le succès du programme lui-même.À bientôt peut-être, effectivement ça peut être très amusant, et toucher un vieux code peut être quelque chose de très passionnant. :-)
ce commentaire est sous licence cc by 4 et précédentes