150

c'est faux, pour codeblocks tu peux faire un projet avec du code existant, tu peux même utiliser ton make file personnel si tu veux pas le système de build de c::b

151

Brunni (./149) :
Bon alors sur ce point je ne suis pas d'accord. C'est précisément pour cette raison que je n'utilise pas Eclipse pour le dév amateur par exemple, impossible de créer un projet dans un dossier qui a déjà des fichiers (p. ex. téléchargé sur le net ou fait avec un autre IDE). Il faut absolument qu'il y ait un répertoire parent, qu'il y foute son .metadata plein de petits fichiers pourris, que la synchro soit mauvaise si on fait quoi que ce soit en dehors de l'IDE, etc. pareil pour Code::Blocks et autres qui veulent absolument gérer leur projet eux-même: impossible de faire un projet simple qui utilise un .bat pour compiler par exemple. Du coup j'utilise cet overkill de Visual Studio, tu peux créer tes fichiers depuis l'explorateur et les drag & drop au projet (ceux que tu souhaites inclure, pas toute l'arborescence bien sûr).
Je suis pas sur de comprendre ton problème avec Eclipse. Tu peux très bien crée ton projet ou tu le souhaite et drag&droper de ficher vers/depuis l'explorateur.
Le seul truc c'est que par défaut tu auras a faire un refresh de l'arborescence des fichiers crées/supprimé en par des logiciels externes mais il y a une option pour un refresh automatique.
avatar

152

Rares sont les IDE qui ne supporte pas le makefile actuellement
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

153

J'utilise peu Eclipse, mais il me semble qu'Eclipse (3.3 ou 3.4) m'a déjà fait le coup de ne pas trop aimer certains fichiers ajoutés par ailleurs, même après un refresh forcé.


Le passage "façon Kevin" de ./148 contient au moins un morceau sérieux: la compilation avec optimisations interprocédurales / le mode whole program, qui sera probablement une réalité tangible à moyen terme.
Supposons qu'un jour, le GCC de TIGCC/GCC4TI soit rebasé sur GCC 4.3/4.4 ou plus, pour lesquels l'IPO est à la fois plus stable (crashe moins le compilateur et génère moins de code incorrect) et plus puissante que celle de GCC 4.1. On pourra alors vouloir utiliser, avec une bonne confiance, l'IPO, parce que c'est exactement le genre d'optimisations qu'on veut activer sur une plate-forme embarquée, parce que ça peut permettre d'augmenter la vitesse et/ou de diminuer la taille...
Mais les outils de haut niveau ne supportent pas ce mode de compilation, et les outils de bas niveau ne doivent (d'après Kevin) pas être utilisés parce qu'ils pourraient en théorie changer de façon incompatible. Alors que fait-on ??
Vais poster ça comme feature request sur notre tracker, tiens.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

154

Lionel Debroux (./148) :
Ta philosophie "c'est à l'utilisateur de s'adapter à l'outil", philosophie que tu appliques à TIGCC, n'est pas la vérité universelle absolue... Ne citons que SAP (fabricant de logiciel propriétaire vilain, on sait), qui fait des outils modulaires et assez facilement modelables, et travaille avec ses clients pour faire des outils qui collent au mieux aux besoins des clients.

Mais ce sont des outils pour des entreprises, entreprises qui emploient une équipe entière pour personnaliser leurs logiciels, ce n'est pas pratiquable pour des particuliers.
Autrement dit, tprbuilder est un bug et pas une feature ?

tprbuilder est un outil qui sert à compiler des projets faits avec et pour l'EDI si on n'a pas accès à l'EDI pour une raison ou pour une autre. C'est plutôt obsolescent depuis qu'il y a KTIGCC. Et effectivement, des projets qui ne compilent qu'avec tprbuilder, ça ne rentre pas du tout dans l'utilisation prévue de l'EDI et je dirais même que ces projets sont bogués.
[Dans ce qui suit, je m'essaie à la critique à la façon Kevin telle qu'on la ressent depuis des années: dénigrer les méthodes, les idées et le travail des autres. J'utilise certaines de ses expressions, marquées en italique.]

Pourquoi ne peux-tu pas argumenter sans ce genre d'attaques personnelles? roll
Par conséquent, l'usage prévu de l'EDI est donc de créer, maintenir et ouvrir un par un douze projets quand je veux compiler TICT-Explorer. C'est irrésistiblement user-friendly trilove

Ben non, l'usage prévu de l'EDI est d'avoir un seul projet par programme. Comme tu le remarques correctement plus bas, ça implique la compatibilité on-calc, qui pour moi est indispensable (les calculatrices permettent le transfert entre les différents modèles, ce n'est pas pour que quelqu'un rajoute une limitation arbitraire à un seul modèle). Pour les traductions:
[ul][li]je ne suis pas convaincu qu'il soit utile de traduire un logiciel pour calculatrice - tant que le logiciel n'est pas incompatible avec les versions traduites de AMS, je ne vois pas le problème s'il est seulement en anglais,[/li][li]il y a sans doute des solutions plus maintenables pour les traductions que de recompiler le même binaire 6 fois, par exemple on pourrait utiliser des fichiers de traduction externes.[/li][/ul]

Ta solution avec le script qui appelle tprbuilder 12 fois oblige à recompiler tout le projet à chaque petite modification, même si elle ne porte que sur un seul fichier .c (chose que justement l'EDI évite et raison pour laquelle tprbuilder n'est qu'une solution de dernier recours), et pas une fois, mais 12 fois! (Et même si tu rajoutes un mode incrémentel à tprbuilder, ça ne va pas résoudre ce problème parce qu'il faut tout nettoyer entre tes 12 compilations et tout recompiler avec des options différentes. C'est bien pour ça que l'EDI ne permet pas de compiler les mêmes sources plusieurs fois, et ça ne rentre pas dans les fonctionnalités prévues pour les groupes de projets non plus. C'est tout simplement incompatible avec un modèle de compilation incrémentel.)
Alors même que le mode compilation avec optimisations interprocédurales - déconseillé et non supporté par toi - est inaccessible avec l'IDE, il faut passer par un système de build plus flexible (en fait, appeler directement gcc, patcher et ld-tigcc, parce que tigcc et tprbuilder en sont aussi incapables que l'IDE) si on veut y avoir accès.

Ce mode (qui est d'ailleurs intermodulaire, pas seulement interprocédural) est déconseillé et non supporté parce qu'il ne marche pas de manière fiable (à l'heure actuelle)! Même le GCC 4.1 de Fedora plante facilement avec --combine. (Je n'ai pas encore essayé ce que ça donne avec le 4.3.) D'ailleurs, dans GCC 4.1, il se limite essentiellement à l'inlining, qui est peu utile dans le cadre de l'optimisation taille.

Le jour où toutes les sources compileront avec --combine de la même manière que sans (et en particulier sans planter GCC) et où les fonctionnalités proposées seront vraiment intéressantes sera le jour où il sera considéré pour tigcc (et si ça se passe vraiment sans problèmes, tigcc pourrait même l'utiliser automatiquement). Mais pour l'EDI, le problème est que --combine est une fois de plus une fonctionnalité incompatible par principe avec le modèle de compilation incrémentel (raison pour laquelle pratiquement aucun projet de logiciel libre grand public ne l'utilise, parce que ce n'est pas compatible avec le fonctionnement des makefiles non plus, et cela fait que ce mode est peu testé et est par conséquent une des raisons pour lesquelles il est peu fiable).
D'ailleurs, rappelons que patcher est plutôt un hack, et de toute façon une solution de facilité pour implémenter dans les gcc / as de TIGCC des features absentes de gcc / as upstream. La bonne façon de faire, la solution à long terme, serait de modifier correctement gcc et as, même si c'est difficile

Et c'est prévu. Le patcher existe essentiellement pour des raisons historiques, il ne fait plus grand chose de nos jours, et ce qu'il fait toujours serait mieux fait dans GCC. C'est juste que j'ai eu des choses plus importantes à faire.
et pourquoi pas, de contribuer à upstream une partie de ces modifications-là - après tout, il n'y a probablement pas que sur cette architecture qu'on pourrait avoir envie d'utiliser du reg-relative.)

Impossible à cause de la bureaucratie des copyright assignments de la FSF.
Les overlays à la DOS ou CP/M (entre bien d'autres systèmes) étaient des moyens de s'adapter aux ressources limitées des machines sur lesquelles ces systèmes tournaient, et par là-même, permettre aux utilisateurs de se servir plus à fond du potentiel des machines. Enfin bon, ce que j'en dis...

Oui, mais ça ne sert à rien sur TI pour des programmes de taille inférieure à 64 KO (et dans le cas des programmes de Martial, la taille est largement inférieure à 64 KO), ça complique juste la compilation et crée un overhead de taille important.
Brunni (./149) :
Bon alors sur ce point je ne suis pas d'accord. C'est précisément pour cette raison que je n'utilise pas Eclipse pour le dév amateur par exemple, impossible de créer un projet dans un dossier qui a déjà des fichiers (p. ex. téléchargé sur le net ou fait avec un autre IDE).

Avec TIGCC IDE / KTIGCC, c'est possible. Tu vas éventuellement mettre un peu de temps pour avoir tous les fichiers dans le bon dossier virtuel, mais à part ça, aucun problème. Mais justement l'idée est qu'il y a un seul EDI pour TIGCC et donc le problème des projets faits avec un autre EDI ne se pose pas! C'est bien pour ça que je suis aussi fortement contre l'utilisation d'autres EDIs ou de la ligne de commande. Rien que personnellement, à chaque fois quand ces utilisateurs me reportent des bogues, je me retrouve à devoir importer leurs !"§$%&/()=? de projets dans l'EDI. Mais ça touche tous les utilisateurs de TIGCC quand des sources sont fournies sans un projet TPR, ça agace tout le monde.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

155

Kevin Kofler (./147) :
Et puis tu n'as qu'à coder des programmes en un morceau comme tout le monde plutôt que des overlays à la DOS ou CP/M. tongue.gif

Je te parle d'une exécution en flash bête et méchante, même pas d'overlay (méthode que j'utilise pas, elle est deprecated sous PedroM vu qu'on peut exécuter en flash justement. Par contre sous AMS, ON a pas trouvé mieux tongue)
avatar
<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

156

Kevin Kofler (./154) :
Ta solution avec le script qui appelle tprbuilder 12 fois oblige à recompiler tout le projet à chaque petite modification, même si elle ne porte que sur un seul fichier .c (chose que justement l'EDI évite et raison pour laquelle tprbuilder n'est qu'une solution de dernier recours), et pas une fois, mais 12 fois! (Et même si tu rajoutes un mode incrémentel à tprbuilder, ça ne va pas résoudre ce problème parce qu'il faut tout nettoyer entre tes 12 compilations et tout recompiler avec des options différentes. C'est bien pour ça que l'EDI ne permet pas de compiler les mêmes sources plusieurs fois, et ça ne rentre pas dans les fonctionnalités prévues pour les groupes de projets non plus. C'est tout simplement incompatible avec un modèle de compilation incrémentel.)


Bizzare.. Pas mal d'IDE que je connais sont capable de gaire les 12 compilations sans me gueuler dessus... (sinon comment je ferrais pour generer une application PPC/PPC64/x86/x86_64 en debug et release avec l'appuie sur un seul bouton dans l'IDE ?)
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

157

./154:
Ta solution avec le script qui appelle tprbuilder 12 fois oblige à recompiler tout le projet à chaque petite modification

Les disques sont gros et les machines modernes sont rapides. N'est-ce pas ?
Tu crois vraiment que je recompile les 12 projets à chaque petite modification, sachant que la majorité des modifications entre TICT-Explorer 1.30 et 1.40-pre est indépendante à la fois de la traduction et du modèle de TI-68k ? roll
parce qu'il faut tout nettoyer entre tes 12 compilations et tout recompiler avec des options différentes

Et alors ? Comme l'écrit Godzil, des IDE autres que cet IDE limité savent faire.
il y a sans doute des solutions plus maintenables pour les traductions que de recompiler le même binaire 6 fois, par exemple on pourrait utiliser des fichiers de traduction externes.

Ce qui veut dire ajouter du code pour trouver ces fichiers, donnant des programmes plus gros pour un gain fonctionnel douteux (ça permettrait à l'utilisateur de changer de langue au runtime sans retransférer le programme... est-ce vraiment si utile que ça ?).
le problème est que --combine est une fois de plus une fonctionnalité incompatible par principe avec le modèle de compilation incrémentel

Bah, il faut savoir ce qu'on veut. Si on veut / a besoin de (limite des 64 KB, etc.) plus d'optimisation, et que pour l'avoir, il faut laisser tomber un modèle qui n'est pas adapté à ce use case... so be it.
Oui, mais ça ne sert à rien sur TI pour des programmes de taille inférieure à 64 KO (et dans le cas des programmes de Martial, la taille est largement inférieure à 64 KO), ça complique juste la compilation et crée un overhead de taille important.

Dans le cas des programmes de Martial, on est assez d'accord smile
(enfin, si c'est une pure exécution en Flash dans un environnement qui va bien, l'overhead est plus faible)
Mais justement l'idée est qu'il y a un seul EDI pour TIGCC

Idée avec laquelle pas tout le monde n'est pleinement d'accord wink


./155:
Par contre sous AMS, ON a pas trouvé mieux tongue

On pourrait le faire, mais pour avoir une modification permanente (= pas un programme à relancer à chaque reset), il faut modifier une image de l'OS pour pousser la limite d'exécution en Flash (contenu de 0x700012) au-delà de FlashMemoryEnd, et de la FSigner avant de la transférer avec FreeFlash.
Tant qu'on est à modifier l'OS, on peut aussi en profiter pour désactiver la protection d'exécution en RAM (HW3Patch permanent).

Tickets #39 (upgrade GCC ?) et #40 (support whole program compilation) créés.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

158

Kevin Kofler (./154) :
Oui, mais ça ne sert à rien sur TI pour des programmes de taille inférieure à 64 KO (et dans le cas des programmes de Martial, la taille est largement inférieure à 64 KO), ça complique juste la compilation et crée un overhead de taille important.

Purée mais je rêve ou quoi ? Tu veux décrêter que j'ai pas le droit de faier tourner mes programmes en flache ? Je le fais si je veux puis c'est tout...

Quant à l'overhead, je dirais qqpart entre 100 et 300 octets, pas de quoi appeler ça un "overhead de taille importante". Ca vaut toujours mieux que les micro-kernels embarqués dans x programmes, les codes de démarrage non-optimisés ou les mmultiplications de routines de niveau de gris toutes HW1 compliant même sur HW2. Franchement t'es mal placé pour parler overhead grin
avatar
<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

159

./158: dans la liste, tu as oublié au moins sa préconisation d'utiliser des pstarters ! grin
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

160

Godzil (./152) :
Rares sont les IDE qui ne supporte pas le makefile actuellement

Oué mais makefile faut en faire et c'est chiant. Souvent je voudrais juste exécuter un petit fichier de commandes que j'ai écrit, et pas qu'il soit lancé dans un environnement virtuel du type cygwin... (en particulier j'aime bien si je peux appeler des outils natifs, genre écrire copy plutôt que cp par exemple)
Cela dit je serais assez intéressé de savoir faire un makefile qui me fasse l'équivalent d'un bat (appelle bêtement un processus externe). L'image des makefiles que j'ai c'est des trucs extrêmement complexes qui marchent vraiment par magie, j'en modifie le strict minimum.
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

161

default:
cmd truc.bat


enfin ça doit être de ce genre.

162

On peut faire des makefiles extrêmement complexes, mais ce n'est en général pas le cas de ceux qu'on maintient à la main. Le makefile d'un projet simple n'est vraiment pas obligé d'être compliqué.
En revanche, ceux qui sont auto-générés par automake (par exemple) sont effectivements complexes grin
Et la syntaxe makefile est plus compacte que du XML vilain à la ant ou maven, je t'assureoui


squalyl a posté ce qui suffit pour lancer un processus externe. En fait, dans son exemple, il faut un tab en début de ligne (éventuellement suivi d'espaces, mais il faut absolument un tab) devant "cmd", mais ce tab a dû être strippé par le processus de post.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

163

non j'ai mis 4 espaces mébon je suppose que "tout le monde" sait qu'il faut un tab embarrassed

164

Brunni (./160) :
Oué mais makefile faut en faire et c'est chiant. Souvent je voudrais juste exécuter un petit fichier de commandes que j'ai écrit, et pas qu'il soit lancé dans un environnement virtuel du type cygwin... (en particulier j'aime bien si je peux appeler des outils natifs, genre écrire copy plutôt que cp par exemple) Cela dit je serais assez intéressé de savoir faire un makefile qui me fasse l'équivalent d'un bat (appelle bêtement un processus externe). L'image des makefiles que j'ai c'est des trucs extrêmement complexes qui marchent vraiment par magie, j'en modifie le strict minimum.
Au contraire la syntaxe des fichier makefile fait à la main est extrêmement simple(si on veut rester dans le simple) et parfaitement adaptée pour exécuter facilement des commandes shell.
L'impression de complexité te vient sans doute des autotools qui génèrent automatiquement des makefiles très complexes. Comme la majorité des outils automatique, c'est puissant, mais il ne vaut mieux pas passer a la main derière.
le fonctionement de base c'est :
fichier_a_construire: liste des fichiers dont fichier_a_construire dépend
<tab>comande shell pour construire fichier_a_construire

Après tu peux définir des variables et des regle plus complexes(par exemple une règle qui indique comment compiler tous les *.c en *.o), mais le fonctionnement de base est extrêmement simple par rapport aux autres systèmes que je connais
avatar

165

(attention par contre, il lui faut ABSOLUMENT un tab et pas un softtab a ce *** de make)
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

166

C'est pour ca qu'un bon IDE (comme emacs au hasard) utilise automatiquement des hard tab dans un makefile.
avatar

167

Oui enfin Emacs, IDE.. heu non pas vraiment mais bon c'est perso ^^
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

168

emacs et vim répondent à la définition d'environnement de développement intégré (on peut lancer énormément de choses tout en restant dans l'environnement), mais ça reste effectivement du non graphique (dans une console) / semi-graphique (gvim, xemacs, etc.), très largement piloté au clavier ^^
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

169

emacs est pas forcément dans une console hein (bon ok, mio j'invoque toujoues emacs -nw cheeky)
avatar
<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

170

Ok merci les gars, c'est vrai que dans ce cas c'est vraiment simple smile
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

171

En effet smile
Essaie de faire la même chose avec Ant ou Maven (j'ai dû utiliser le premier à l'école, et je dois utiliser Maven pour le boulot), tu vas voir la différence trioui
(mais ces outils ont des avantages par rapport à make, je te rassure grin)
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

172

Bah si vous voulez utiliser un vrai "build system", il faudra utiliser CMake. tongue

Cela dit, déjà make me semble de l'overkill pour des projets pour calculatrice. TIGCC gardera le format de projets .tpr, avec éventuellement des petits ajouts, mais aucun changement radical. Des groupes de projets pourraient être rajoutés sous forme d'un format simple qui référence plusieurs .tpr, à part ça je ne vois pas l'intérêt d'un nouveau format.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

173

Kevin: c'est quoi déjà ton plus gros projet en C sur TI ?
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

174

Pas forcément si petit que ça, mais pourtant suffisamment simple pour ne pas rencontrer les limitations des TPR.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

175

Ben moi je vois TI-NES, le TPR montre plus que ses limites (et gtc aussi pour le coup sad)

(et c'est pas un projet complexe en sois c'est vrai, juste tres morcelé, et pas du tout "compatible" TPR)
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

176

C'est quoi la limitation concrète qui te pose problème?
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

177

Perso, j'aimerais savoir comment faire ça avec les outils de TIGCC :
#!/bin/sh

######################################
#	assemble the loader
######################################
tigcc	loader.s -v -o loader


######################################
#	generate info headers
######################################
echo " .ascii \"Built on "`date -uR | cut -f 1 -d +`\" > date.h
echo " .ascii \""`cat version`\" > version.h
echo " .ascii \""`cat author`\" > author.h
echo " .ascii \""`cat email`\" > email.h


######################################
#	generate bin files
######################################
../bin/ttbin2str/ttbin2str -s89 ./author.h author
../bin/ttbin2str/ttbin2str -s89 ./version.h version
../bin/ttbin2str/ttbin2str -s89 ./comment comment


######################################
#	assemble the main part
######################################
tigcc	asmain.s	\
	assembly.s	\
	cmdline.s	\
	commands.s	\
	files.s		\
	ints.s		\
	mem.s		\
	options.s	\
	strasm.s	\
	strcmdln.s	\
	strerror.s	\
	quit.s	 	\
	-v -o asmain

#	verbose.s	\
#	opcodes.s	\


######################################
#	create the pack archive
######################################
../bin/kpack/kpack loader.89z !asmain.89z icon.89i author.89s version.89s comment.89s asti68k
../bin/kpack/kpack loader.9xz !asmain.9xz icon.89i author.89s version.89s comment.89s asti68k
../bin/kpack/kpack loader.v2z !asmain.v2z icon.89i author.89s version.89s comment.89s asti68k


######################################
#	move binaries and clean sources
######################################
mv	asti68k.??z ../

rm -f	_kpack.asm	\
	author.h	\
	date.h		\
	email.h		\
	version.h	\
	*.89s		\
	\#*\#		\
	*.o		\
	*.??z		\
	*~		\
	../*~		\
	../doc/*~

cheeky
avatar
<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

178

J'avais un truc du même genre(avec encore plus de modules) mais avec makefile, ce qui évite de se farcir toute les étapes si elles ne sont pas nécessaire.
avatar

179

Folco (./177) :
######################################
# assemble the loader
######################################tigcc loader.s -v -o loader

Pas possible tant qu'il n'y a pas les groupes de projets. Il change si souvent que ça, le loader? Et puis sick pour le loader perso, vive les programmes compressés et le pstarter standard!
######################################
# generate info headers
######################################
echo " .ascii \"Built on "`date -uR | cut -f 1 -d +`\" > date.h
echo " .ascii \""`cat version`\" > version.h
echo " .ascii \""`cat author`\" > author.hecho " .ascii \""`cat email`\" > email.h

sick Beurk! sick

Pour la date, tu peux utiliser __DATE__ dans un .c (cf. grayversion.c dans les sources de TIGCCLIB pour un exemple). Pour le reste, c'est plus propre de mettre ça directement dans le .h en question.
######################################
# generate bin files
######################################
../bin/ttbin2str/ttbin2str -s89 ./author.h author../bin/ttbin2str/ttbin2str -s89 ./version.h version

sick Beurk! sick

Il y a sans doute une meilleure solution pour ça. Par exemple, tu pourrais traîter include "author" et include "version" spécialement dans ton assembleur, ça éviterait de devoir autogénérer ces fichiers à chaque fois.
../bin/ttbin2str/ttbin2str -s89 ./comment comment

Beurk le format de packs archive. sick (Non supporté par TIGCC.) Et puis il change si souvent que ça, le commentaire?
######################################
# assemble the main part
######################################
tigcc asmain.s \
assembly.s \
cmdline.s \
commands.s \
files.s \
ints.s \
mem.s \
options.s \
strasm.s \
strcmdln.s \
strerror.s \
quit.s \ -v -o asmain

Ça, l'EDI sait faire. grin
######################################
# create the pack archive
######################################
../bin/kpack/kpack loader.89z !asmain.89z icon.89i author.89s version.89s comment.89s asti68k
../bin/kpack/kpack loader.9xz !asmain.9xz icon.89i author.89s version.89s comment.89s asti68k../bin/kpack/kpack loader.v2z !asmain.v2z icon.89i author.89s version.89s comment.89s asti68k

C'est possible avec le post-processing de l'EDI. Mais sick pour ton système de pack archive, surtout le fait que asmain n'est pas compressé et gaspille donc de l'archive.
######################################
# move binaries and clean sources
######################################mv asti68k.??z ../

sick Pourquoi pas laisser le binaire où il est? Un seul dossier pour le projet complet.
rm -f _kpack.asm \
author.h \
date.h \
email.h \
version.h \
*.89s \
\#*\# \
*.o \
*.??z \
*~ \
../*~ \ ../doc/*~

Inutile. (Et il te crée des *~, KTIGCC? Si c'est le cas, il faudra que je corrige ça...)
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

180

Kevin, maître du monde, modèle du genre.

les autres, vous (on) faites de la merde.