GTC : un TIGCC sur votre calculatrice ? - Page 78

mais oui c'est une feature si un hello world aussi simple compile pas ! c'est pour empecher les ni00b d'utiliser GTC of course ^^

Bah oué

./2311 c'est ironique ?

Nil :
Hum, ça me rappelle certains bugs de TIGCC qui sont considérés comme des features par la team

Lesquels?

Je ne les ai plus en tête (vu que j'ai bien laissé le monde TI), mais cf. les commentaires de la beta 6 ou 7.

#include "fichier.h" alors que le fichier n'est pas dans le même dossier que le .c dans lequel on écrit cette ligne

heu, veut dire il recherche sur tout le disque???

non dans les fichiers qui sont dans le .tpr, ce qui n'est pas logique, ce qui fait que passer d'une compilation a la main

par ex #include "lib/graphic.h" en ligne de commande

marchera plus dans tigcc

et kevin appele ça une feature !

(on prend le cas ou les fichiers sont comme ça :

.
..
main.c
lib/graphic.h

void _main(void)
{
DrawStr(0,0,"cool",A_NORMAL); }

Un petit F5, et....

GT-Dev - Error

In file '' (line 4), in
function '__main' :

Error : local label not found: ''

Et ça finit par un Crash Intercepted de PreOS ().
Sous AMS 2.05, TI-92 Plus HW2 (rien d'autre dessus, quand je pense que j'ai fait un reset
total pour ça lol )

Y'a aucune solution...?

fait #include "std.h"
au lieu de tigcc.h

SnowTiger>
Oui, je sais que ça ne marche pas, je l'ai dit dans ./2302. Mais maintenant je sais d'où vient le pb (merci Nerick ), donc je vais pouvoir débugger ça.

Et effectivement, comme le dit kurni, on peut contourner le pb en utilisant "std.h" (mais je vais qd même corriger le bug, évidemment)

C'était quoi le problème en fait ?

C'était lié au support d'exit(), et en fait je passais par une variable globale pour stocker les références internes du label __save__sp__, mais celle-ci était en ROM (parce qu'elle était initialisée)

Godzil :
non dans les fichiers qui sont dans le .tpr, ce qui n'est pas logique, ce qui fait que passer d'une compilation a la main

par ex #include "lib/graphic.h" en ligne de commande

marchera plus dans tigcc
et kevin appele ça une feature !

Ce problème n'existe plus maintenant que l'IDE gère les sous-répertoires virtuels, il suffit que les structures de répertoires réelle et virtuelle correspondent pour qu'on puisse compiler le même projet en ligne de commande et dans l'IDE.

Et il est évident que le fait de pouvoir faire abstraction de la structure physique des répertoires est une feature!

il suffit que les structures de répertoires réelle et virtuelle correspondent pour qu'on puisse compiler le même projet en ligne de commande et dans l'IDE

quelle horreur ces répertoires virtuels

C'est une feature pour pouvoir organiser mieux ses projets. Pourquoi voulez-vous absolument que la structure des répertoires dans le projet corresponde à celle sur le disque?

pour que ça continue de marcher en mode ligne de commande à tout hasard...

Surtout que je ne vois pas en quoi on peut moins bien organiser ses projets si la structure correspond à celle du disque

d'autant que le système de répertoire de fat est largement suffisante pour bien s'organiser.

quoique symlink pawa, mais bon...

Kevin> N'importe quoi, c'est tout sauf pratique !
En plus, il n'y a pas de réelle abstraction car si on crée un fichier dans un sous-dossier "virtuel", il sera créé physiquement dans ce sous-dossier (qui sera lui aussi créé pour l'occasion).
Donc, soit vous faîtes un vrai système virtuel qui ne crée pas de dossiers lorsqu'on veut créer une nouveau fichier, soit vous ne faîtes pas du tout d'abstraction de la structure physique réelle (et c'est la meilleure solution à mon avis), mais pas un truc entre les deux.

Sinon, au passage, une question : comment faites-vous pour que ça fonctionne, les #include "fichier.h" qui ne sont pas dans le répertoire courant ? Parce que je suppose que vous appelez TIGCC.exe comme si vous l'invoquiez depuis une ligne de commandes. Et pourtant le comportement n'est pas le même

ouf je je vois que je suis pas le seul a penser ça

vince
: pour que ça continue de marcher en mode ligne de commande à tout hasard...

Alors rien ne t'empêche de faire comme ça.

Sasume :
Kevin> N'importe quoi, c'est tout sauf pratique ! En plus, il n'y a pas de réelle abstraction car si on crée un fichier dans un sous-dossier "virtuel", il sera créé physiquement dans ce sous-dossier (qui sera lui aussi créé pour l'occasion).

C'est fait justement pour que des gens comme Flanker ou vince ont ce qu'ils demandent! Il suffit de créer le fichier d'abord et le déplacer après pour avoir la "réelle abstraction".

Donc, soit vous faîtes un vrai système virtuel qui ne crée pas de dossiers lorsqu'on veut créer une nouveau fichier, soit vous ne faîtes pas du tout d'abstraction de la structure physique réelle (et c'est la meilleure solution à mon avis), mais pas un truc entre les deux.

Notre solution est "le meilleur des 2 mondes".

Sinon, au passage, une question : comment faites-vous pour que ça fonctionne, les #include "fichier.h" qui ne sont pas dans le répertoire courant ? Parce que je suppose que vous appelez TIGCC.exe comme si vous l'invoquiez depuis une ligne de commandes. Et pourtant le comportement n'est pas le même

Tout le projet est copié dans un répertoire temporaire. Cela permet entre autres de compiler un projet sans le sauvegarder (désactive l'option Auto-Save activée par défaut et tu verras...). Et l'IDE n'utilise pas TIGCC.exe en interne (il y a du code en commun dans les deux et du code qui fonctionne légèrement différemment entre les deux), mais ça n'a pas de réelle importance.

Kevin Kofler
:

Sasume :
Kevin> N'importe quoi, c'est tout sauf pratique ! En plus, il n'y a pas de réelle abstraction car si on crée un fichier dans un sous-dossier "virtuel", il sera créé physiquement dans ce sous-dossier (qui sera lui aussi créé pour l'occasion).

C'est fait justement pour que des gens comme Flanker ou vince ont ce qu'ils demandent! Il suffit de créer le fichier d'abord et le déplacer après pour avoir la "réelle abstraction".

"Il suffit de" ! Trop facile, c'est comme :

il suffit que les structures de répertoires réelle et virtuelle correspondent pour qu'on puisse compiler le même projet en ligne de commande et dans l'IDE

Une bonne IDE devrait justement permettre de ne pas se soucier de ces détails...
Je pourrais dire moi aussi "il suffit que le double buffering de TIGCCLIB permette d'utiliser des plans contigus pour pouvoir l'utiliser avec mon tilemap engine".

Donc, soit vous faîtes un vrai système virtuel qui ne crée pas de dossiers lorsqu'on veut créer une nouveau fichier, soit vous ne faîtes pas du tout d'abstraction de la structure physique réelle (et c'est la meilleure solution à mon avis), mais pas un truc entre les deux.

Notre solution est "le meilleur des 2 mondes".

Ben non, vous faîtes un truc entre les deux !

Pas content -> plains-toi chez Sebastian, c'est son idée, pas la mienne.

et hop, je rejette la responsabilité ailleurs

Et j'ai raison de le faire parce que c'est lui le responsable de l'IDE.
Parlez-lui directement au lieu de vous plaindre de ses choix derrière son dos!

On ne se plaint pas derriere son dos !!

Tu es le seul représentant de la tigccteam sur ce forum tu as donc comme obligation de reporter ce genre de plainte

Si ton boulot ne te convient pas tu n'as qu'a pas dire tout le temps que tu fait partit de la tigcc team

De plus je trouve lâche de faire partie d'une team quand il y a des lauriers à récolter et de s'en détacherdès le moindre petit problème...

Vu de loin (je ne suis pas l'évolution de tigcc) j'ai l'impression de voir un développeur qu'est fier que le projet ait été releasé mais qui n'en maitrise pas les tenants et aboutissants si bien qu'il se décharge au moindre bug qu'on lui signale (d'abord en faisant passer lesdits bugs pour des changements volontaires, des "features" puis ensuite en rportant la responsabilité sur d'autres membres de la team, bien entendu en leur absence, ils pouraient se défendre...).