Lionel Debroux (./24) :
En première intention, penses-tu qu'il soit efficace pour nous, qui avons nous aussi un manpower limité (quoique moins que le tien...), de s'amuser à consacrer beaucoup d'énergie à autre chose que l'IDE Delphi, qui est quand même BEAUCOUP plus utilisé que tous les KTIGCC réunis, parce que Windows est BEAUCOUP plus utilisé que tous les Linux réunis (même si on ajoutait les chiffres de MacOS X, ça resterait vrai, mais c'est suffisamment merdique d'installer TIGCC sur MacOS X pour qu'il n'y ait pas un monde énorme qui le fasse, j'ai l'impression) ?
Donc votre fork sera monoplateforme?
Vous faites vraiment tout pour dégrader la qualité de ce qui était TIGCC avant de passer sous votre bulldozer. 
Un certain nombre d'entre nous, nous plaignons depuis des années du comportement de l'IDE, qui permet que dossiers virtuels != dossiers physiques. Cela ne nous paraît pas naturel du tout, ce n'est pas comme cela que font nombre d'autres systèmes de build...Nous aurions donc tendance à formuler cette phrase, qui est consacrée à tprbuilder, en remplaçant "limitation" par "feature"...
Ce n'est pas une fonctionnalité d'interdire quelque chose. Personne ne t'oblige à utiliser des dossiers physiques et virtuels qui ne correspondent pas.
Je vois 3 solutions pour implémenter ça:La solution 1 est clairement inapplicable parce qu'elle casse la compatibilité antérieure de certains projets faits avec tprbuilder (au moins ExtGraph).
* 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.
Argument non valable, les projets TPR sont avant tous des projets pour les EDIs, si tu fais un projet qui ne marche qu'avec tprbuilder, c'est ton problème, ce n'est pas documenté donc pas supporté.
À toi de corriger ton projet pour que la structure des dossiers du projet corresponde à la structure physique (ou alors de modifier les #include pour correspondre à la structure virtuelle, mais ça rendrait le projet incompatible avec la version actuelle du tprbuilder) et tous les fichiers nécessaires pour la compilation soient référencés dans le projet (un projet qui ne satisfait pas ça n'est pas un fichier .tpr valide).
Et à mon avis, il n'y a pas beaucoup de projets dans ce cas.
=> Pour moi
, proposer dans l'IDE l'option de compiler dans un répertoire temporaire (solution 2), bien évidemment désactivée par défaut (pour garder la compatibilité avec le comportement actuel de l'IDE)
Je pense au contraire de rendre le dossier temporaire le choix par défaut, parce que tprbuilder est censé être compatible avec les EDIs, le comportement actuel de tprbuilder est une limitation technique à corriger, et les projets bogués comme ExtGraph pourraient utiliser l'option.
Cela dit, je ne sais pas s'il vaut le coup de maintenir les 2 modes juste pour faire marcher ExtGraph. Un fichier .tpr qui ne fonctionne pas avec les EDIs n'est pas un fichier .tpr valide.
@Godzil: KTIGCC 1 peut être compilé sous OS X. Si tu veux une version Qt/Mac native (KDE 4), tu peux m'aider avec KTIGCC 2 (ou 3, mais si j'ai un patch pour la compatibilité avec OS X avant la release 2.00 et s'il ne casse rien sous GNU/Linux, je veux bien le merger).
Flanker (./28) :Kevin Kofler (./17) :
C'est parce qu'une seule version fonctionne très bien. Les fichiers .c ne sont pas versionnés non plus.
Et tu trouves que c'est une bonne chose ?
OK, à la demande de Flanker, dans la prochaine version, tout fichier .c doit porter une déclaration de la forme:
#pragma TIGCC ISO_C99 #pragma TIGCC USE_GNU_EXTENSIONS #pragma TIGCC USE_TIGCC_EXTENSIONS
sinon il sera refusé.
(Je plaisante évidemment.
)
Tu en as d'autres comme ça? 
)
, par expérience
Mais ce qu'il a posté ne fonctionne au mieux que pour 1% des OS.