7Fermer9
Kevin KoflerLe 06/06/2009 à 20:06
Lionel Debroux (./6) :
Très mauvaise idée, puisque KDE ne maintient pas la compatibilité antérieure, et que tu le comprennes ou non, des gens sont encore sous KDE 3. Et puis je pense qu'il y a plus urgent à faire...

L'intégration KDE 3 plante avec le gtk-qt-engine Qt 4 (parce que ça mélange les 2 versions incompatibles de Qt), donc pour moi la priorité de ceci est très haute. On peut garder le support KDE 3 à côté pour l'instant. Mais tu peux aussi désactiver l'intégration KDE (du moins si tu utilises le patch pour KTIGCC qui lui fait utiliser D-Bus à la place de DCOP) ou installer les libs KDE 4 (parfaitement possible sur un système KDE 3, cf. Fedora 8).
Hmm, c'est portable entre distros ? Je n'ai pas trouvé en deux minutes de lien convaincant à propos de "minizip".

C'est un sous-paquetage de zlib sous Fedora. Pour les autres distributions, rien n'empêche de le packager. C'est une dépendance au même titre que les tilibs. Utiliser une copie interne d'une lib système comme minizip n'est pas autorisé par les Packaging Guidelines de Fedora.
Vu que ça ne coûte à peu près rien en maintenance de supporter VC++, et que supprimer le support de VC++ n'apporte rien, je doute de la priorité, et encore plus de la nécessité, de ceci...

Au contraire, ça coûte beaucoup en maintenance: je ne peux pas utiliser les extensions GCC ni le C99 (tableaux de taille variable, déclarations à l'intérieur du code etc.), et il y a pas mal du build system qui est dupliqué. (Ça pourrait être mieux en principe avec CMake, mais pour l'instant on a les autotools d'un côté et des projets VC++ de l'autre.) De plus, les projets VC++ sont bourrés de chemins absolus codés en dur, ils ne marchent que si on duplique le layout exact du disque dur de Romain. Et enfin, je ne peux pas tester avec VC++, seulement avec GNU/Linux natif et cross-MinGW, donc de toute façon le support VC++ a de fortes chances d'arrêter de fonctionner si Romain ne s'en occupe plus. Donc autant être honnête et le virer tout de suite. Rien de plus agaçant que quelque chose dite censée fonctionner qui en réalité ne marche pas du tout!
Romain et moi t'avons fait comprendre que nous ne sommes pas du tout contre sur le principe
...En revanche, tu sais que très rares sont ici ceux qui trouvent admissible de remplacer purement et simplement la syntaxe Motorola, largement utilisée dans l'industrie et de lecture plus agréable, par la syntaxe "libre" GDB, beaucoup moins utilisée dans le monde réel et dont les '%' pourrissent la lecture.

Alors déjà je ne suis pas du tout d'accord, je trouve que la syntaxe devrait être cohérente avec GNU as.

Et ensuite, j'attends ta contribution pour avoir la syntaxe que tu veux (et pas un truc fait à moitié comme ton patch qui ne rendait optionnels que les '%'). Cela dit, je reste contre, parce que ça alourdit pas mal le code d'avoir 2 syntaxes et ça n'apporte rien.
Vu qu'il y a un certain nombre de personnes qui voient l'intérêt de cette option, je ne crois pas que tu aies vraiment le choix de ne pas la garder wink

Si, je suis le mainteneur, je fais ce que je veux, si tu t'amuses à inverser mes changements sur svn.tilp.info, je vais continuer mon travail quelque part où tu n'as pas accès en écriture.