90

question: est ce qu'il est possible de faire de la compilation séparée avec tigcc en kernel?
Car il n'a envoyé une serie d'erreur impressionante au linkage quand j'ai voulu compiler CC en kernel
avatar

91

> question: est ce qu'il est possible de faire de la compilation séparée avec tigcc en kernel?
Oui mais chaque compilation doit etre avec -DUSE_KERNEL

A noter que depuis GCC 4.0, il vaut mieux passer tous les fichiers d'un coup a GCC grace a -funit-at-a-time, car tous les fichiers seront parsees en un coup, puis apres il travaillera l'optimisation de tous smile (TIGCC experimental GCC 4.0 seulement)

92

question: est ce qu'il est possible de faire de la compilation séparée avec tigcc en kernel? Car il n'a envoyé une serie d'erreur impressionante au linkage quand j'ai voulu compiler CC en kernel
Moi aussi... Il me le fait avec as. Mais plutôt que regarder la première erreur et de la corriger, je reboote le PC tellement ça fait ramer sous
TIGCC IDE. sad
Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

93

Mais quelle idée de compiler avec TIGCCIDE aussi. un bon petit makefile est tellement plus pratique.
avatar

94

qqc de plus rapide que d'appuyer juste sur F9 pour assembler et envoyer à VTI ? hum
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

95

96

qqc de plus rapide que d'appuyer juste sur F9 pour assembler et envoyer à VTI ?

Bien sur! Mon makefile utilise tilp en ligne de commande pour envoyer automatiquement a VTI / tiemu / vraie ti.
Il reste a appuyer su enter c'est vrai.
avatar

97

Et surtout, le Makefile ne recompile que ce qui est nécessaire, pas la totalité.

98

Et surtout, le makefile peut appeler d'autres scripts automagiquement...

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

99

100

personnellement je me ferais quand meme pas chier avec des makefiles si j'utilisais pas les outils unix classiques avec... (surtout que pour bien faire il faut faire des "make depend" et tout ca, sinon ca sux)

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

101

un truc interprété par le logiciel make

102

J'ai cherché des définitions de makefile sur google tout à l'heure, qu'est ec que c'est concrètement? Un fichier de commande je suppose, comme un .bat?

en plus avancé

notamment, ça te permet de choisir, pour chaque fichier que tu veux compiler, de quels autres fichiers il dépend.
Autrement dit, ce fichier en question sera recompilé seulement s'il a été modifié depuis la dernière compilation, ou si un des fichiers dont il dépend a été modifié depuis la dernière compilation.

(avec "compilé" qui peut être remplacé par n'importe quelle commande)
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

103

Le makefile n'est pas vraiment un fichier de commande.
En fait on crée un fichier qui s'appelle makefile qui contient les regles pour faire la compilation. C'est le programme make qui lit le makefile et en déduit ce qui a besoin d'être recompilé

Voici un exemple très limité de ce qu'on peut faire.
on ecris le fichier makefile suivant:
CC=tigcc -O2 -DUSE_KERNEL                  # la commande de compilation est habituellement placée dans une variable du nom de CC

projet_test: projet test                   # la première cible est celle qui est construite pas défaut. 
                                           # Ici par défaut on construit le projet et on teste
					  

projet: main.89z data.89y                  # pour faire le projet il faut construire 'main.89z' et 'data.89z'

main.89z: main.c module1.o module2.o       # main.89z n'est recompilé que s'il y a eu un modification dans les fichier suivent 
	${CC} main.c module.o module2.o    # Commande utilisée si compilation nécessaire. ${CC} est remplacé par sa valeur
	
module1.o: module1.c                       # module1.o n'est recompilé que s'il y a des modifications dans "module1.c"
	${CC} -c module1.c
	
module2.o: module2.c                       # module2.o n'est recompilé que s'il y a des modifications dans "module2.c"
	${CC} -c module2.c
	
data.89y: data.bin                         # Supossons que tu convertit un fichier binaire en ficher de données TI
	convertisseur data.bin             # en utilisant un outil que j'ai appellé 'convertisseur'
	

test: main.89z data.89y                    # et pour tester
	tilp -cmdline .. main.89z data.89z # on evoie via TILP

clean:                                     # souvent un definit "clean" pour effacer les fichier produits et ainsi tout recompiler
	rm *.89z *.89y *.o 

"make" lancera la compilation se projet et lance le test
"make test" ne lancera que le test
"make projet" ne lancera que la compilation
"make clean" effacera tous les fichiers des compilations précédantes. Le prochain "make" reconstruira donc tout.
...

A chaque fois, make verifie si le fichiers qui sont nécéssaires pour construire la cible ont été modifiés. Si ce n'est pas le cas, il recompilera pas. Sur TI c'est pratique même si on peut s'en passer. Mais sur des gros projets ca sauve la vie.
avatar

104

[edit: cross avec uther, son makefile est mieux expliqué, ça invalide un peu mon post mais bon cheeky]

c'est même pas du tout un bat.
Un Makefile, comme son nom l'indique, détaille comment il faut faire pour créer le programme à partir des sources. Par exemple ça dit
fmon.o : fmon.c fmon.h
        cc -c -o fmon.o fmon.c

Ceci veut dire :
1- pour créer le fichier fmon.o, il faut fmon.c et fmon.h
2- à partir de ces deux fichiers, il faut exécuter la commande indiquée

Voilà, c'est très simple. En fait on pourrait même simplifier encore plus, parce qu'une règle aussi simple peut etre générée automatiquement par make (donc y'a pas besoin de l'écrire du tout). En indiquant comment créer chaque fichier, il suffit ensuite de laisser make déterminer tout seul la liste des opérations à faire. Notamment, si tu modifies juste un fichier et que tu relances make, il ne regénerera que les fichiers dépendant de celui modifié (ici, fmon.o sera recompilé si et seulement si fmon.c ou fmon.h est modifié), ce qui est un gain de temps énorme, surtout pour des gros projets.

Un Makefile peut en plus contenir des règles automatiques, des variables, des scripts et autres éléments sui permettent de spécifier de manière générique comment construire le projet, comment installer l'application, etc. Et c'est très générique, ça marche sur n'importe quel système où la commande make existe (en gros : tous (oui il existe make pour windows, et même visual c++ utilise un outil très proche, nmake)).

105

Uther :
A chaque fois, make verifie si le fichiers qui sont nécéssaires pour construire la cible ont été modifiés.

Nan tongue
Et c'est ca qui est chiant avec les makefiles, c'est que pour pas se planter, il faut faire extrement gaffe a ce qu'on ecrit : la par exemple si module1.c inclut toto.h, alors une modification de toto.h ne reconstruira aucun des fichiers, donc les modifications ne seront pas apparentes dans l'executable produit. Pire : si tu modifies apres module2.c, qui lui aussi utilise toto.h, module2 sera reconstruit, mais pas module1 : resultat, ton programme risque de planter puisque les structures de donnees employees ne seront plus coherentes entre module2 et module1...
Autre exemple, si tu veux rajouter un #define sur la ligne de commande (avec le switch -DFROBNICATOR), tous les fichiers ne seront pas recompiles, parce que le makefile n'est pas marqué en dependance de module1.o ... Donc memes risques d'incoherences/plantages ^^ Encore un autre exemple : tu mets a jour TIGCC, si l'ABI change, tu peux avoir des plantages plus ou moins subtils...

Ensuite meme une fois que tu as tenu compte de tous ces facteurs et fait un zouli makefile tout propre, si tu rajoutes un include et que tu oublies de rajouter la dependance qui-va-bien dans le Makefile, tu vas avoir les memes problemes ; heureusement, il y a des programmes pour faire ca (ca s'appelle makedepend), mais evidemment ca contribue encore a rendre le Makefile encore plus illisible... Et il ne faut pas oublier de faire "make depend" quand tu as modifie ce dont depend un fichier, donc le probleme n'est toujours pas entierement resolu... L'ideal serait de dire que la cible "depend" dépend de tous les fichiers .c/.h utilisés par le projet, et de le mettre en dependance de tous les fichiers .o, mais je ne sais pas si makedepend a une option pour ca ? (j'ai jamais eu le courage de faire les choses aussi bien tongue)

Bref, c'est vraiment penible d'utiliser des Makefiles mal foutus parce que tu vas avoir des pbs difficiles a detecter... Et le pb est encore accentué par le fait que les makefiles, c'est l'apologie de la duplication de code : si 99% des makefiles sont buggés, c'est pas parce que c'est pas possible de faire un makefile correct, c'est parce que c'est pas possible d'utiliser une lib qui, par exemple, ferait les makedepend comme un grand une fois que tu as dit que tu compiles bien des fichiers C et pas du Sindarin... (bon, y a des bloatwares pour faire des scripts de configure et tout ca qui font peut-etre des trucs du genre, mais je me suis jamais aventuré la dedans...)


(bon j'avoue j'ai pas pu me retenir de troller sur la fin, désolé happy)



Bref je crois que c'est un peu overkill, surtout quand on utilise pas des outils Unix (make a le gros avantage d'etre bien integre dans le monde unix), et tout recompiler permet au moins d'etre tranquille si on ne maitrise pas le detail du fonctionnement des makefiles (tant que les temps de compilation restent raisonnables) -- surtout que si a chaque fois que le code plante, on est tenté de faire un "make clean" au cas ou le makefile aurait foiré, on peut pas dire que ca soit plus rapide...

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

106

un mot : automake

107

oué, enfin je trouve ça un peu surdimensionné pour des programmes assembleur de qqes ko grin F9 suffit largement
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

108

nan, pas F9, F8 (qui lance make).

109

spectras :
un mot : automake
(bon, y a des bloatwares pour faire des scripts de configure et tout ca qui font peut-etre des trucs du genre, mais je me suis jamais aventuré la dedans...)
Wikipedia
: It [...] must be used with autoconf, another GNU tool.

Ca a des chances d'etre une usine a gaz, non ? Tu t'en sers vraiment ? Perso je trouve ca bcp plus propre de faire un truc juste a base de makefiles plutot que d'avoir des scripts de configure compliqués qui en plus ne servent que qd t'utilises d'autres usines a gaz comme bibliotheques ou que tu veux tourner sur des systemes prehistoriques... Mais si comme tu le sous-entends ca permet de faire des trucs simples et robustes, faut voir ^^

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

110

la par exemple si module1.c inclut toto.h,
et bien dans ce cas tu mets toto.h dans les dépendance c'est tout. Si on fait pas trop d'alzeimer en général on s'en souvient.
si tu veux rajouter un #define sur la ligne de commande
S'est vrai que ca j'y avais pas pensé. La solution est simple "make clean ; make" . Mais c'est vrai que c'est le genre de truc qu'on pourait facilement oublier.
si l'ABI change, tu peux avoir des plantages plus ou moins subtils...
Certes, mais bon quand tu vieins de changer les libraires et/ou le compilateur ca me parrais quand même prudent de faire systematiquement "make clean ; make"

J'ai fait une description simple car avec TIGCC on a rarement besoin de trucs monstrueux(pour PedroM peut-être) et parceque je suis pas sur qu'il avait envie d'avoir un cours complet sur les "makefile" "automake" "autoconf" ""ant" ou n'importequel autre outil de compilation.
avatar

111

>Uther:
1. Il faut que tu rajoutes le Makefile dans tes dependances.
2. Il faut que tu rajoutes main.89z data.89z au dependances de test.
3. J'ajouterai une ligne pour auto-recompiler convertisseur.

./105: Tout s'explique par ta propre incompetence. N'accuses pas Make de tes lacunes wink

Tenez le Makefile de PedroM
PREOS=../../preos/
PREOS_SRC=$(PREOS)/src
PREOS_STDLIB=$(PREOS)/stdlib.9xz
GPL=

##############################################################################

CC=tigcc
CFLAGS=-Os -fomit-frame-pointer -S -Wall
CSFLAGS=-Os -fomit-frame-pointer -S -Wall
INCLUDES=-I. -Ic
ASM=tigcc
A68K=a68k 
A68K_INCLUDE=-ic -i$(PREOS_SRC)
S2ASM=../bin/s2asm
MAKETIB=../bin/maketib
STRIP=../bin/strip
MV=mv -f
CP=cp -f

SOURCE=c/unpack.asm c/qsort.asm c/printf.asm c/md5.asm c/float.asm c/files.asm c/ellipse.asm c/clipline.asm c/bitmap.asm Bcd.asm     Estack2.asm  Heap.asm     Link.asm    Misc.asm     Script.asm   Vat.asm Boot.asm    Estack.asm   Ints.asm     Long.asm    PedroM.asm   shell2.asm   Vectors.asm Cert.asm    Flash.asm    Kernel.asm   Memstr.asm  Process.asm  Shell.asm    Window.asm Dialog.asm  Graph.asm    Library.asm  Misc2.asm   RomVoid.asm  Strings.asm stdlib.bin
TOOL=../bin/maketib ../bin/s2asm

all: pedrom

../bin/s2asm:
	cd ../bin/ ; make s2asm

../bin/maketib:
	cd ../bin/ ; make maketib

../bin/strip:
	cd ../bin/ ; make strip

$(PREOS_STDLIB): 
	cd $(PREOS) ; make # Far from perfect

stdlib.bin: $(PREOS_STDLIB) $(STRIP)
	$(STRIP) $(PREOS_STDLIB) stdlib.bin

c/bitmap.asm: c/bitmap.c ../bin/s2asm
	$(CC) $(CFLAGS) $(INCLUDES) c/bitmap.c -o c/bitmap.s
	$(S2ASM) c/bitmap.s c/bitmap.asm LBitmap 5
	$(RM) c/bitmap.s

c/clipline.asm: c/clipline.c ../bin/s2asm
	$(CC) $(CFLAGS) $(INCLUDES) c/clipline.c -o c/clipline.s
	$(S2ASM) c/clipline.s c/clipline.asm LClipLine 5
	$(RM) c/clipline.s

c/ellipse.asm: c/ellipse.c ../bin/s2asm
	$(CC) $(CFLAGS) $(INCLUDES) c/ellipse.c -o c/ellipse.s
	$(S2ASM) c/ellipse.s c/ellipse.asm LEllipse 5
	$(RM) c/ellipse.s

c/files.asm: c/files.c ../bin/s2asm
	$(CC) $(CFLAGS) $(INCLUDES) c/files.c -o c/files.s
	$(S2ASM) c/files.s c/files.asm LFiles 5
	$(RM) c/files.s

c/float.asm: c/float.c ../bin/s2asm
	$(CC) $(CFLAGS) $(INCLUDES) c/float.c -o c/float.s
	$(S2ASM) c/float.s c/float.asm LFloat 5
	$(RM) c/float.s

c/md5.asm: c/md5.c ../bin/s2asm
	$(CC) $(CFLAGS) $(INCLUDES) c/md5.c -o c/md5.s
	$(S2ASM) c/md5.s c/md5.asm LMD5 5
	$(RM) c/md5.s

c/printf.asm: c/printf.c ../bin/s2asm
	$(CC) $(CSFLAGS) $(INCLUDES) c/printf.c -o c/printf.s
	$(S2ASM) c/printf.s c/printf.asm LPrintf 5
	$(RM) c/printf.s

c/qsort.asm: c/qsort.c ../bin/s2asm
	$(CC) $(CFLAGS) $(INCLUDES) c/qsort.c -o c/qsort.s
	$(S2ASM) c/qsort.s c/qsort.asm LQsort 5
	$(RM) c/qsort.s

c/side92.asm: c/side.c ../bin/s2asm
	$(CC) $(CSFLAGS) -DPEDROM -DTI92P $(INCLUDES) c/side.c -o c/side92.s
	$(S2ASM) c/side92.s c/side92.asm LSide 5
	$(RM) c/side92.s

c/side89.asm: c/side.c ../bin/s2asm
	$(CC) $(CSFLAGS) -DPEDROM -DTI89 $(INCLUDES) c/side.c -o c/side89.s
	$(S2ASM) c/side89.s c/side89.asm LSide 5
	$(RM) c/side89.s

c/unpack.asm: c/unpack.c ../bin/s2asm
	$(CC) $(CFLAGS) $(INCLUDES) c/unpack.c -o c/unpack.s
	$(S2ASM) c/unpack.s c/unpack.asm LUnpack 5
	$(RM) c/unpack.s

pedrom89: $(TOOL) $(SOURCE) c/side89.asm
	$(A68K) $(A68K_INCLUDE) PedroM.asm -vTI89 $(GPL)
	$(MAKETIB) PedroM.o
	$(RM) PedroM.o
	$(MV) PedroM.tib pedrom89.tib

pedrom92: $(TOOL) $(SOURCE) c/side92.asm
	$(A68K) $(A68K_INCLUDE) PedroM.asm -vTI92P $(GPL)
	$(MAKETIB) PedroM.o
	$(RM) PedroM.o
	$(MV) PedroM.tib pedrom92.tib

pedrom8x: $(TOOL) $(SOURCE) c/side89.asm
	$(A68K) $(A68K_INCLUDE) PedroM.asm -vTI89TI $(GPL)
	$(MAKETIB) PedroM.o
	$(RM) PedroM.o
	$(MV) PedroM.tib pedrom8x.tib

pedrom9x: $(TOOL) $(SOURCE) c/side92.asm
	$(A68K) $(A68K_INCLUDE) PedroM.asm -vV200 $(GPL)
	$(MAKETIB) PedroM.o
	$(RM) PedroM.o
	$(MV) PedroM.tib pedrom9x.tib

pedrom: pedrom89 pedrom92 pedrom8x pedrom9x
	$(MV) *.tib ..

clean:
	$(RM) c/*.asm c/*~
	$(RM) *~ pedrom89.tib pedrom92.tib pedrom8x.tib pedrom9x.tib
	$(RM) stdlib.bin


Ca a des chances d'etre une usine a gaz, non ? Tu t'en sers vraiment ? Perso je trouve ca bcp plus propre de faire un truc juste a base de makefiles plutot que d'avoir des scripts de configure compliqués qui en plus ne servent que qd t'utilises d'autres usines a gaz comme bibliotheques ou que tu veux tourner sur des systemes prehistoriques... Mais si comme tu le sous-entends ca permet de faire des trucs simples et robustes, faut voir ^^

Oui et non. C'est une usine a gaz, mais il n'y pas vraiment le choix si tu veux des scripts portables sad
Sur TI, un Makefile est amplement suffisant.

112

1. Il faut que tu rajoutes le Makefile dans tes dependances.
2. Il faut que tu rajoutes main.89z data.89z au dependances de test. 3. J'ajouterai une ligne pour auto-recompiler convertisseur.
1. C'est vrai j'y avais jamais pensé.
Ca permet de corriger le problème des switchs de Pollux wink
2. J'ai hésité, j'avais surtout laissé tel quel pour montrer que le fait qu'il y ait une dépendance n'est pas obligatoire (j'avais oublié de mettre un "clean" au début)
3. J'y ai pensé mais je voulais faire assez simple.
avatar

113


2. J'ai hésité, j'avais surtout laissé tel quel pour montrer que le fait qu'il y ait une dépendance n'est pas obligatoire (j'avais oublié de mettre un "clean" au début)

Ben sinon ca buggue avec make -j4 (qui permet de compiler en general 25% plus rapidement).

114

exact, j'y pensais pas à cette enfoirée de géniale option.
avatar

115

Moi je m'en sers souvent. Meme que compiler GCC avec make -j fait ecrouler un systeme Linux cheeky

116

Make -j ca veut dire qu'il utilise autant de processus que possible c'est ca?
Y'a pas de moyen de limiter le nombre de prossessus par utilisateurs sous Linux?
avatar

117

FORK_MAX ?
Je suis tel la fleur du lotus.
Bien que naissant de la boue,
aucune boue n'y adhère.

118


Make -j ca veut dire qu'il utilise autant de processus que possible c'est ca?

Oui. La charge est montee a 115 puis pouf. Plus de reponses.

Y'a pas de moyen de limiter le nombre de prossessus par utilisateurs sous Linux?

Surement smile

119

PpHd :
./105: Tout s'explique par ta propre incompetence. N'accuses pas Make de tes lacunes wink

Personnellement mes Makefile sont propres, mais ce thread prouve que ce n'est pas le cas de tout le monde tongue (y compris toi ^^)
Tenez le Makefile de PedroM<snip>

Bah tu recompiles quasiment tout a chaque fois, c'est pas etonnant que ca soit simple triroll (sauf les fichiers .c, pour lesquels c'est buggé, mais tu ne dois pas les modifier tres souvent donc c pas trop genant)


Ca a des chances d'etre une usine a gaz, non ? Tu t'en sers vraiment ? Perso je trouve ca bcp plus propre de faire un truc juste a base de makefiles plutot que d'avoir des scripts de configure compliqués qui en plus ne servent que qd t'utilises d'autres usines a gaz comme bibliotheques ou que tu veux tourner sur des systemes prehistoriques... Mais si comme tu le sous-entends ca permet de faire des trucs simples et robustes, faut voir ^^

Oui et non. C'est une usine a gaz, mais il n'y pas vraiment le choix si tu veux des scripts portables sad

Voila, mais moi ce que je voulais c'est un truc léger qui soit axé non pas sur la portabilité, mais sur la possibilité de réutiliser un meme "squelette" dans plusieurs makefiles... (parce que la c'est tres artisanal, tonnes de code dupliqué, makefile buggés jusqu'a l'os comme le tien ou celui d'uther couic2)
Sur TI, un Makefile est amplement suffisant.

Si tu peux te permettre de tout recompiler a chaque fois, oui cheeky Sinon, c'est tres lourd sad

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

120

Tout s'explique par ta propre incompetence et/ou ton trollisme
N'accuses pas Make ni les autres de tes propres lacunes