squalyl (./148) :
Faux, faux et refaux, on peut faire:
-des options par défaut attachées au compilateur-des projets template pour définir des options par défaut pour chaque nouveau projet créé

Alors fais-le, parce que sinon ton template est limite inutilisable.

tu attaques sans savoir, as tu au moins touché une fois CodeBlocks?

Oui, et c'était bogué à fond, on dirait que c'est un lieu commun des logiciels utilisant wxGTK...

parce qu'il est un peu obsolète et que tu ne veux entendre aucune plainte de tes utilisateurs? On va pas répéter hein...

Obsolète, tu rigoles? Je ne vois rien d'obsolète.
Et il n'est pas vrai que je ne veux entendre aucune plainte de mes utilisateurs, le problème est que vos suggestions demandent des modifications radicales à la structure des EDIs:
* que je n'ai pas le temps de faire maintenant, surtout que je dois d'abord finir KTIGCC 2 (version KDE 4) et ensuite faire la version 3 multiplateforme,
* que je ne peux pas rajouter avant KTIGCC 3 parce que sinon je devrais le coder 2 fois, dont une fois avec un outil de développement auquel je n'ai pas accès (Delphi). (Mais évidemment, si tu es volontaire pour maintenir l'EDI en Delphi jusqu'à ce que KTIGCC 3 soit prêt, on pourra en reparler.)

Qu'est ce que c'est que ce truc de filer une DLL comme binaire?

C'est l'interface utilisée par TIGCC IDE et le tigcc.exe en Delphi, je ne vais pas livrer un exécutable utilisé nulle part! Mais il est fort probable qu'il y aura un ld-tigcc.exe avec KTIGCC 3.

Tu veux pas mettre gcc en DLL tant que t'y es?

Impossible parce que GCC ne libère pas ses allocations, ça leakerait de la mémoire comme pas possible.

Et puis je pensais que tu pestais contre le DLL Hell, comment oses tu y participer?

Ce n'est pas une DLL partagée, ça n'a strictement rien à voir avec du DLL Hell. La seule raison pourquoi c'est une DLL est qu'on ne peut pas statiquement linker du C dans du Delphi.

C'est de plus une manipulation pour nous obliger à utiliser tigcc.exe

Je ne vois pas du tout pourquoi tu veux contourner tigcc.exe à part pour être lourd. tigcc.exe est l'interface documentée, qui continuera à fonctionner même si la chaîne d'outils utilisée en interne change (comme ça a été le cas plusieurs fois dans le passé, on a eu 3 générations de systèmes de linking avant ld-tigcc: link.exe tout seul, GNU ld + link.exe, GNU ld + obj2ti). Et tigcc.exe est dans le PATH système, les outils utilisés en interne ne le sont pas.

et en plus, pourquoi l'option tigcc -ar n'est pas documentée dans tigcc --help? J'ai du observer la sortie de tprbuilder pour deviner cette option!

Je vais voir ce que je peux faire pour tigcc --help dans la version -W32 (la version *nix documente -ar dans tigcc --help, vois-tu maintenant pourquoi je veux me débarasser de toute cette duplication de code?), mais l'option est documentée dans http://tigcc.ticalc.org/doc/comopts.html#SEC3.

Lionel Debroux (./150) :
Mais quand je change de demo (ce que j'ai fait très souvent, ces temps-ci, avec l'augmentation de la couverture de tests), je vais prendre le temps de créer 33 projets pour les demos, alors que ces projets ne contiennent chacun qu'un fichier, que toutes les demos sont compilé avec les mêmes options, etc. ? Ouais, bien sûr

Ben franchement, je ne vois pas pourquoi pas... Tous les 67 exemples de TIGCC ont un fichier .tpr correspondant, et ils sont tous composés d'un seul fichier .c chacun eux aussi.

Il faudrait tout simplement une gestion de groupes de projets.

C'est pas faux, mais ça ne ferait que contourner une grosse limitation de l'outil et ses projets brain-dead qui sont incapables de compiler certains fichiers avec des options différentes (ce dont est capable Code::Blocks). C'est pas une solution à la cause racine du problème

Ce n'est pas du tout le même problème! Compiler avec des options différentes ne va pas magiquement te permettre de compiler plusieurs targets en même temps (par exemple plusieurs démos dans un exécutable séparé chacune), seul un groupe de projets avec un projet pour chaque target peut faire ça.

Solution évidente: arrêter de compiler tout avec des options différentes, TI-Chess compile très bien avec -Os par tout.

Solution évidente... et fausse. Mais tu ne peux manifestement pas comprendre.

Tu ne veux pas faire le moindre sacrifice pour t'adapter aux outils, c'est ça le problème, et c'est bien dommage parce que tu perds tous les avantages de ces outils seulement parce que tu ne peux pas accepter une petite limitation qui n'a aucune importance en pratique.

Solution évidente: rendre les programmes compatibles on-calc.

Solution évidente... et fausse. Antinomique avec le but de solution précédente, aussi. Tes contradictions, comme d'habitude

Tu n'as toujours pas compris que c'est une considération qui n'a strictement rien à voir avec l'optimisation!

Optimisation = gagner en taille ou en temps sans changer les fonctionnalités du programme!

Là, il s'agit de rajouter une fonctionnalité, la possibilité d'exécuter le même programme sur des calculatrices différentes, et il est évident que ça prend de la place, comme n'importe quelle autre fonctionnalité! Avec le concept d'"optimisation" que tu défends là, il faudrait faire tous les jeux en blanc et noir parce que les sprites prennent 2 fois moins de place qu'en niveaux de gris, donc les niveaux de gris ne sont pas du tout "optimisés".

C'est fou qu'avec le nombre de fois que j'essaie te t'expliquer ça, ce ne soit toujours pas rentré!

Solution évidente: faire de la langue un choix en temps d'exécution, pas de compilation (cf. réponse précédente).

Solution évidente... et fausse. Antinomique avec l'optimisation taille. Voir réponse précédente.

"Antinomie" totalement imaginaire. Voir réponse précédente.

Je parle que je compile certains projets avec tprbuilder dans mon terminal, j'ai besoin de cette option -v, parce que sinon je n'ai pas les stats. Et si je veux compiler le même projet, sans me faire ch*** à le modifier à chaque fois, dans KTIGCC, je ne peux pas parce que ton truc d'arrête avant de linker parce qu'il croit que la compilation a généré tout plein d'erreurs.

C'est normal, rajouter -v aux options du compilateur est un hack que je n'avais pas du tout prévu, et c'est absolument la mauvaise solution, pourquoi n'appelles-tu pas tprbuilder avec l'option -v tout simplement?

Faut-il vraiment que je me mette à sortir des erreurs pour tout ce qui n'était pas prévu? Je n'ai vraiment pas envie de me mettre à valider les options de GCC définies dans le .tpr, mais si vous y mettez tout et n'importe quoi, vous allez m'y obliger.