Lionel Debroux (./15) :
A voir si on veut remettre un Project Wizard

Je ne suis pas sûr que revenir en arrière soit une bonne idée ici.

Et n'oublie pas que toute fonctionnalité à l'EDI doit être implémentée au moins 3 fois (TIGCC IDE, KTIGCC 1, KTIGCC HEAD (ce qui deviendra KTIGCC 2)), et il y a aussi votre fork de TIGCC IDE maintenant (une quatrième branche à modifier), et si vous voulez que votre fork soit multiplateforme vous serez bien obligés de forker aussi au moins une branche de KTIGCC (cinquième branche à modifier). Donc vous comprendrez que c'est absolument le mauvais moment pour rajouter des fonctionnalités à l'EDI maintenant, il faut attendre KTIGCC 3.

Et je te rappelle aussi que je n'ai pas de mainteneur pour le code Delphi (et non, je ne peux pas le maintenir parce que je n'ai pas Delphi ni le système d'exploitation correspondant). Si tu acceptais de maintenir TIGCC IDE (la version officielle) dans le cadre du projet TIGCC (le vrai), bien sûr tu devrais renoncer à certaines modifications (genre le support de VTI), mais il y aurait beaucoup plus de chances qu'un ajout comme celui-ci soit réalisé.

pour y mettre quoi ?

Effectivement, c'est pour ça que je ne suis pas sûr que ce soit une bonne idée. Un wizard qui ne demande que "[X] commentaires" ne sert pas à grand chose.

En fait, je ne sais même plus ce que le Project Wizard de TIGCC IDE avait

En gros les choses qui sont maintenant dans les Program Options dans les options du projet. Elles ont été déplacées parce que ce sont des réglages globaux et doivent donc être les mêmes pour tous les fichiers source, pas seulement le premier.

Mais proposer et implémenter un autre format plus flexible (en prenant l'inspiration sur des patterns connus dans les vrais IDEs), on peut

Comme ça votre fork serait incompatible avec TIGCC.

Malheureusement, les membres de la TIGCC Team n'ont pas fait dès l'origine ce qui est pourtant un truc basique de génie logiciel (le versionnement des formats de fichiers...), que font nombre de vrais IDEs (entre autres)...

C'est parce qu'une seule version fonctionne très bien. Les fichiers .c ne sont pas versionnés non plus. Les EDIs gèrent sans problèmes les anciens projets, les valeurs par défaut quand ils chargent un TPR sont telles que ça fonctionne, elles sont volontairement différentes des valeurs par défaut pour les nouveaux projets (chose que la ligne de commande ne peut pas faire et la raison pour laquelle je dis de ne pas compiler avec tigcc en ligne de commande).

Je pense que la vraie solution, et ce qui est vraiment demandé ici, ce serait de modifier tprbuilder pour qu'il gère les dossiers virtuels. (Le fait qu'il nécessite que dossiers virtuels == dossiers physiques est une limitation connue.) Le problème est que ça nécessiterait de compiler dans un dossier temporaire comme le font les EDIs, on ne pourrait plus simplement invoquer tigcc. Mais ça correspondrait vraiment à ce qui est demandé, changer le format TPR ne serait qu'une tentative de contouner cette limitation de tprbuilder (en l'imposant aussi aux EDIs?). Je vois 3 solutions pour implémenter ça:
* compiler toujours dans un répertoire temporaire, comme les EDIs,
* proposer une option qui permet de choisir si on compile dans un répertoire temporaire ou dans le répertoire courant,
* détecter automatiquement si les chemins virtuels et physiques correspondent et choisir le mode de compilation en conséquence.
Je ne suis pas sûr laquelle est la meilleure.

Même s'il se trouvait que TIGCC IDE ET KTIGCC ne se comportent pas mal en présence d'infos non prévues (je n'ai pas regardé), on est à peu près obligés de faire un nouveau format, puisqu'on ne peut pas faire confiance à certain pour ne pas être embêtés dans le futur par des changements intentionnels de comportement.

...