Je pose la question parce que le plus gros morceau restant (outre les tests, même si j'en ai déjà fait ^^) est de faire le travail dans KTIGCC...
Evidemment, il y a des membres de GCC4TI ML qui connaissent déjà l'API Qt / KDE. Je pourrais aussi le faire moi-même en regardant la doc des classes et fonctions qui vont bien, comme je l'ai fait il y a quelques jours pour le parsing de la ligne de commande avec Glib dans TILP (même si j'ai pas fait grand chose, c'est quasi-exclusivement Romain qui a implémenté mes feature requests
).
Mais ça serait fait plus vite et mieux par quelqu'un qui connaît déjà l'API (voire qui, dans ton cas, est le créateur du programme).
Même si tu ne comptes pas ajouter le support des noms avec répertoire dans le champ "Compress program", il faut de toute façon corriger deux bugs de KTIGCC:
* limitation de la taille du champ à 8 caractères (déjà reporté);
* absence de vérification de la validité des noms. Contrairement à l'IDE Delphi, KTIGCC ne voit aucun inconvénient à une data variable nommée "a\a\a" (ou a\a\a).
Comme en l'absence de patches, ld-tigcc (le patch que j'ai posté sur le Trac est incomplet...), ainsi que le reste de la toolchain, n'y voient aucun inconvénient non plus, les noms foireux se retrouvent dans les exécutables... et le code de startup, sous AMS et PedroM, ne trouvant pas un tel path, arrête l'exécution du programme.
En fait, la vérification des paths est encore plus compliquée que ce qui est mentionné dans le ticket #34. En effet, ld-tigcc, grâce à main.c :: DecodeOnCalcName, supporte l'utilisation du charset natif de la machine.
Mais aucun des deux IDE ne le supporte vraiment: non seulement les champs d'edit sont trop courts (IDE Delphi et KTIGCC), mais '%' n'est pas un caractère autorisé par le vérificateur de l'IDE Delphi (N/A pour KTIGCC qui ne vérifie rien du tout, pour le moment). La taille max du champ d'édition dépend de son contenu...
(je n'ai pas essayé, mais je ne vois pas pourquoi l'utilisation du charset natif ne fonctionnerait pas avec tprbuilder et tigcc, en revanche)
[EDITs: suppression d'un smiley intempestif, quelques ajouts.]