C'est quoi ce linker de MER** - Page 2

L'IDE:
Add, Make, Build (C'est ce que la fenetre d'aide dit). Puis, "Run Program".
"Make" ne compile que ce qu'il faut compiler. Build recompile tout.

Thibaut:
>>Il est possible que ton problème soit dû (u ? ût ? ut ?) au fait que _rowread n'est >>plus une fonction mais une macro
NON. _rowread est une function, _rowread_internal est une macro.

TiMad:
>>Il est tout a fait illogique de faire un define _rowread_internal..
L'equipe l'a gardé pour garder la compatibilité avec de plus vieux programmes parce que _rowread était: #define _rowread(row) (~(_rowread_internal(row)))

godzil:
Si tu veux un debugger, fais un toi-même! L'équipe TIGCC serait très content de l'avoir. Ils ne devront pas s'en faire un !

godzil
a écrit : Sinon aussi un zoli changement qu'on pourrait faire a TI-GCC, c de virer le "tigcc" et faire un vrai system de compilation digne de GCC : MAKE !

Parce que make est beaucoup plus compliqué à utiliser que tigcc.exe. Et rien ne t'empêche d'utiliser le make sur http://www.mingw.org et de faire des makefiles appelant tigcc.

C vrai quoi, pourquoi on se trimbale se programme alors qu'on utilise GCC ?? GCC gere bien l'appel a l'editeur de lien que je sache nan ? Alors pourquoi avoir autent de programme ??

Parce que GCC ne gère pas le système de linking de TIGCC (qui n'est pas une toolchain 100% GNU), ni l'appel de A68k.

Aussi un petit commentaire a se que g pu lire de kevin : TIGCC est basé sur GCC, et GCC est un ligiciel libre, alors je pige pas pq vous donnez pas directement les mise a jour sur la partie compilation de GCC modifié pour le projet TIGCC ?? Sachant que si par ex demain, il sortent GCC 4, il va falloir modifier tt les fichiers de GCC a la main pour intégrer les modifications que vous aviez faites...

Parce que:
1. Nos patches sont beaucoup trop sales pour l'inclusion dans GCC.
2. Certains de nos patches inversent même exprès certaines décisions de l'équipe de GCC.
3. Nous n'avons aucune envie de nous battre avec la bureaucratie des "copyright assignments" de la FSF.

Pour les versions futures de GCC, on fera comme on a fait pour GCC 3.0 et 3.1: je porterai nos patches.

En plus le must du must serait d'utiliser l'éditeur de lien de gcc, en rajoutant par exemple dans les liste de processeur un tag pour TI68k, sa serait encore plus propre, et il n"y "aurait plus" que GCC a DL pour avoir une version "mini" d'un compilateur C pour TI.

C'est trop compliqué.

Sinon pour l'IDE, je pense que sa serait une bonne id, je trouve perso que l'ide actuel manque un peu de fiabilité.. En plus, faudra m'expliqué la différence qu'il y a entre "Compil" et "Make" et "Build" pasque pour tt les projet que g pu faire, (multi fichiers ou pas, avec des fichier asm ou pas) il me fait TJRS la meme chose, donc, sa me fait 2 fonction inutile...

Compile -> ne recompile que le fichier actuellement dans l'éditeur
Make -> ne recompile que les fichiers qui ont changé (reconnus à l'aide de la date)
Build -> recompile le projet en entier

XDanger
a écrit : (les versions où il y a encore Compile, Make, Build sont très vieilles)

Faux, ils y sont encore dans la bêta la plus récente.

Thibaut a écrit :
Il est possible que ton problème soit dû (u ? ût ? ut ?) au fait que _rowread n'est plus une fonction mais une macro

C'est l'inverse: ce n'est plus une macro, mais une fonction.