chemins relatifs pour tigcc - Page 1

coucou,

Franchement, Kevin, tu veux pas implémenter un système de stockage de fichiers avec des chemins relatifs par rapport au fichier tpr?
pas forcément pour tigcc, mais au moins pour ktigcc

tu m'avais expliqué pourquoi c'est pas fait, je me souviens plus. c'était pas un souci technique.

N'empêche que c'est pas du tout agréable, on peut pas balader un projet dans des dossiers différents.
C'est très handicapant pour moi qui utilise subversion entre différents PC (et les dossier checkoutés ne sont pas du tout dans le même dossier sur chaque ordi)

Et aucun autre IDE n'a de support pour l'assembleur, ce qui fait de tigcc un outil précieux. c'est pour ça que je propose de l'améliorer.

Et y'a aucun workaround. J'ai pas envie d'éditer le fichier .tpr à la main, et je suis même pas sûr que ça marche.

Qu'en penses tu?

(au pire tu peux pas faire un script/programme qui modifie le fichier TPR avec tes quelques configs ?)

non je fais pas, ce sera tigcc.exe avec un makefile pour l'instant.

Les chemins sont relatifs si tous les fichiers sont dans le même dossier que le .tpr ou un sous-dossier de ce dossier, comme c'est censé être le cas. Et c'est bien un souci technique: si tu références un fichier n'importe où dans ton système de fichiers, comment veux-tu que KTIGCC sache si ce fichier va être déplacé avec le projet ou pas? Pour moi, un fichier en dehors du projet est un fichier en dehors du projet, il n'a rien à voir avec le projet, donc je ne vois pas trop comment l'adresser à part en absolu. La solution à ton problème est de mettre tous les fichiers dans le dossier de ton projet, et le .tpr directement dans ce dossier, pas un sous-dossier.

ok.

mais avoue qu'en général, si on met des fichiers en dehors, c'est pour améliorer la maintenabilité d'un projet, avec une arborescence type
src/
include/
doc/
projects/$platform

dans ce cas le projet est cohérent, propre, plus maintenable et mieux organisé.

le stockage en relatif pourrait être une option de l'IDE non activée par défaut.

Les projets TIGCC multiplateforme, ça ne court pas les rues, normalement le code a besoin d'être modifié pour TIGCC, les projets que ça concerne sont donc très rares. Et personnellement, je ne vois pas trop le problème de mettre le .tpr dans le répertoire de base, c'est un seul fichier, ça ne sert à rien de créer un répertoire pour un seul fichier.

Et dans mes projets, en général, tout est dans le répertoire de base ou presque. Cf. KTIGCC par exemple.

Sauf que quand tu es le seul mainteneur/développeur d'un projet utilisé par la multitude, il faut voir plus loi que 'moi je' et 'dans mes projets'

Tu penses que c'est quoi, KTIGCC? Oui, je suis le seul mainteneur et oui, il est utilisé. Évidemment, pas autant que les logiciels propriétaires les plus diffusés ni les logiciels libres les plus diffusés, et ce de plusieurs ordres de grandeur, mais ces projets ont en général plusieurs mainteneurs aussi.

Quant au travail en équipe, je ne vois pas en quoi mettre les sources dans le répertoire de base empêcherait de travailler en équipe. S'il y en a trop, on peut mettre certaines sources dans des sous-répertoires (comme c'est fait dans ld-tigcc par exemple), mais ça n'empêche pas de garder les fichiers projet et les fichiers source principaux (genre main.c) dans le dossier de base.

Non mais ce qu'il veut dire c'est que, justement parce que tu es le seul mainteneur alors que le projet est utilisé par d'autres que toi, le fait que TOI ça ne te dérange pas de faire comme ci et que dans TES projets tu fasses comme ça n'est pas une raison suffisante (ni même une raison valable) pour ne pas implémenter la possibilité de faire autrement si on veut ^^. Ça serait une raison valable si tu codais pour toi ^^

Ce n'est pas ça la raison de ne pas implémenter cette suggestion, c'est juste un argument comme quoi il n'est absolument pas nécessaire d'utiliser la structure qui n'est pas gérée.

La raison de ne pas l'implémenter est purement technique: KTIGCC n'est pas clairvoyant, il ne peut pas distinguer entre une référence au répertoire à côté dans le même projet, une référence au projet d'à côté et une référence qui pointe dans un dossier système quelque part (genre si tu mets ExtGraph dans /opt/ExtGraph, ça serait une aberration de mettre un chemin relatif vers ça!). Et la solution au problème est simple (mettre le .tpr à la racine du projet comme prévu).

(mega cross sans doute, rédigé hier soir)

Il n'est pas question de rendre ktigcc clairvoyant.

Ni de stocker les libs en relatif, même si ça reste possible, au prix de beaucoup de ../../.. .

Je parle des fichiers du projets, qui sont forcément liés d'une manière ou d'une autre au fichier TPR.

Et comment proposes-tu de distinguer un fichier du projet d'un fichier d'une lib externe? Ce n'est pas possible par extension, un .h peut être les deux.

Je ne comprends pas pourquoi tu insistes à demander que KTIGCC s'adapte à tes conventions plutôt que l'inverse, qui est pourtant beaucoup plus simple!

parce que ce que je propose est une option désactivable et désactivée par défaut, et que KTIGCC devrait s'adapter au maximum de conventions plutot que d'en supporter une et de tuer les autres.

N'importe quel chemin peut être converti de relatif en absolu si on connait le chemin absolu du TPR. Si tu veux pas faire l'algo, je te le fais, et tu l'intègres.

et puis j'ai bien lu le source du parseur de TPR et on y fait bien la différence entre les "C File %i" et les autres, donc c'est sélectionnable par vrai type de fichier et on a pas besoin de l'extension.

au pire on peut avoir une fenêtre de propriétés par fichier, pour y choisir si on veut l'enregistrer en relatif ou en absolu, je suppose qu'il y a déja une structure de données par fichier, vu que chacun a déja un "dossier virtuel".

Heu perso je suis de l'avis de KK (oui, ça arrive pas souvent) : il devient assez douteux de vouloir des chemins relatifs vers des fichiers qui ne sont pas dans le dossier ou dans un sous-dossier du TPR (à partir d'un rang en arrière, il se peut très bien que je veuille volontairement un chemin absolu, et il n'y a aucun mal à ce que le TPR qui est supposé être le point racine du projet soit dans le dossier le moins profond).

En revanche, est-ce que KTIGCC possède toujours cette horreur de dossiers virtuels qui ne correspondent pas aux dossiers physiques où sont stockés les sources ?

oui, hélas.

comme je disais le stockage en relatif devrait être activable par un bouton droit sur un fichire.

y-a-t'il un cas où un fichier situé dans le(un) (sous-)dossier du TPR ne bougera pas ne même temps que lui et devrait donc être enregistré en absolu ?
quelle application génère des chemins en relatifs pour un dossier situé plus "haut" que le dossier de départ ? (i.e avec un chemin qui commence par ../)

non je fais pas, ce sera tigcc.exe avec un makefile pour l'instant.

Pour l'expérience que j'en ai, un makefile ou un batch/script est souvent la solution la plus facile à écrire et la flexible, même s'il faut passer les switches à la main à tigcc (trivial si on sait lesquels il faut passer). Dit autrement: les TPR sont utilisables pour des projets simples (tous les fichiers compilés avec les mêmes options, tous les fichiers dans le même répertoire, etc.), mais moins pour des projets plus compliqués.

TI-Minesweeper et TICT-Explorer utilisent des TPR, parce qu'à l'époque, je n'avais pas compris les défauts des TPR (et qu'ils ne se manifestent pas trop dans ces programmes). Même si pour TICT-Explorer, c'était plus simple de patcher tprbuilder que de maintenir un TPR par langue pour le lanceur et l'explorateur (12 TPR au lieu de 2 !!).
Mais TI-Chess et ExtGraph ne sont pas basés uniquement sur des TPR, parce que différents fichiers sont compilés avec différentes options de compilation. Evidemment, je pourrais maintenir un TPR par jeu d'options de compilation, plus un qui linke le tout ensemble... mais bof, quoi.



Ce que je te conseille, c'est d'utiliser des chemins relatifs dans le TPR, et de compiler tes TPR avec tprbuilder. Exemple avec le TPR contenant plein de tests ponctuels d'ExtGraph:
Dans le TPR:
[code][Included Files]
C File 1=essais.c
GNU Assembler File 1=gray.s
Header File 1=../../lib/extgraph.h
Header File 2=../../lib/preshift.h
Archive File 1=../../lib/extgraph.a[/code]

Dans le code C:
[code]#include "extgraph.h"
#include "preshift.h"[/code]

squalyl (./13) :
KTIGCC devrait s'adapter au maximum de conventions plutot que d'en supporter une et de tuer les autres.

Alors déjà là je ne suis pas d'accord, donc on est mal partis.

N'importe quel chemin peut être converti de relatif en absolu si on connait le chemin absolu du TPR. Si tu veux pas faire l'algo, je te le fais, et tu l'intègres.

Ce n'est pas la conversion le problème, mais le choix de convertir ou pas.

et puis j'ai bien lu le source du parseur de TPR et on y fait bien la différence entre les "C File %i" et les autres, donc c'est sélectionnable par vrai type de fichier et on a pas besoin de l'extension.

Ça ne change rien, un Header File peut faire partie du projet ou d'une lib externe.

au pire on peut avoir une fenêtre de propriétés par fichier, pour y choisir si on veut l'enregistrer en relatif ou en absolu

Beurk! Pas pratique du tout, ça.

Zephyr (./14) :
En revanche, est-ce que KTIGCC possède toujours cette horreur de dossiers virtuels qui ne correspondent pas aux dossiers physiques où sont stockés les sources ?

Oui, et ça restera toujours, compatibilité antérieure oblige.

Lionel Debroux (./17) :
Même si pour TICT-Explorer, c'était plus simple de patcher tprbuilder que de maintenir un TPR par langue pour le lanceur et l'explorateur (12 TPR au lieu de 2 !!).

Ton patch a été intégré depuis.

très bien, donc tu as perdu un utilisateur de tigcc de longue date, je suppose que tu t'en fiches totalement vu leur nombre global, donc tant mieux.

la page de propriétés par fichier n'aurait jamais besoin d'être touchée pour monsieur tout le monde. sauf pour ceux qui veulent passer leurs fichiers en relatif.

tiens, je viens de voir que le dialogue d'ajout de libs de Code::blocks demande si on veut conserver le chemin en relatif ou en absolu quand on ajoute une lib, et garde les fichiers source du projet en relatif. Certains ont donc pensé au problème et l'ont résolu d'une manière efficace, on dirait...

Même si pour TICT-Explorer, c'était plus simple de patcher tprbuilder que de maintenir un TPR par langue pour le lanceur et l'explorateur (12 TPR au lieu de 2 !!).

Ton patch a été intégré depuis.

J'ai pas écrit le contraire

squalyl: je n'utilise plus non plus KTIGCC. A la place, j'utilise tprbuilder + un éditeur de texte à coloration syntaxique, pour le code source comme pour le TPR.

squalyl (./19) :
très bien, donc tu as perdu un utilisateur de tigcc de longue date, je suppose que tu t'en fiches totalement vu leur nombre global, donc tant mieux.

Je ne vois toujours pas en quoi c'est un problème de mettre ton .tpr à la racine de ton projet comme prévu au lieu de faire tes caprices.

la page de propriétés par fichier n'aurait jamais besoin d'être touchée pour monsieur tout le monde. sauf pour ceux qui veulent passer leurs fichiers en relatif.

Si ça t'amuse de faire 3 clics pour chaque ficher... Dans un gros projet, tu n'en as pas fini de cliquer!

tiens, je viens de voir que le dialogue d'ajout de libs de Code::blocks demande si on veut conserver le chemin en relatif ou en absolu quand on ajoute une lib, et garde les fichiers source du projet en relatif. Certains ont donc pensé au problème et l'ont résolu d'une manière efficace, on dirait...

Si tu appelles ça une "manière efficace"...

Et une fois de plus, le concept de "lib" vs. "fichier source" n'existe pas dans KTIGCC / TIGCC IDE, la seule manière que KTIGCC / TIGCC IDE a de savoir est justement si le fichier est dans le répertoire du projet ou un de ses sous-répertoires ou pas!

KK > ça ne serait pas envisageable de garder la compatibilité avec les TPR actuels (et leurs dossiers virtuels), mais mettre en place le même système que tous les autres éditeurs (c'est à dire faire correspondre avec les dossiers du système) pour les TPR nouvellement créés via KTIGCC ? parceque cette histoire de dossiers virtuels c'est vraiment LE truc tordu et mal foutu de TIGCC je trouve :/

Je ne vois toujours pas en quoi c'est un problème de mettre ton .tpr à la racine de ton projet comme prévu au lieu de faire tes caprices.

parce que j'ai plusieurs projets qui utilisent les mêmes fichiers. en ce moment:
-un makefile linux
-un projet codeblocks
-un projet tigcc

j'aime bien séparer les fichiers objets générés.

ma solution avec un menu contextuel sur les entrées de fichier demande un bouton droit+1clic par fichier. Si on pouvait sélectionner plusieurs fichiers simultanément, ça serait encore plus rapide.

la méthode de c::b est efficace, car les libs, on en ajoute 2 au début du projet, et après on est tranquille.

Zephyr: vu comment il argote avec moi, t'inquiete, ça sera pareil pour virer les dossiers virtuels

Ouais

Je ne sais pas si c'est moi qui est mauvais, mais quand j'avais essayé c'était la mort pour déplacer un fichier d'un dossier réel vers un autre...

Sinon, MDI, plusieurs projets dans l'éditeur, envoyer à VTI... ?

edit : réponse à ./23

autant demander à l'équipe de codeblocks d'ajouter le support pour l'assembleur, ça ira plus vite

Zephyr (./23) :
KK > ça ne serait pas envisageable de garder la compatibilité avec les TPR actuels (et leurs dossiers virtuels), mais mettre en place le même système que tous les autres éditeurs (c'est à dire faire correspondre avec les dossiers du système) pour les TPR nouvellement créés via KTIGCC ? parceque cette histoire de dossiers virtuels c'est vraiment LE truc tordu et mal foutu de TIGCC je trouve :/

Bah, c'est déjà le cas, si tu crées un nouveau fichier, il sera dans le dossier physique correspondant à son dossier virtuel!

squalyl (./24) :

Je ne vois toujours pas en quoi c'est un problème de mettre ton .tpr à la racine de ton projet comme prévu au lieu de faire tes caprices.

parce que j'ai plusieurs projets qui utilisent les mêmes fichiers. en ce moment:
-un makefile linux
-un projet codeblocks-un projet tigcc

Ça n'empêche pas de mettre les 3 fichiers projet dans le dossier racine. Un répertoire par fichier, ça ne sert strictement à rien!

j'aime bien séparer les fichiers objets générés.

Et ça, mettre le .tpr dans un sous-dossier ne le fait pas! Les .o sont toujours générés dans le dossier dans lequel se trouve le fichier source.

ma solution avec un menu contextuel sur les entrées de fichier demande un bouton droit+1clic par fichier.

Ça fait 2 clics par fichier, sur un gros projet, tu en as pour des centaines de clics.

Si on pouvait sélectionner plusieurs fichiers simultanément, ça serait encore plus rapide.

Mais on ne peut pas.

la méthode de c::b est efficace, car les libs, on en ajoute 2 au début du projet, et après on est tranquille.

Mais elle n'est pas réalisable dans le contexte de KTIGCC ou TIGCC IDE, il n'y a pas de "rajouter une lib", on rajoute les .a, .h etc. de la lib individuellement.

Ximoon (./26) :
Sinon, MDI

Beurk, quel intérêt? L'arborescence du projet sert déjà de système de tabs.

plusieurs projets dans l'éditeur

Pas forcément une mauvaise idée (et déjà proposé plusieurs fois), mais complexe à implémenter, donc pas pour tout de suite. Et puis ce n'est pas si dur que ça d'ouvrir 2 instances...

envoyer à VTI... ?

On peut déjà envoyer à TiEmu.

OK, te fais pas chier va. j'ai bien compris, c'est toi le dictateur de tigcc, tu fais ce que tu veux.

dommage, c'est tout.

moi je passe à make.

Bah, écoute:
* je ne suis pas à ton service, je ne programme pas sur commande, je n'ai pas signé de contrat avec toi et tu ne m'as rien payé,
* ce n'est pas parce que tu as une idée que c'est une bonne idée, je ne vois pas pourquoi tu persistes sur tes idées à tout prix sans vouloir entendre aucun raisonnement pourquoi cette idée est mauvaise.