il faut recompiler KDE certes, mais c'était justement ce qu'il allait faire pour mettre à jour KDE, donc quel est le problème ?
le problème de base, c'est pas KDE mais le fait que l'ABI en C++ est complètement casse gueule (Et je suis dev C++).
Le moindre ajout / modification de fonction "virtual" pète l'ABI
Le moindre ajout / modification/ suppression de data-member, même privé, change la taille de la class donc pète l'ABI.
Le moindre changement dans les signatures, comme un changement de "int" à "unsigned int" pour une fonction change le name mangling, donc pète l'ABI.
En C++, les devs qui arrivent à maintenir une compatibilité binaires parfaite entre version (comme Qt) se rapprochent plus du statuts de Dieu vivant que de développeur.
Pour reprendre ta phrase, oui c'est un GROS problème de devoir recompiler toute la stack à chaque changement dans une bibliothèque.
1- Une lib dont l'ABI casse tous les trois jours est une lib inutilisable dans un soft non packagé dans les dépots officiels.
2- L’intérêt principal des bibliothèque partagées est justement de pouvoir patcher les différents modules de manière indépendante ... ( Ou autrement dit, ne pas recompiler 20k package chaque semaine à cause d'un bug fix openSSL )
La solution au problème, serait qu'une bande de dudes se décide une bonne fois pour toute de définir une ABI C++ un peu plus saine d'esprit. Une qui ne vous force pas à utiliser des patterns Pimpl et des fonctions pointers toutes les 3 lignes.
[^] # Re: Quelqu'un peut-il m'expliquer le problème avec l'ABI de KDE
Posté par Firwen (site web personnel) . En réponse au journal Pourquoi empaqueter KDE prend-il du temps ?. Évalué à 10. Dernière modification le 18 août 2014 à 08:22.
le problème de base, c'est pas KDE mais le fait que l'ABI en C++ est complètement casse gueule (Et je suis dev C++).
En C++, les devs qui arrivent à maintenir une compatibilité binaires parfaite entre version (comme Qt) se rapprochent plus du statuts de Dieu vivant que de développeur.
Pour reprendre ta phrase, oui c'est un GROS problème de devoir recompiler toute la stack à chaque changement dans une bibliothèque.
1- Une lib dont l'ABI casse tous les trois jours est une lib inutilisable dans un soft non packagé dans les dépots officiels.
2- L’intérêt principal des bibliothèque partagées est justement de pouvoir patcher les différents modules de manière indépendante ... ( Ou autrement dit, ne pas recompiler 20k package chaque semaine à cause d'un bug fix openSSL )
La solution au problème, serait qu'une bande de dudes se décide une bonne fois pour toute de définir une ABI C++ un peu plus saine d'esprit. Une qui ne vous force pas à utiliser des patterns Pimpl et des fonctions pointers toutes les 3 lignes.