kdewin foutage de geule - Page 5

Bah en même temps, ces vilains utilisateurs d'OS propriétaires sont vilains parce qu'ils utilisent un OS propriétaire et non libre au lieu de choisir un OS libre qui faciliterait la vie des développeurs parce qu'au moins ces vilains utilisateurs feraient comme eux...

Un peu comme Apple qui fait une version aux petits oignons d'Itunes sur Mac et qui ressemble à un blob multiforme sous Windows...

[cross avec Lionel]

bon je crois qu'on a tous compris, pas la peine d'insister...

---

Kevin Kofler (./98) :
LOL squalyl, tu oses comparer WinAMP à Amarok?

Bon ben prends foobar2000 alors. Il est juste incomparable avec Amarok... d'ailleurs ça me manque vraiment un équivalent sous Linux, je suis même obligé d'émuler foobar2000 via Wine pour pouvoir lire qqes uns de mes formats audio
(pour le reste j'essaye d'éviter vu que les applis Wine ne sont pas bien intégrés, notamment les hotkeys globales ne sont pas supportées, et Wine ne passe pas les "media keys" donc pas pratique pour changer de musique en bossant)

De toute façon, même un programme Qt-only packagé proprement passe obligatoirement par le kdewin-installer. Tu veux que le binaire de Qt vienne d'où sinon? Trolltech ne fait que des paquetages développeur avec tout dedans, même les sources, ces paquetages sont énormes et pas du tout prévus comme un environnement runtime, il n'y a que le projet kde-windows qui fait un paquetage qt-*-bin.tar.bz2 avec seulement la partie runtime. Donc à moins de livrer une copie de toutes les DLLs avec le programme ( vive la DLL Hell! De plus, Qt étant sous GPL, il faut aussi redistribuer les sources de Qt si on fait ça), les binaires du projet kde-windows sont la seule solution pratique.

Vous avez soulevé en gros 3 problèmes avec kde-windows:
* l'installeur est bogué - ça va se résoudre avec le temps!
* le portage de KDE lui-même est bogué - ça aussi!
* c'est soi-disant trop gros à télécharger - je ne vois pas en quoi c'est un problème à l'heure actuelle où les gens streament des GOs de vidéos sur des sites comme YouTube. Nous ne sommes plus en 1990, de nos jours, 200 MO, ce n'est rien! OpenOffice.org fait plus de 100 MO et ça n'empêche pas que c'est un téléchargement très populaire.

Ton DLL Hell me fait bien rigoler comparé à l'installation de kdewin et GTK+... Pour arriver à un truc qui marche moins bien qu'avant à l'arrivée. Donc tes slogants militanto-marketting, tu peux les garder.

Et TU ne vois pas... Saches que des PC déconnectés, ça existe encore, des quotas, ça existe encore, des petits débits, ça existe encore, des petites configurations, ça existe encore aussi. Bref, une fois de plus, tu vois tout de ton point de vue plutôt que de penser aux utilisateurs.

Tiens à partir de maintenant je vais parler du GTK+Hell et du Kdewin-Hell

sinon désolé mais les fonctionnalités d'une suite bureautique, je veux bien qu'elles prennent 100 Mo, mais pas un EDI.

(je ne sais pas si ça a été cité ici, mais perso j'utilise Scite (scintilla text editor), quand j'ai besoin de faire un peu de code rapidement)

Ben en même temps, il dit privilégier la version pour linux. Dans ce cas, il vaut mieux s'y donner à fond. Je ne vois pas pourquoi il devrait rendre l'IDE laide et peu pratique sur les 2 OS si il y a moyen de la rendre parfait sur l'un et laide/peu pratique seulement sur l'autre.

J'utilise également SciTE pour le boulot et un certain nombre de programmes de TICT, même si certaines opérations (effacement en mode bloc, par exemple) sont très lentes

J'utilise très peu KTIGCC, parce qu'il ne convient pas du tout à l'usage que j'en fais:
* la philosophie '1 projet = 1 compilation d'1 programme' est affreuse quand il y a beaucoup de programmes (ExtGraph: actuellement 33 demos + 1 autre programme de test, ça va encore augmenter);
* les TPRs ne savent pas gérer _simplement_ (je veux dire: plusieurs TPRs pour faire des function archives et linker le tout ensemble, c'est n'importe quoi ) la compilation de plusieurs parties compilées avec des options différentes (TI-Chess);
* les TPRs ne sont pas faits pour les programmes incompatibles on-calc (tous);
* les TPRs ne sont pas faits pour les programmes avec plusieurs langues (TI-Chess, TICT-Explorer).

Je ne peux même pas utiliser le transfert automatique vers TIEmu pour le programme de test d'ExtGraph: j'utilise le mode verbose pour avoir les infos quand je compile avec tprbuilder, et ce mode n'est pas géré par KTIGCC.

tu attendrais quoi, en fait?

tiens, rien à voir, mais pourquoi n'y a t il pas de binaire pour ld-tigcc sous windows?

./131: sous Windows, c'est pas une DLL ?

./130:
* pour le premier défaut des TPR que j'ai cité, je ne vois pas trop ce qui pourrait être fait pour améliorer ça: les scripts sont plus faciles à maintenir et utiliser...
* pour le deuxième, il faudrait pouvoir séparer les options globales du projet et les options d'optimisation (comme le font nombre de programmes basés sur les GNU autotools)
* pour le troisième et le quatrième, des scripts / batchfiles font évidemment ça super bien, mais un 'batch mode' pourrait être implémenté à l'IDE.

!! les projets simples en C se compilent très bien avec code blocks !!

je suis en train de travailler sur la compilation d'Extgraph avec cet IDE. ça devrait pas être trop dur.

La compilation d'ExtGraph, comme celle de la plupart des programes de TICT, est scriptée. Mais ExtGraph est une des compilations les moins triviales pour un IDE:
* il y a la partie extgraph.tpr / TileMap.tpr, et la partie qui est dans buildlib/buildlib.bat;
* la partie dans buildlib/buildlib.bat ne touche qu'extgraph.a;
* dans buildlib/buildlib.bat, il y a des options de compilation différentes de celles d'extgraph.tpr, et pas les mêmes options de compilation pour tous les fichiers.

ça ne lui pose aucun problème. On peut choisir la commande de build par fichier.

pour le moment j'ai fait ça:
http://www.mirari.fr/oacA?a=open

en fait ça y est, j'ai séparé le build du tilemap engine et de la lib principale dans le même projet.
Je connais pas les options de compil par fichier, mais si tu veux, je t'envoie le projet et tu le customises

En fait, je ne builde le tilemap engine que quand je le change... ce qui n'est jamais arrivé depuis le 2005/08/12, date de la création d'un repository SVN => ça ne me paraît pas utile de le mettre dans le processus de build
Les options de compil sont les mêmes pour tous les fichiers d'extgraph.tpr (feature/limitation du TPR), c'est à dire plus de 90% des fichiers que contient extgraph.tpr. Les autres sont dans buildlib/buildlib.bat. Donc ce qu'il faut (et tu dis que code::blocks le fait), c'est un jeu d'options globales, et des overrides par fichier.

Je veux bien que tu m'envoies le projet Code::blocks, mais je ne peux pas l'utiliser tout de suite: je n'ai jamais utilisé cet IDE, et je n'utilise pas une distro pour laquelle ils font des packages précompilés, donc il faut que je me le compile...
Un truc qui m'embête un peu dans ta trace, c'est le temps de build: 1 minutes, 12 seconds. Certes, tu as mis '-g' dans les options, tu utilises un OS où la création des processus est plus lente, et j'imagine que tu as une machine moins puissante que la mienne... mais ça reste quand même 5 à 6 fois plus long que ce que j'obtiens avec buildentirelib.
Je ne peux pas utiliser ça en utilisation normale
[EDIT: hmm, il faut wx 2.8 pour compiler ça, qui n'est pas dans les packages de ma distro non plus...]

Kevin Kofler (./124) :
De toute façon, même un programme Qt-only packagé proprement passe obligatoirement par le kdewin-installer. Tu veux que le binaire de Qt vienne d'où sinon? Trolltech ne fait que des paquetages développeur avec tout dedans, même les sources, ces paquetages sont énormes et pas du tout prévus comme un environnement runtime, il n'y a que le projet kde-windows qui fait un paquetage qt-*-bin.tar.bz2 avec seulement la partie runtime. Donc à moins de livrer une copie de toutes les DLLs avec le programme ( vive la DLL Hell! De plus, Qt étant sous GPL, il faut aussi redistribuer les sources de Qt si on fait ça), les binaires du projet kde-windows sont la seule solution pratique.

Non on peut lier statiquement, ça fait un exécutable de genre 3 Mo (bon après je pense que ça dépend des fonctions vraiment utilisées). Je sais pas si tu te rends compte, mais il faudrait avoir 60 programmes utilisant Qt pour atteindre 200 Mo

(à titre de comparaison, sur TI même si le kernel ne permettait d'économiser que 600 octets par programme il en faudrait bien moins pour justifier la présence de preos+stdlib ^^)

Le linking statique, c'est mal
(Nan, sérieusement: sur PC/Mac, ça sux pour la sécurité.)

lionel: je suis sous winxp sp2 avec un P4 3 GHz / 1 Go de ram
le compilateur est le tigcc officiel 0.96 beta 8 / win32
il est appelé directement par l'IDE.

le compilateur doit être configuré en ajoutant le xml suivant dans le default.conf (ajuste les chemins pour ton environnement) car le compilo n'est pas dans le jeu par défaut des compilateurs.

<compiler>...

		<user_sets>
			<tigcc>
				<NAME>
					<str>
						<![CDATA[TIGCC]]>
					</str>
				</NAME>
				<PARENT>
					<str>
						<![CDATA[gcc]]>
					</str>
				</PARENT>
				<INCLUDE_DIRS>
					<str>
						<![CDATA[C:\Program Files\TIGCC\Include;]]>
					</str>
				</INCLUDE_DIRS>
				<LIBRARY_DIRS>
					<str>
						<![CDATA[C:\Program Files\TIGCC\Lib;]]>
					</str>
				</LIBRARY_DIRS>
				<LIBRARIES>
					<str>
						<![CDATA[C:\Program Files\TIGCC\Lib\tigcc.a;]]>
					</str>
				</LIBRARIES>
				<MASTER_PATH>
					<str>
						<![CDATA[C:\Program Files\TIGCC]]>
					</str>
				</MASTER_PATH>
				<EXTRA_PATHS>
					<str>
						<![CDATA[C:\Program Files\TIGCC;]]>
					</str>
				</EXTRA_PATHS>
				<C_COMPILER>
					<str>
						<![CDATA[tigcc.exe]]>
					</str>
				</C_COMPILER>
				<CPP_COMPILER>
					<str>
						<![CDATA[tigcc.exe]]>
					</str>
				</CPP_COMPILER>
				<LINKER>
					<str>
						<![CDATA[tigcc.exe]]>
					</str>
				</LINKER>
				<LIB_LINKER>
					<str>
						<![CDATA[tigcc.exe]]>
					</str>
				</LIB_LINKER>
<macros>
					<compile_single_file_to_object_file>
						<tool1>
							<COMMAND>
								<str>
									<![CDATA[$compiler $options $includes -Wa,$includes -c $file -o $object]]>
								</str>
							</COMMAND>
							<EXTENSIONS>
								<astr>
									<s>
										<![CDATA[s]]>
									</s>
								</astr>
							</EXTENSIONS>
							<GENERATEDFILES>
								<astr />
							</GENERATEDFILES>
						</tool1>
					</compile_single_file_to_object_file>
					<link_object_files_to_static_library>
						<tool0>
							<COMMAND>
								<str>
									<![CDATA[$lib_linker -ar -n $exe_name -o $static_output $link_objects]]>
								</str>
							</COMMAND>
							<EXTENSIONS>
								<astr />
							</EXTENSIONS>
							<GENERATEDFILES>
								<astr />
							</GENERATEDFILES>
						</tool0>
					</link_object_files_to_static_library>
				</macros>
				<switches>
					<LOGGING int="0" />
				</switches>
			</tigcc>
		</user_sets>

</compiler>

Mmm, du bon XML
On dirait Maven...

J'ai installé les packages wx 2.8 à partir du repository officiel, mais même après avoir relancé le script de bootstrap des autotools, Code::blocks ne veut pas détecter wx 2.8.x
[EDIT: quand on prend la version stable plutôt que la version SVN, ça fonctionne.]

sinon te fais pas chier, c'est juste un proof of concept pour prouver qu'on peut utiliser TIGCC avec autre chose que TIGCC IDE

Lionel Debroux (./138) :
(Nan, sérieusement: sur PC/Mac, ça sux pour la sécurité.)

- les failles de sécurité potentielles sur un éditeur de fichier textes sont quand même limitées, c'est pas comme si c'était connecté à internet ou que ça lisait des images externes ;

- de toute façon actuellement sous Windows le support des mises à jours de sécurité pour les libs genre GTK+ est désastreux : il faut à la fois être au courant qu'on a GTK+ (pas du tout évident si c'est installé par un programme genre Tiemu sans qu'on y fasse attention), suivre les mises à jour de sécurité de GTK+, et les installer (sachant que seule une partie ridiculement faible de ces mises à jour de sécurité sera pertinente pour Tiemu, mais à moins de s'y connaître on ne peut pas savoir lesquelles le sont). Autant dire qu'à moindre d'être très sensibilisé aux questions de sécurité aucun utilisateur final ne sera à jour ;

- inversement si c'est linké statiquement et que le mainteneur suit les mises à jour de sécurité, il peut mettre à jour son logiciel pour les rares failles qui l'affecteront et les utilisateurs seront au courant ; et si c'est plus maintenu, la version gratuite de Qt imposant au programme d'être compatible GPL n'importe qui peut relinker avec la nouvelle version...

Bref, je crois pas que ça soit une si mauvaise idée que ça

proof of concept pour prouver qu'on peut utiliser TIGCC avec autre chose que TIGCC IDE

@Pollux: certes, bien vu...

Lionel Debroux (./120) :

Une fois de plus, il n'y a pour moi aucune raison de coder en Qt-only, les libs KDE sont là pour être utilisées! Coder en Qt-only = coder une application mal intégrée à KDE et réinventer la roue pour tout ce qui est dans KDE. Bref, ces "utilisateurs de Qt" n'ont qu'à utiliser les kdelibs.

Je n'ai pas de wishlist particulière, je veux toute la flexibilité offerte par KDE, un point c'est tout. Je ne comprends pas pourquoi tu t'obstines à ne pas comprendre.

Déconnexion développeur/utilisateurs, quand tu nous tiens... Enfin bon, c'est pas une nouveauté pour nous que tu n'es pas à l'écoute de tes utilisateurs...

Tant que kdewin ne marchera pas mieux et ne sera pas plus léger, il ne deviendra pas un toolkit de choix. Un point c'est tout. Sauf pour quelques développeurs obtus, évidemment.

Sous Windows, il existe différents frameworks comme MFC, ATL, WTL qui servent d'interface avec win32 et sont donc très légers (juste une ou deux DLL) et offrent quasiment tout ce dont le codeur peut rêver

Kochise

squalyl (./131) :
tiens, rien à voir, mais pourquoi n'y a t il pas de binaire pour ld-tigcc sous windows?

Lionel Debroux (./132) :
./131: sous Windows, c'est pas une DLL ?

Effectivement. Si tu appelles ld-tigcc directement, c'est une erreur grave dans ton script de compilation, il faut passer par tigcc pour toutes les opérations de compilation en ligne de commande.

Lionel Debroux (./129) :
* la philosophie '1 projet = 1 compilation d'1 programme' est affreuse quand il y a beaucoup de programmes (ExtGraph: actuellement 33 demos + 1 autre programme de test, ça va encore augmenter);

Ben, il suffit de ne recompiler que quand c'est nécessaire, ça ne sert à rien de recompiler les 33 démos à chaque fois! Et en tout cas:

Lionel Debroux (./132) :
* pour le premier défaut des TPR que j'ai cité, je ne vois pas trop ce qui pourrait être fait pour améliorer ça: les scripts sont plus faciles à maintenir et utiliser...

Il faudrait tout simplement une gestion de groupes de projets.

* les TPRs ne savent pas gérer _simplement_ (je veux dire: plusieurs TPRs pour faire des function archives et linker le tout ensemble, c'est n'importe quoi ) la compilation de plusieurs parties compilées avec des options différentes (TI-Chess);

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

* les TPRs ne sont pas faits pour les programmes incompatibles on-calc (tous);

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

* les TPRs ne sont pas faits pour les programmes avec plusieurs langues (TI-Chess, TICT-Explorer).

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

j'utilise le mode verbose pour avoir les infos quand je compile avec tprbuilder, et ce mode n'est pas géré par KTIGCC.

Tu parles de quelles infos? Les stats sorties par ld-tigcc. Je te signale que si tu actives "Display message after successful compilation" dans les options de KTIGCC, tu as toutes ces stats dans une boîte de dialogue.

Pollux (./137) :
Non on peut lier statiquement, ça fait un exécutable de genre 3 Mo (bon après je pense que ça dépend des fonctions vraiment utilisées).

Il faut un Qt compilé spécialement pour ça, je ne vois de qt-mingw-static précompilé nulle part (le projet kde-windows a juste un qt-msvc-static utilisé pour leur installeur, et pas à jour en plus (4.3.2, ils s'en foutent parce que c'est suffisant pour leur installeur et Qt statique ne sert nulle part ailleurs, tout le reste utilise le Qt dynamique partagé)). Et on perd les plugins avec ça, donc tout est soit à compiler directement dans Qt, et donc au final dans l'exécutable, soit à désactiver (donc perte de fonctionnalité). Quant à KDE, le linkage statique n'est pas du tout géré, ils utilisent des plugins obligatoirement et il y a aussi d'autres fichiers externes (icônes notamment).

squalyl (./141) :
sinon te fais pas chier, c'est juste un proof of concept pour prouver qu'on peut utiliser TIGCC avec autre chose que TIGCC IDE

Et tu perds:
* des switches par défaut raisonnables pour les nouveaux projets!!! Rien que pour ça, je déconseille totalement l'utilisation de la ligne de commande ou d'un EDI autre que TIGCC IDE ou KTIGCC: nos EDIs savent ce qu'est un nouveau projet et ce qui est un ancien projet réouvert, et ils appliquent automatiquement les options fortement conseillées (lire: si vous n'avez pas une très bonne raison de ne pas les mettre, c'est un bogue de ne pas les mettre!) pour les nouveaux projets. La ligne de commande est obligée de présupposer que tous les projets pourraient être d'anciens projets et donc garder la compatibilité antérieure, ce qui fait que les réglages par défaut sont totalement inutilisables et qu'il faut passer au minimum (sauf exceptions justifiées) -Os -ffunction-sections -fdata-sections --optimize-code --cut-ranges --reorder-sections --merge-constants --remove-unused -Wall -Wextra -Wwrite-strings. L'EDI met aussi le MIN_AMS par défaut à 100 pour les nouveaux projets (optimal parce que ça ne nécessite pas de détection de la version minimale), pour les anciens projets et donc aussi en ligne de commande, le MIN_AMS par défaut est 101 pour des raisons de compatibilité.
* un EDI adapté à la tâche, qui présente toutes les fonctions utiles pour la programmation avec TIGCC (comme les dialogues des options du projet avec les options de TIGCCLIB, la complétion qui connaît les fonctions de TIGCCLIB etc.), et qui ne présente pas des fonctionnalités qui n'ont rien à voir, genre tout ce qui est spécifique au C++.
* l'intégration avec TiEmu et son débogueur C.
Bref, je ne comprends pas du tout cette manie de vouloir à tout prix utiliser autre chose que les EDIs que nous proposons. TIGCC est une solution complète, l'EDI en fait partie intégrante. Le compilateur en ligne de commande n'existe que pour la compatibilité avec les anciens projets, je déconseille absolument l'utilisation (même indirectement à travers un EDI qui n'est pas celui de TIGCC) pour tout nouveau projet. (Et attention, ça ne veut pas dire qu'il faut appeler les composants directement, ce n'est pas du tout supporté, ça crée des problèmes de portabilité (cf. ld-tigcc qui n'existe pas en tant qu'exécutable sous W32) et les composants peuvent changer à tout moment sans avertissement. tigcc et tprbuilder sont les seules interfaces documentées pour la ligne de commande.)

Pollux (./142) :
- inversement si c'est linké statiquement et que le mainteneur suit les mises à jour de sécurité, il peut mettre à jour son logiciel pour les rares failles qui l'affecteront et les utilisateurs seront au courant

Si c'est linké dynamiquement, il peut demander une version minimale de la lib qui corrige la faille dans une mise à jour de l'application, et si la version est trop ancienne, relancer l'installeur de la lib (comme quand la lib est entièrement manquante). Donc ça marche tout aussi bien que dans le cas statique et toutes les autres applications qui partagent la même lib seront donc corrigées en même temps.

On n'est pas sur TI où un logiciel n'a aucun moyen de télécharger une lib mise à jour (le gros problème des libs dynamiques sur TI, il n'y a aucun moyen de résoudre les dépendances automatiquement).

Kochise (./144) :
Sous Windows, il existe différents frameworks comme MFC, ATL, WTL qui servent d'interface avec win32 et sont donc très légers (juste une ou deux DLL) et offrent quasiment tout ce dont le codeur peut rêver

Ces frameworks sont propriétaires et monoplateforme, donc totalement inexploitables pour une application multiplateforme (à moins de coder des frontends différents pour chaque plateforme, ce qui n'est pas maintenable à long terme, Romain en a fait l'expérience avec TiLP). De plus, ils ne fonctionnent pas avec MinGW, donc ils sont aussi inexploitables pour la cross-compilation.

Sauf si on atteint la limite où :

_
> tps_coding_frontend < tps_coding_FWmultiplateforme

Kevin Kofler (./146) :
* des switches par défaut raisonnables pour les nouveaux projets!!! Rien que pour ça, je déconseille totalement l'utilisation de la ligne de commande ou d'un EDI autre que TIGCC IDE ou KTIGCC: nos EDIs savent ce qu'est un nouveau projet et ce qui est un ancien projet réouvert, et ils appliquent automatiquement les options fortement conseillées (lire: si vous n'avez pas une très bonne raison de ne pas les mettre, c'est un bogue de ne pas les mettre!) pour les nouveaux projets.

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éé
tu attaques sans savoir, as tu au moins touché une fois CodeBlocks?

Kevin Kofler (./146) :
Bref, je ne comprends pas du tout cette manie de vouloir à tout prix utiliser autre chose que les EDIs que nous proposons.

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...

Kevin Kofler (./146) :
(cf. ld-tigcc qui n'existe pas en tant qu'exécutable sous W32)

C'est honnêtement et sans troller honteux, je vois pas pourquoi on peut pas avoir de programme de link séparé alors que les autres (a68k,as,gcc), le sont. Qu'est ce que c'est que ce truc de filer une DLL comme binaire? Tu veux pas mettre gcc en DLL tant que t'y es? Et puis je pensais que tu pestais contre le DLL Hell, comment oses tu y participer?
C'est de plus une manipulation pour nous obliger à utiliser tigcc.exe

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!

squalyl (./148) :
C'est honnêtement et sans troller honteux, je vois pas pourquoi on peut pas avoir de programme de link séparé alors que les autres (a68k,as,gcc), le sont. Qu'est ce que c'est que ce truc de filer une DLL comme binaire? Tu veux pas mettre gcc en DLL tant que t'y es? Et puis je pensais que tu pestais contre le DLL Hell, comment oses tu y participer?
C'est de plus une manipulation pour nous obliger à utiliser tigcc.exe

Une manipulation ? Je vois pas le problème, tu fais "tigcc machin.o truc.o -o bidule" pour linker... Pareil pour a68k/as/gcc/cpp, normalement tu n'as aucune raison de les appeler séparément -- GNU garde les exécutables séparés plus par souci de compatibilité qu'autre chose.

* la philosophie '1 projet = 1 compilation d'1 programme' est affreuse quand il y a beaucoup de programmes (ExtGraph: actuellement 33 demos + 1 autre programme de test, ça va encore augmenter);

Ben, il suffit de ne recompiler que quand c'est nécessaire, ça ne sert à rien de recompiler les 33 démos à chaque fois!

Evidemment que je ne recompile pas toujours chacune des 33 demos à chaque fois
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

* pour le premier défaut des TPR que j'ai cité, je ne vois pas trop ce qui pourrait être fait pour améliorer ça: les scripts sont plus faciles à maintenir et utiliser...

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

les TPRs ne savent pas gérer _simplement_ (je veux dire: plusieurs TPRs pour faire des function archives et linker le tout ensemble, c'est n'importe quoi ) la compilation de plusieurs parties compilées avec des options différentes (TI-Chess);

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.

* les TPRs ne sont pas faits pour les programmes incompatibles on-calc (tous);

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

* les TPRs ne sont pas faits pour les programmes avec plusieurs langues (TI-Chess, TICT-Explorer).

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.

j'utilise le mode verbose pour avoir les infos quand je compile avec tprbuilder, et ce mode n'est pas géré par KTIGCC.

Tu parles de quelles infos? Les stats sorties par ld-tigcc. Je te signale que si tu actives "Display message after successful compilation" dans les options de KTIGCC, tu as toutes ces stats dans une boîte de dialogue.

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.