Compiler dans une console n'est pas du tout un usage prévu de l'EDI.
Autrement dit, tprbuilder est un bug et pas une feature ?
[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.]
TIGCC IDE / KTIGCC ne sait pas faire les groupes de projets. Je nourris quelques craintes quant à leur implémentation, vu:
[ul][li]le temps que tu mets à merger des patches triviaux (dont l'existence même montre que contrairement à ce que tu écris, on a essayé et on essaie toujours de bosser avec toi)[/li]
[li]la pauvreté de tes méthodes de génie logiciel (SCM bien connu comme merdique et dépassé, pas d'infrastructure de build automatique, pas de moyen public et adapté de tracker les bugs, les feature requests, les patches, etc.). C'est pourtant bien connu qu'une parcimonie dans l'utilisation de méthodes de génie logiciel augmente les risques de faire des bêtises.[/li][/ul]
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
Ah, c'est vrai, Thomas et par la suite moi n'avions qu'à faire un binaire unique qui non seulement fonctionne sur tous les modèles, mais qui de plus embarque les traductions complètes pour les six langues supportées. Ca, au moins, TIGCC IDE / KTIGCC saurait faire.
Et après, sous la contrainte de cette significative augmentation de taille, faire tout notre possible pour optimiser taille. 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.
(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 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.)
[fin du passage rédigé à la façon Kevin]
Et puis tu n'as qu'à coder des programmes en un morceau comme tout le monde plutôt que des overlays à la DOS ou CP/M.
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...
[EDITs multiples]