Lionel Debroux (./148) :
Ta philosophie "c'est à l'utilisateur de s'adapter à l'outil", philosophie que tu appliques à TIGCC, n'est pas la vérité universelle absolue... Ne citons que SAP (fabricant de logiciel propriétaire vilain, on sait), qui fait des outils modulaires et assez facilement modelables, et travaille avec ses clients pour faire des outils qui collent au mieux aux besoins des clients.
Mais ce sont des outils pour des entreprises, entreprises qui emploient une équipe entière pour personnaliser leurs logiciels, ce n'est pas pratiquable pour des particuliers.
Autrement dit, tprbuilder est un bug et pas une feature ?
tprbuilder est un outil qui sert à compiler des projets faits avec et pour l'EDI si on n'a pas accès à l'EDI pour une raison ou pour une autre. C'est plutôt obsolescent depuis qu'il y a KTIGCC. Et effectivement, des projets qui ne compilent qu'avec
tprbuilder, ça ne rentre pas du tout dans l'utilisation prévue de l'EDI et je dirais même que ces projets sont bogués.
[Dans ce qui suit, je m'essaie à la critique à la façon Kevin telle qu'on la ressent depuis des années: dénigrer les méthodes, les idées et le travail des autres. J'utilise certaines de ses expressions, marquées en italique.]
Pourquoi ne peux-tu pas argumenter sans ce genre d'attaques personnelles?
Par conséquent, l'usage prévu de l'EDI est donc de créer, maintenir et ouvrir un par un douze projets quand je veux compiler TICT-Explorer. C'est irrésistiblement user-friendly 
Ben non, l'usage prévu de l'EDI est d'avoir un seul projet par programme. Comme tu le remarques correctement plus bas, ça implique la compatibilité on-calc, qui pour moi est indispensable (les calculatrices permettent le transfert entre les différents modèles, ce n'est pas pour que quelqu'un rajoute une limitation arbitraire à un seul modèle). Pour les traductions:
[ul][li]je ne suis pas convaincu qu'il soit utile de traduire un logiciel pour calculatrice - tant que le logiciel n'est pas incompatible avec les versions traduites de AMS, je ne vois pas le problème s'il est seulement en anglais,[/li][li]il y a sans doute des solutions plus maintenables pour les traductions que de recompiler le même binaire 6 fois, par exemple on pourrait utiliser des fichiers de traduction externes.[/li][/ul]
Ta solution avec le script qui appelle
tprbuilder 12 fois oblige à recompiler tout le projet à chaque petite modification, même si elle ne porte que sur un seul fichier .c (chose que justement l'EDI évite et raison pour laquelle
tprbuilder n'est qu'une solution de dernier recours), et pas une fois, mais 12 fois! (Et même si tu rajoutes un mode incrémentel à
tprbuilder, ça ne va pas résoudre ce problème parce qu'il faut tout nettoyer entre tes 12 compilations et tout recompiler avec des options différentes. C'est bien pour ça que l'EDI ne permet pas de compiler les mêmes sources plusieurs fois, et ça ne rentre pas dans les fonctionnalités prévues pour les groupes de projets non plus. C'est tout simplement incompatible avec un modèle de compilation incrémentel.)
Alors même que le mode compilation avec optimisations interprocédurales - déconseillé et non supporté par toi - est inaccessible avec l'IDE, il faut passer par un système de build plus flexible (en fait, appeler directement gcc, patcher et ld-tigcc, parce que tigcc et tprbuilder en sont aussi incapables que l'IDE) si on veut y avoir accès.
Ce mode (qui est d'ailleurs intermodulaire, pas seulement interprocédural) est déconseillé et non supporté parce qu'il ne marche pas de manière fiable (à l'heure actuelle)! Même le GCC 4.1 de Fedora plante facilement avec
--combine. (Je n'ai pas encore essayé ce que ça donne avec le 4.3.) D'ailleurs, dans GCC 4.1, il se limite essentiellement à l'inlining, qui est peu utile dans le cadre de l'optimisation taille.
Le jour où toutes les sources compileront avec
--combine de la même manière que sans (et en particulier sans planter GCC) et où les fonctionnalités proposées seront vraiment intéressantes sera le jour où il sera considéré pour
tigcc (et si ça se passe vraiment sans problèmes,
tigcc pourrait même l'utiliser automatiquement). Mais pour l'EDI, le problème est que
--combine est une fois de plus une fonctionnalité incompatible par principe avec le modèle de compilation incrémentel (raison pour laquelle pratiquement aucun projet de logiciel libre grand public ne l'utilise, parce que ce n'est pas compatible avec le fonctionnement des makefiles non plus, et cela fait que ce mode est peu testé et est par conséquent une des raisons pour lesquelles il est peu fiable).
D'ailleurs, rappelons que patcher est plutôt un hack, et de toute façon une solution de facilité pour implémenter dans les gcc / as de TIGCC des features absentes de gcc / as upstream. La bonne façon de faire, la solution à long terme, serait de modifier correctement gcc et as, même si c'est difficile
Et c'est prévu. Le
patcher existe essentiellement pour des raisons historiques, il ne fait plus grand chose de nos jours, et ce qu'il fait toujours serait mieux fait dans GCC. C'est juste que j'ai eu des choses plus importantes à faire.
et pourquoi pas, de contribuer à upstream une partie de ces modifications-là - après tout, il n'y a probablement pas que sur cette architecture qu'on pourrait avoir envie d'utiliser du reg-relative.)
Impossible à cause de la bureaucratie des copyright assignments de la FSF.
Les overlays à la DOS ou CP/M (entre bien d'autres systèmes) étaient des moyens de s'adapter aux ressources limitées des machines sur lesquelles ces systèmes tournaient, et par là-même, permettre aux utilisateurs de se servir plus à fond du potentiel des machines. Enfin bon, ce que j'en dis...
Oui, mais ça ne sert à rien sur TI pour des programmes de taille inférieure à 64 KO (et dans le cas des programmes de Martial, la taille est largement inférieure à 64 KO), ça complique juste la compilation et crée un overhead de taille important.
Brunni (./149) :
Bon alors sur ce point je ne suis pas d'accord. C'est précisément pour cette raison que je n'utilise pas Eclipse pour le dév amateur par exemple, impossible de créer un projet dans un dossier qui a déjà des fichiers (p. ex. téléchargé sur le net ou fait avec un autre IDE).
Avec TIGCC IDE / KTIGCC, c'est possible. Tu vas éventuellement mettre un peu de temps pour avoir tous les fichiers dans le bon dossier virtuel, mais à part ça, aucun problème. Mais justement l'idée est qu'il y a un seul EDI pour TIGCC et donc le problème des projets faits avec un autre EDI ne se pose pas! C'est bien pour ça que je suis aussi fortement contre l'utilisation d'autres EDIs ou de la ligne de commande. Rien que personnellement, à chaque fois quand ces utilisateurs me reportent des bogues, je me retrouve à devoir importer leurs !"§$%&/()=? de projets dans l'EDI. Mais ça touche tous les utilisateurs de TIGCC quand des sources sont fournies sans un projet TPR, ça agace tout le monde.
)
)
pour le loader perso, vive les programmes compressés et le pstarter standard!
