Ce que fait l'ide - Page 1

Existe-t-il un moyen de savoir ce que fait exactement l'ide de tigcc
lorsqu'on compile un programme, du style est-il possible
de générer un .bat avant ou bien pendant la compilation ?

l'IDE doit générer une sorte de .bat à chaque compilation, afin de déterminer quels fichiers ont été modifiés, et donc quels fichiers recompiler.
cela dit, je pense pas qu'elle génére quoi que ce soit... elle doit se contenter d'appeller tigcc.exe en interne

cela dit, tu peux parfaitement faire ton .bat toi-même...
tu pourras meme toi-même fixer tes options, pour chaque fichier source, plutot que pr tout le projet

bylos :
Existe-t-il un moyen de savoir ce que fait exactement l'ide de tigcc
lorsqu'on compile un programme, du style est-il possible de générer un .bat avant ou bien pendant la compilation ?

Non.
Utilise tigcc.exe ou tprbuilder.exe si tu veux compiler en ligne de commande.

squale92 :
l'IDE doit générer une sorte de .bat à chaque compilation, afin de déterminer quels fichiers ont été modifiés, et donc quels fichiers recompiler. cela dit, je pense pas qu'elle génére quoi que ce soit... elle doit se contenter d'appeller tigcc.exe en interne

Même pas, elle appelle les outils un par un. (Il y a du code commun à IDE.exe et à tigcc.exe, et il y a aussi des détails qui sont faits différemment dans IDE.exe et dans tigcc.exe.)

cela dit, tu peux parfaitement faire ton .bat toi-même...

Non. Il ne faut jamais appeller un exécutable autre que tigcc.exe ou tprbuilder.exe directement. Ça ne marchera plus avec les versions futures. (Parce que les outils utilisés en interne changeront dès la prochaine bêta et sont susceptibles de rechanger à tout moment. Le nom de notre linker, par exemple, ne vous regarde pas.)

tu pourras meme toi-même fixer tes options, pour chaque fichier source, plutot que pr tout le projet

Pour faire ça, il suffit d'utiliser tigcc -c pour compiler chaque source et tigcc pour linker. Et pour passer des arguments aux outils particuliers, cf. http://tigcc.ticalc.org/doc/comopts.html#SEC12. Attention, évitez d'utiliser -Wl, parce qu'on changera le linker dans la prochaîne bêta, et donc la plupart des options ne seront plus reconnues. (En revanche, notre nouveau linker aura des fonctionnalités très intéressantes que le linker GNU n'a pas. Et avant qu'il y en aient qui râlent sans raison: notre nouveau linker sera aussi sous GPL.)

arf dommage qu'aucun script ne puisse etre récupéré...
enfin bref c pas grave je vé me debrouiller, personnellement
ça me simplifie la vie de pouvoir compiler et linker séparément ou d'un seul coup avec
tigcc
En fait j'initialise tjs de la meme maniere la calculatrice pour tous mes programmes,
, et de meme pour les fonctions en fin de prog, ou d'autres qui me sont tjs tres utiles,
et j'aurai voulu les integrer à extgraph pour un usage strictement personnel, pour
m'éviter de retaper ces fonctions à chaque fois, ou à inclure plusieurs librairies,
mais je ne sais pas comment l'ide compile ma librairie, c pour ça ke j'ai un peu
du mal à les inclure dans le.bat d'extgraph, ki compile tous les fichiers avec des options différentes.
Enfin ma soif de savoir m'oblige à retourner bidouiller les options de compilations

Même pas, elle appelle les outils un par un

arf, ok

Non. Il ne faut jamais appeller un exécutable autre que tigcc.exe ou tprbuilder.exe directement

dans mon .bat, je ne fais des appels qu'à tigcc.exe
(cela dit, je pensais cque l'ide faisait pareil, ce qui explique ce que j'ai dit plus haut)

Pour faire ça, il suffit d'utiliser tigcc -c pour compiler chaque source et tigcc pour linker

c'est ce que je fais

tiens, sous linux, qd je voulais linker des .o, en faisant quelque chose du style
tigcc *.o -o krypton2 extgraph.a
(dans le genre)
ca me disait qu'il n'y avait pas de fichier en entrée... alors que sous windows, ca marchait (enfin, ca fait deja quelques temps, et je connais que dalle à linux)
(heu... fodrait que je reteste sous linux, vu que je l'ai réinstallé.)
(naturellement, sous linux, je teste avec la version linux de tigcc)

C'est censé marcher. Le shell devrait remplacer *.o par la liste de fichiers .o, séparée par des espaces. (Sous Windows, c'est aux programmes de le faire.)

Non. Il ne faut jamais appeller un exécutable autre que tigcc.exe ou tprbuilder.exe directement. Ça ne marchera plus avec les versions futures.

Et sous linux ?
Pour l'instant j'ai été obligé d'appeler les outils un par un dans un script, parce que l'exécutable tigcc ne marche pas (enfin, marche des fois mais pas toujours)...

./7> la prochaine fois que je boote sous linux, si j'y pense, je re-testerai

Le shell devrait remplacer *.o par la liste de fichiers .o, séparée par des espaces.

Sauf s'il n'y en a pas, auquel cas il laisse *.o (ça fait partie des comportements peu intuitifs du shell) ; donc même dans ce cas il devrait te dire que le fichier *.o n'existe pas et non qu'il n'y a pas de fichiers en entrée.
Tu as beaucoup de fichiers .o ? parce que tigcc version linux n'aime pas du tout les lignes de commande un peu longues, donc s'il y en a pas mal ça pourrait être ça ; sinon, pense à utiliser -v pour avoir les détails

je dirai une petite huitaine, environ, de fichiers o

Sally Brown
:

Non. Il ne faut jamais appeller un exécutable autre que tigcc.exe ou tprbuilder.exe directement. Ça ne marchera plus avec les versions futures.

Et sous linux ?

Même chose.

Pour l'instant j'ai été obligé d'appeler les outils un par un dans un script, parce que l'exécutable tigcc ne marche pas (enfin, marche des fois mais pas toujours)...

C'est censé marcher. Bogue connu: les lignes de commande longues ne marchent pas. (Il faudra que je corrige ça. )

Bogue connu: les lignes de commande longues ne marchent pas.

Oui, c'est bien de ça que je parle
j'aurais dû être plus précise...