Lionel Debroux (./130) :
Mais la réponse se trouve à un endroit où il n'y a pas besoin de la copier-coller: notre tracker de bugs et de feature requests (regroupés sous le vocable "tickets", dans Trac).

... auquel je n'ai en principe pas accès parce que vous firewallez mon IP.

Personne n'a indiqué travailler sur le portage du TIGCC patch vers un GCC plus récent.Il y a bien d'autres éléments de la todo list pour nous tenir occupés, tu sais. Nous avons commencé à introduire un processus de qualité (bug + feature request + patch tracker, ML, un vrai SCM), il faut continuer (automatisation des builds, etc.). Et puis il y a bien sûr les feature requests fonctionnelles.

Bref, vous vous limitez à bosser sur les petits détails faciles et vous comptez parasiter le projet TIGCC original pour tout ce qui est difficile. C'est sûr que c'est facile de "maintenir" un projet comme ça.

Le fait d'être "I" n'empêche pas d'être modulaire. Ce qu'à notre avis, TIGCC IDE et sa copie presque 1:1 KTIGCC ne sont pas assez.

À mon avis, ce n'est pas une histoire de modularité, mais bien d'intégration. Des petits "modules" éparpillés ne donneront jamais une intégration comparable à ce que TIGCC IDE et KTIGCC proposent.

En mémoire, sur le disque avec des diffs dans un sens ou dans l'autre, sur le disque avec une forme ou une autre de DB... ce ne sont pas les solutions techniques qui manquent.

Les solutions ne manquent pas, mais ils ont tous leurs désavantages et je ne suis pas convaincu que cette fonctionnalité soit nécessaire dans un EDI pour calculatrices.