TIGCC: demandes de fonctionnalités (feature requests)... - Page 1

Dans un topic fait pour ne pas être sérieux (plus exactement, pour déplacer le troll que certain a créé dans un topic sérieux et nettoyer ainsi le topic sérieux), il y a eu des posts sérieux (un morceau de topics/117325-moved-tigcc-nom-pour-le-fork/2#45 , par exemple).
Flanker a raison, on devrait créer un topic sérieux dans lequel on parle de feature requests.

Donc, qu'aimeriez-vous voir dans TIGCC (ou son fork qui a un mode plus collectif de décision, bien sûr) ?
TIGCC étant un logiciel ouvert (et même dit "libre"), le fork l'est aussi. Pour être "libre", il suffit, comme Kevin l'a écrit dans topics/2-113677-kdewin-foutage-de-geule ou topics/2-114905-tigcc-contributions-fork (enfin, je crois que c'est un de ces deux-là, mais je n'ai pas envie de reparcourir jusqu'à 360+ posts), de fournir les sources de temps en temps (à l'occasion d'une release, par exemple).
Ca tombe bien, c'est ce qu'on fera tant que l'infrastructure complète ne sera pas publique (ce qui ne tardera très probablement pas... même si c'est une décision à prendre collectivement). Cela qui n'empêche bien sûr pas de pre-relaser des choses, ce que nous avons fait à topics/117269-tigcc-ide-gerant-vti-et-tiemu (TIGCC IDE avec support VTI et TIEmu) ou encore http://tichessteamhq.yuku.com/topic/4650 .
Ce dernier est une contribution en bonne et due forme de patches, que nous avons contribués justement parce qu'on savait qu'il pourrait y avoir des problèmes de nommage (et donc des incompatibilités stupides si on ne résolvait pas le problème à l'amiable, en communauté...), problèmes de nommage qui ne sont toujours pas véritablement résolus parce que personne ne donne son avis .


Récapitulatif des feature requests:
[ul][li]./2: suppression d'au moins un ou deux commentaires spéciaux dans le template de fichier C[/li]
[li]./3: changement de la gestion des dossiers virtuels / physiques dans l'IDE et/ou dans tprbuilder, qui n'est pas forcément intuitive. Feature request déjà postée dans le tracker avant ce topic.[/li]
[li]./16:
[ul][li]ajout de raccourcis claviers pour les outils définis dans le menu Outils. Feature request maintenant postée dans le tracker.[/li]
[li](aussi dans ./52) permettre d'adresser VTI en ligne de commande. Feature request maintenant postée dans le tracker.[/li]
[li] auto-complétion pour l'asm à partir des labels définis en début de ligne. Feature request maintenant postée dans le tracker.[/li][/ul][/li]
[li]./62:
[ul][li]Fichiers sources en feuilles MDI. Feature request maintenant postée dans le tracker.[/li]
[li]Pouvoir ouvrir plusieurs projets à la fois. Feature request maintenant postée dans le tracker.[/li][/ul][/li]
[/ul]

Yoshi Noir a posté:

c'est possible de virer ce tableau über-gros et über-moche pour définir une icône quand on crée un nouveau projet avec TIGCC ?

J'ai répondu:

Hmm. Je ne suis pas très convaincu que ça vaille le coup de changer TIGCC IDE / KTIGCC pour le virer: c'est en effet trivial de supprimer les #defines spéciaux à la main une fois qu'ils ont été créés... mais on peut toujours en discuter
Je vois deux façons de changer le comportement actuel:
* ajouter une option dans le menu préférences, option à laquelle le code qui est dans MainUnit.pas pour le TIGCC IDE et mainform.cpp pour KTIGCC réagit;
* mettre dans un fichier externe le code qui sera utilisé comme template dans le premier fichier C du projet. Cela permet à l'utilisateur de choisir de se passer de manière permanente de ces #defines spéciaux. Autres idées ?

idée bête : mettre dans le post initial une courte description de la demande avec le numéro du post ^^



sinon, de mémoire (ça fait un peu longtemps que je ne me suis pas servi de TIGCC ), il y avait le problème très chiant des dossiers dans l'IDE qui ne correspondaient pas toujours aux dossiers physiques... y aurait-il moyen de changer cela ?

idée bête : mettre dans le post initial une courte description de la demande avec le numéro du post ^^

Tu as raison, mieux vaut le faire tout de suite plutôt que d'attendre que le topic atteigne (par exemple) deux pages

sinon, de mémoire (ça fait un peu longtemps que je ne me suis pas servi de TIGCC ), il y avait le problème très chiant des dossiers dans l'IDE qui ne correspondaient pas toujours aux dossiers physiques... y aurait-il moyen de changer cela ?

Feature request déjà postée dans notre tracker
(ça fait des années qu'on est plusieurs à la réclamer)

un checkbox quand on fait un nouveau projet

[_] générer le code pour afficher une icone

Pour parler de l'IDE ce que je trouve le plus gerbant avec c'est la fenetre d'options du projet, elle est microscopique, impossible de comprendre tel que la moitié des cases a cocher vu leur nom super bien trouvé, il y a tellement de tabs qu'on est obligé de les faire scroller, bref c'est une fenetre bien fait toussa
Si les participants au fork peuvent faire un truc la dessus, je cracherais pas dessus ^^

squalyl (./5) :
un checkbox quand on fait un nouveau projet

[_] générer le code pour afficher une icone

Je serait plus pour le retour du wizard a la création d'un projet, je n'ai toujours pas entendu de raisons valable pour le fait qu'il ai été enlevé...

Lionel Debroux (./1) :
./2: suppression d'au moins un ou deux commentaires spéciaux dans le template de fichier C

Ces commentaires sont là exprès, ils sont censés être remplis, pas supprimés. Et si vraiment on veut les supprimer, la touche Suppr est là pour ça.

./3: changement de la gestion des dossiers virtuels / physiques dans l'IDE et/ou dans tprbuilder, qui n'est pas forcément intuitive.

Impossible, casse la compatibilité antérieure.

Ca se détecte, ça appelle un convertisseur de projet et ça roule.

ou alors, suffit de préciser TPR v2 ou TPR v1 dans le fichier .tpr...

(pour la cloche : est-ce qu'un (gentil) admin pourrait mettre le topic en annonce ? merci )

oui, j'avais envie de jouer avec la cloche

méheu t'as cloché qui? t'imagines si y'a un compteur de cloches?

je me suis self-cloché ^^

huhu

Mmm, à la deuxième cloche, c'est le ban automatique et irrévocable...

./2: suppression d'au moins un ou deux commentaires spéciaux dans le template de fichier C

Ces commentaires sont là exprès, ils sont censés être remplis, pas supprimés. Et si vraiment on veut les supprimer, la touche Suppr est là pour ça.

Je suis assez d'accord, cf. ./2. Mais le fait que je ne trouve pas ça très utile n'empêche pas d'en discuter, je pense

A voir si on veut remettre un Project Wizard (pour y mettre quoi ? En fait, je ne sais même plus ce que le Project Wizard de TIGCC IDE avait )

./3: changement de la gestion des dossiers virtuels / physiques dans l'IDE et/ou dans tprbuilder, qui n'est pas forcément intuitive.

Impossible, casse la compatibilité antérieure.

Ne sois pas bête
Même si ce format est incomplet et inflexible, et qu'on t'en parle depuis des années sans que tu y remédies, la base installée de TPR est importante. Cela n'a pas de sens qu'on ne comprenne pas ce format.
Mais proposer et implémenter un autre format plus flexible (en prenant l'inspiration sur des patterns connus dans les vrais IDEs), on peut

ou alors, suffit de préciser TPR v2 ou TPR v1 dans le fichier .tpr...

Malheureusement, les membres de la TIGCC Team n'ont pas fait dès l'origine ce qui est pourtant un truc basique de génie logiciel (le versionnement des formats de fichiers...), que font nombre de vrais IDEs (entre autres)...
Même s'il se trouvait que TIGCC IDE ET KTIGCC ne se comportent pas mal en présence d'infos non prévues (je n'ai pas regardé), on est à peu près obligés de faire un nouveau format, puisqu'on ne peut pas faire confiance à certain pour ne pas être embêtés dans le futur par des changements intentionnels de comportement.

Mes features requests à moi, tout aussi discutables que le reste. Mais ça fait déjà 'achement plaisir de pouvoir en parler.

=> ajout de raccourcis claviers pour les outils définis dans le menu Outils (ben oui ). Je compile en effet mes projets en deux parties, loader + main part, j'ai donc deux compilations (ou plus) pour un seul projet, puis un package avec d'autres fichiers en plus pour suivre le standard des pack archives proposé par PpHd.
Avec un projet simple, il y a F9 qui fait ça, mais dans mon cas, je dois reprendre la souris pour exécuter mes scripts. Ya moyen ?

=> permettre d'adresse VTI en ligne de commande (c'est peut-être pas possible directement), mais un wrapper pour la fonction d'envoi à VTI est peut-être possible ? genre fonction ("./ce_prog") pour faire ce que ferait l'IDE si je compilais le projet "ce_prog". En script, on appellerait "nom_du_script mon_prog" et le wrapper s'en démerderait. Parce qu'à cause de mes programmes, je peux pas envoyer directement à un ému.

=> auto-complétion pour l'asm à partir des labels définis en début de ligne. J'y goute dans Kate, on s'en passe plus (surtout pour les noms façon _ReturnTableHandlePtr_Loop_End_, bonjour les fautes de typo régulièrement).

Lionel Debroux (./15) :
A voir si on veut remettre un Project Wizard

Je ne suis pas sûr que revenir en arrière soit une bonne idée ici.

Et n'oublie pas que toute fonctionnalité à l'EDI doit être implémentée au moins 3 fois (TIGCC IDE, KTIGCC 1, KTIGCC HEAD (ce qui deviendra KTIGCC 2)), et il y a aussi votre fork de TIGCC IDE maintenant (une quatrième branche à modifier), et si vous voulez que votre fork soit multiplateforme vous serez bien obligés de forker aussi au moins une branche de KTIGCC (cinquième branche à modifier). Donc vous comprendrez que c'est absolument le mauvais moment pour rajouter des fonctionnalités à l'EDI maintenant, il faut attendre KTIGCC 3.

Et je te rappelle aussi que je n'ai pas de mainteneur pour le code Delphi (et non, je ne peux pas le maintenir parce que je n'ai pas Delphi ni le système d'exploitation correspondant). Si tu acceptais de maintenir TIGCC IDE (la version officielle) dans le cadre du projet TIGCC (le vrai), bien sûr tu devrais renoncer à certaines modifications (genre le support de VTI), mais il y aurait beaucoup plus de chances qu'un ajout comme celui-ci soit réalisé.

pour y mettre quoi ?

Effectivement, c'est pour ça que je ne suis pas sûr que ce soit une bonne idée. Un wizard qui ne demande que "[X] commentaires" ne sert pas à grand chose.

En fait, je ne sais même plus ce que le Project Wizard de TIGCC IDE avait

En gros les choses qui sont maintenant dans les Program Options dans les options du projet. Elles ont été déplacées parce que ce sont des réglages globaux et doivent donc être les mêmes pour tous les fichiers source, pas seulement le premier.

Mais proposer et implémenter un autre format plus flexible (en prenant l'inspiration sur des patterns connus dans les vrais IDEs), on peut

Comme ça votre fork serait incompatible avec TIGCC.

Malheureusement, les membres de la TIGCC Team n'ont pas fait dès l'origine ce qui est pourtant un truc basique de génie logiciel (le versionnement des formats de fichiers...), que font nombre de vrais IDEs (entre autres)...

C'est parce qu'une seule version fonctionne très bien. Les fichiers .c ne sont pas versionnés non plus. Les EDIs gèrent sans problèmes les anciens projets, les valeurs par défaut quand ils chargent un TPR sont telles que ça fonctionne, elles sont volontairement différentes des valeurs par défaut pour les nouveaux projets (chose que la ligne de commande ne peut pas faire et la raison pour laquelle je dis de ne pas compiler avec tigcc en ligne de commande).

Je pense que la vraie solution, et ce qui est vraiment demandé ici, ce serait de modifier tprbuilder pour qu'il gère les dossiers virtuels. (Le fait qu'il nécessite que dossiers virtuels == dossiers physiques est une limitation connue.) Le problème est que ça nécessiterait de compiler dans un dossier temporaire comme le font les EDIs, on ne pourrait plus simplement invoquer tigcc. Mais ça correspondrait vraiment à ce qui est demandé, changer le format TPR ne serait qu'une tentative de contouner cette limitation de tprbuilder (en l'imposant aussi aux EDIs?). Je vois 3 solutions pour implémenter ça:
* compiler toujours dans un répertoire temporaire, comme les EDIs,
* proposer une option qui permet de choisir si on compile dans un répertoire temporaire ou dans le répertoire courant,
* détecter automatiquement si les chemins virtuels et physiques correspondent et choisir le mode de compilation en conséquence.
Je ne suis pas sûr laquelle est la meilleure.

Même s'il se trouvait que TIGCC IDE ET KTIGCC ne se comportent pas mal en présence d'infos non prévues (je n'ai pas regardé), on est à peu près obligés de faire un nouveau format, puisqu'on ne peut pas faire confiance à certain pour ne pas être embêtés dans le futur par des changements intentionnels de comportement.

...

Folco (./16) :
=> ajout de raccourcis claviers pour les outils définis dans le menu Outils (ben oui ). Je compile en effet mes projets en deux parties, loader + main part, j'ai donc deux compilations (ou plus) pour un seul projet, puis un package avec d'autres fichiers en plus pour suivre le standard des pack archives proposé par PpHd.Avec un projet simple, il y a F9 qui fait ça, mais dans mon cas, je dois reprendre la souris pour exécuter mes scripts. Ya moyen ?

Oui, mais pas avant KTIGCC 3 (cf. ./17).

=> permettre d'adresse VTI en ligne de commande (c'est peut-être pas possible directement), mais un wrapper pour la fonction d'envoi à VTI est peut-être possible ? genre fonction ("./ce_prog") pour faire ce que ferait l'IDE si je compilais le projet "ce_prog". En script, on appellerait "nom_du_script mon_prog" et le wrapper s'en démerderait. Parce qu'à cause de mes programmes, je peux pas envoyer directement à un ému.

Et le rapport avec TIGCC? De plus VTI est un mauvais choix pour ça parce qu'il n'a pas d'interface IPC. Avec TiEmu, le suivant marche (si tu as une version compilée avec D-Bus activé, comme les paquetages Fedora):

#!/bin/bash
if qdbus | grep "^ *org.ticalc.lpg.tiemu.TiEmuDBus" > /dev/null ; then
    :
else
    tiemu &
    qdbus | grep "^ *org.ticalc.lpg.tiemu.TiEmuDBus" > /dev/null
fi
while [ $? -ne 0 ] ; do
    sleep 1
    qdbus | grep "^ *org.ticalc.lpg.tiemu.TiEmuDBus" > /dev/null
done
READY=`qdbus org.ticalc.lpg.tiemu.TiEmuDBus /org/ticalc/lpg/tiemu/TiEmuDBus ready_for_transfers`
if [ $? -ne 0 ] ; then
    echo 'error: ready_for_tranfers failed'
    exit 1
fi
while [ "$READY" == "false" ] ; do
    sleep 1
    READY=`qdbus org.ticalc.lpg.tiemu.TiEmuDBus /org/ticalc/lpg/tiemu/TiEmuDBus ready_for_transfers`
    if [ $? -ne 0 ] ; then
        echo 'error: ready_for_tranfers failed'
        exit 1
    fi
done
while [ -n "$1" ] ; do
    case "$1" in
      *.89[a-z]|*.9[2x][a-z]|*.v2[a-z])
        SUCCESS=`qdbus org.ticalc.lpg.tiemu.TiEmuDBus /org/ticalc/lpg/tiemu/TiEmuDBus send_file "$1"`
        if [ $? -ne 0 -o "$SUCCESS" == "false" ] ; then
            echo 'error: send_file failed'
            exit 1
        fi
        ;;
      *)
        SUCCESS=`qdbus org.ticalc.lpg.tiemu.TiEmuDBus /org/ticalc/lpg/tiemu/TiEmuDBus execute_command "$1"`
        if [ $? -ne 0 -o "$SUCCESS" == "false" ] ; then
            echo 'error: execute_command failed'
            exit 1
        fi
        ;;
    esac
    shift
done
exit 0

Usage:
./tiemudbus.sh tigcc-projects/bgammon/bgammon.89[yz] 'bgammon()'

=> auto-complétion pour l'asm à partir des labels définis en début de ligne. J'y goute dans Kate, on s'en passe plus (surtout pour les noms façon _ReturnTableHandlePtr_Loop_End_, bonjour les fautes de typo régulièrement).

Possible, mais pas avant KTIGCC 3 (cf. ./17).

c'est à dire: pas avant 2042.

Bah, si vous m'aidiez au lieu de perdre votre temps à dupliquer les efforts et à implémenter des "fonctionnalités" inutiles comme le support pour VTI et au lieu de me provoquer sur les forums pour me faire perdre mon temps, ça avancerait plus vite.

ben oui mais tu fais le dictateur et tu veux jamais prendre en compte l'avis de tes client utilisateurs

Même s'il se trouvait que TIGCC IDE ET KTIGCC ne se comportent pas mal en présence d'infos non prévues (je n'ai pas regardé), on est à peu près obligés de faire un nouveau format, puisqu'on ne peut pas faire confiance à certain pour ne pas être embêtés dans le futur par des changements intentionnels de comportement.

...

Bah, oui, on ne peut pas te faire confiance. Ca ne te plaît peut-être pas qu'on le dise, mais avec tes antécédents (en menaces ou en actes - heureusement, tu parles beaucoup plus que tu n'agis), ça serait risqué pour nous de te faire confiance, désolé.
Voir les épisodes "je peux très bien empoisonner des identificateurs utilisés dans ExtGraph", ou un morceau de http://tichessteamhq.yuku.com/reply/32899/t/IDE-with-VTI-AND-TIEmu-support-.html#reply-32899 :

And what did you do to that bitmap? (You didn't even explain the change, for all I know you could have replaced it with anal pr0n.)

(quel mépris... et puis il faut vraiment être un pervers, en plus, pour avoir 1) pensé à un truc pareil et 2) avoir osé l'écrire...)

ouais mais bon les attaques personnelles on les ignore, inutile d'y répondre avec d'autres AP...

Et n'oublie pas que toute fonctionnalité à l'EDI doit être implémentée au moins 3 fois [...]

En première intention, penses-tu qu'il soit efficace pour nous, qui avons nous aussi un manpower limité (quoique moins que le tien...), de s'amuser à consacrer beaucoup d'énergie à autre chose que l'IDE Delphi, qui est quand même BEAUCOUP plus utilisé que tous les KTIGCC réunis, parce que Windows est BEAUCOUP plus utilisé que tous les Linux réunis (même si on ajoutait les chiffres de MacOS X, ça resterait vrai, mais c'est suffisamment merdique d'installer TIGCC sur MacOS X pour qu'il n'y ait pas un monde énorme qui le fasse, j'ai l'impression) ?

(Le fait qu'il nécessite que dossiers virtuels == dossiers physiques est une limitation connue.)

Un certain nombre d'entre nous, nous plaignons depuis des années du comportement de l'IDE, qui permet que dossiers virtuels != dossiers physiques. Cela ne nous paraît pas naturel du tout, ce n'est pas comme cela que font nombre d'autres systèmes de build...
Nous aurions donc tendance à formuler cette phrase, qui est consacrée à tprbuilder, en remplaçant "limitation" par "feature"...

Je vois 3 solutions pour implémenter ça:
* compiler toujours dans un répertoire temporaire, comme les EDIs,
* proposer une option qui permet de choisir si on compile dans un répertoire temporaire ou dans le répertoire courant, * détecter automatiquement si les chemins virtuels et physiques correspondent et choisir le mode de compilation en conséquence.

La solution 1 est clairement inapplicable parce qu'elle casse la compatibilité antérieure de certains projets faits avec tprbuilder (au moins ExtGraph).
La solution 3 est plus transparente pour l'utilisateur, mais continue à cacher des choses à l'utilisateur... pas trop fan de cette solution.
=> Pour moi, proposer dans l'IDE l'option de compiler dans un répertoire temporaire (solution 2), bien évidemment désactivée par défaut (pour garder la compatibilité avec le comportement actuel de l'IDE) serait la meilleure de ces trois-là.
Peut-être y a-t-il au moins une autre solution, mais je n'en vois pas actuellement.

[EDIT: une phôte de franssé...]

Lionel Debroux (./22) :
(quel mépris... et puis il faut vraiment être un pervers, en plus, pour avoir 1) pensé à un truc pareil et 2) avoir osé l'écrire...)

Non, juste un habitué de Slashdot...

Et puis il faut être un homophobe pour traîter le sexe anal de "pervers".

vous pouvez jeter vos attaques perso à la poubelle? ça pollue les features de tigcc.

mais c'est suffisamment merdique d'installer TIGCC sur MacOS X

C'est merdique je confirme :/

Obligé de tout recompiler (ou presque) a la main aucune distrib binaire aucun reel support d'un IDE etc... (et compiler TIGCC est une vrai horreur...)

Kevin Kofler (./17) :
C'est parce qu'une seule version fonctionne très bien. Les fichiers .c ne sont pas versionnés non plus.

Et tu trouves que c'est une bonne chose ?

ça a surtout rien à voir.

Lionel Debroux (./24) :
En première intention, penses-tu qu'il soit efficace pour nous, qui avons nous aussi un manpower limité (quoique moins que le tien...), de s'amuser à consacrer beaucoup d'énergie à autre chose que l'IDE Delphi, qui est quand même BEAUCOUP plus utilisé que tous les KTIGCC réunis, parce que Windows est BEAUCOUP plus utilisé que tous les Linux réunis (même si on ajoutait les chiffres de MacOS X, ça resterait vrai, mais c'est suffisamment merdique d'installer TIGCC sur MacOS X pour qu'il n'y ait pas un monde énorme qui le fasse, j'ai l'impression) ?

Donc votre fork sera monoplateforme? Vous faites vraiment tout pour dégrader la qualité de ce qui était TIGCC avant de passer sous votre bulldozer.

Un certain nombre d'entre nous, nous plaignons depuis des années du comportement de l'IDE, qui permet que dossiers virtuels != dossiers physiques. Cela ne nous paraît pas naturel du tout, ce n'est pas comme cela que font nombre d'autres systèmes de build...Nous aurions donc tendance à formuler cette phrase, qui est consacrée à tprbuilder, en remplaçant "limitation" par "feature"...

Ce n'est pas une fonctionnalité d'interdire quelque chose. Personne ne t'oblige à utiliser des dossiers physiques et virtuels qui ne correspondent pas.

Je vois 3 solutions pour implémenter ça:
* compiler toujours dans un répertoire temporaire, comme les EDIs,
* proposer une option qui permet de choisir si on compile dans un répertoire temporaire ou dans le répertoire courant,* détecter automatiquement si les chemins virtuels et physiques correspondent et choisir le mode de compilation en conséquence.

La solution 1 est clairement inapplicable parce qu'elle casse la compatibilité antérieure de certains projets faits avec tprbuilder (au moins ExtGraph).

Argument non valable, les projets TPR sont avant tous des projets pour les EDIs, si tu fais un projet qui ne marche qu'avec tprbuilder, c'est ton problème, ce n'est pas documenté donc pas supporté.

À toi de corriger ton projet pour que la structure des dossiers du projet corresponde à la structure physique (ou alors de modifier les #include pour correspondre à la structure virtuelle, mais ça rendrait le projet incompatible avec la version actuelle du tprbuilder) et tous les fichiers nécessaires pour la compilation soient référencés dans le projet (un projet qui ne satisfait pas ça n'est pas un fichier .tpr valide).

Et à mon avis, il n'y a pas beaucoup de projets dans ce cas.

=> Pour moi
, proposer dans l'IDE l'option de compiler dans un répertoire temporaire (solution 2), bien évidemment désactivée par défaut (pour garder la compatibilité avec le comportement actuel de l'IDE)

Je pense au contraire de rendre le dossier temporaire le choix par défaut, parce que tprbuilder est censé être compatible avec les EDIs, le comportement actuel de tprbuilder est une limitation technique à corriger, et les projets bogués comme ExtGraph pourraient utiliser l'option.

Cela dit, je ne sais pas s'il vaut le coup de maintenir les 2 modes juste pour faire marcher ExtGraph. Un fichier .tpr qui ne fonctionne pas avec les EDIs n'est pas un fichier .tpr valide.

@Godzil: KTIGCC 1 peut être compilé sous OS X. Si tu veux une version Qt/Mac native (KDE 4), tu peux m'aider avec KTIGCC 2 (ou 3, mais si j'ai un patch pour la compatibilité avec OS X avant la release 2.00 et s'il ne casse rien sous GNU/Linux, je veux bien le merger).

Flanker (./28) :

Kevin Kofler (./17) :
C'est parce qu'une seule version fonctionne très bien. Les fichiers .c ne sont pas versionnés non plus.

Et tu trouves que c'est une bonne chose ?

OK, à la demande de Flanker, dans la prochaine version, tout fichier .c doit porter une déclaration de la forme:

#pragma TIGCC ISO_C99
#pragma TIGCC USE_GNU_EXTENSIONS
#pragma TIGCC USE_TIGCC_EXTENSIONS

sinon il sera refusé.
(Je plaisante évidemment. )