Lionel Debroux (./121) :

Cela dit, ce n'est effecitvement pas vital sur les plateformes utilisant une variante de l'ISO-8859-1 comme charset système.

C'est à dire, en base installée, une grande majorité.

Je ne suis pas sûr que tes pourcentages soient valables pour TIGCC, le public visé étant un public de développeurs, donc les statistiques prises sur des échantillons d'utilisateurs moyens n'étant pas forcément valables. Pas mal des utilisateurs de TIGCC utilisent GNU/Linux, mais je ne connais pas les pourcentages exacts.

* Les options du projet connaissent aussi les options de ld-tigcc.

Les options du linker font partie des options du projet.

Oui, mais dans mon post que tu as cité, je ne parlais que de TIGCCLIB, j'avais oublié ld-tigcc.

* La compilation dans un dossier temporaire, ce qui permet:- de compiler un projet sans l'enregistrer et

Mouais. Je ne sais pas si ça doit être considéré comme une feature.

C'est une option, même pas l'option par défaut, mais c'est le comportement traditionnel de TIGCC IDE et certains utilisateurs (dont moi!) apprécient cette fonctionnalité.

- d'utiliser les dossiers virtuels.

Pas tout le monde ne considère ça comme une feature dans 100% des use cases

Alors c'est que vous ne l'utilisez pas correctement.

Si vous n'aimez pas les dossiers virtuels, rien ne vous empêche de faire correspondre les dossiers virtuels aux répertoires physiques. (C'est d'ailleurs ce qui se passe par défaut si vous créez un nouveau fichier dans un dossier virtuel. Et si vous créez vos fichiers en dehors de l'EDI, c'est déjà là votre première erreur. )

Je ne dis pas que c'est absolument trivial à réaliser, mais il existe, sur tous les OS, au moins un moyen de faire de l'IPC.

Utilisation totalement inutile de l'IPC, ça n'apporte absolument rien de faire ça avec l'IPC, ces fonctionnalités ont leur place dans l'EDI. Pourquoi veux-tu nous faire ça en IPC?

La plupart des IDE enregistrent les fichiers avant de compiler, puisque c'est nécessaire pour tous les vrais systèmes de build.

Je n'apprécie pas le sous-entendu dans la dernière partie de ta phrase.

Les IDE demandent éventuellement à l'utilisateur, si au moins un fichier a été modifié, s'il veut enregistrer avant de lancer le build.

TIGCC IDE et KTIGCC peuvent enregistrer automatiquement le projet aussi (c'est même l'option par défaut). Ce n'est juste pas forcément ce qu'on veut.

L'absence de ce comportement de l'IDE Delphi / KTIGCC ne priverait pas grand monde, je pense.

Si, moi, et donc ça ne changera pas.

Quand je veux tester un truc que je ne veux pas forcément garder, souvent, je modifie, je compile, puis je ferme l'EDI sans enregistrer. (Ou alors si je décide de garder la modification, j'enregistre à ce moment, après avoir compilé avec succès.) Je trouve ça très pratique et je ne vais pas supprimer cette fonctionnalité seulement parce que monsieur Debroux veut changer la manière dont fonctionne la compilation dans l'EDI (changement qui ne servirait absolument à rien parce que le comportement actuel est déjà codé).

Ce qu'il faut retenir, c'est qu'il y a de bonnes raisons pour lesquelles l'architecture des EDIs est telle qu'elle l'est.

Je vais le dire en clair: il n'est pas prévu de modifier la manière dont fonctionne la compilation dans TIGCC IDE / KTIGCC, sauf pour les petites modifications déjà effectuées dans le CVS de TIGCC et de KTIGCC 2 (compression ExePack intégrée au linker). Le fonctionnement actuel marche très bien et il restera tel quel (dans TIGCC, je ne peux pas parler pour le projet totalement différent de Lionel). De même, le format TPR ne subira pas de changements majeurs. Le seul changement que je retiendrais utile (mais je ne peux pas encore promettre que ce sera réalisé, ce sera pour KTIGCC 3 au plus tôt), ça seraient les groupes de projets (à la Visual Studio), ça répondrait aux demandes de Folco (qui veut pouvoir ouvrir un programme et ses libs dynamiques kernel en même temps) et des personnes qui demandent des fonctionnalités style makefile. Mais ça n'impliquerait pas une modification du format TPR, juste l'ajout d'un nouveau format (TPG?) qui contiendrait une liste de TPRs et les dépendances entre les TPRs (l'ordre dans lequel compiler quand on compile le groupe entier, par exemple si on a des libs statiques dans le mix).

La deuxième partie de mon message se voulait plus générale que les outils en ligne de commande ("hors de l'IDE lui-même").Qu'est-ce qui empêcherait de pousser Project -> Options hors de l'IDE ?

Que c'est une partie intégrante de l'EDI, ces options sont enregistrées dans le fichier .tpr quand on enregistre le projet (et seulement à ce moment - une fois de plus, on peut compiler un projet non enregistré!) et utilisées au moment de la compilation (directement par l'EDI depuis les structures en mémoire, sans passer par des fichiers - une fois de plus, on peut compiler un projet non enregistré! bis), je ne vois pas ce que tu veux externaliser.

Et puis la question est surtout: qu'est-ce que ça apporterait?

(Evidemment, il faudrait refactorer le code pour permettre à certains morceaux fonctionnellement communs à plusieurs exécutables d'être écrits une seule fois.)

Quel intérêt?

Et puis quels plusieurs exécutables? Il n'y aura plus qu'un seul EDI TIGCC avec KTIGCC 3.