roms a écrit :
RPM & DEB: le programme 'alien' permet de passer entres les formats .tgz, RPM et DEB.
De plus, il faut savoir que le format RPM est mort à terme. Toutes les distribs LInux passent à 'apt-get', le systeme de package Debian. Meme RedHat va y passer !
Ça ne veut pas dire qu'ils abandonnent le RPM. Au contraire, le standard de paquets prévu par la Linux Standards Base (LSB) est le RPM. Il y a une version de
apt-get pour RPM (
apt-rpm) qui marche très bien (vu que c'est ce que j'utilise pour mettre à jour mon
RedHat 7.3).
Concernant le packaging: comme KK, j'estime qu'un tgz est suffisant. Mon packager Debian a qui j'avais proposé de faire des packages a refusé: pas d'intérêt.
En effet.
Setup: aucun intéret sous Linux. Le système de gestion de package est très puissant, bcp plus puissant que c'est setup.exe débiles qui vous enlèvent pas la moitié des trucs.
Mais ça permettrait d'avoir une procédure d'installation pratiquement identique à celle de la version Windows. Et ça me permettrait aussi de:
- permettre à l'utilisateur de choisir son répertoire de destination pendant l'installation (mais il faudra voir si GCC et Binutils peuvent être facilement déplacés après avoir été configurés pour un certain préfixe). Par exemple, un utilisateur qui n'est pas
root voudra probablement installer TIGCC dans
~/tigcc plutôt que
/usr/local/tigcc.
- rajouter automatiquement les bonnes options d'environnement dans
~/.bashrc (en option, comme on le fait pour
autoexec.bat dans la version Windows).
Les seuls programmes pour lesquels ont trouve de tels Setup sont les jeux (UT, Quake3). Loki a développé un packager libre en GTK.
Est-il bien? Ça m'éviterait de passer mon temps à en écrire un pour TIGCC. (Même si le GTK ne me fascine pas trop personnellement.)
A vous lire, on dirait qu'avant que KK prenne en main TIGCC, on pouvait rien faire sous Linux. C un peu dommage pour les gens qui ont bossé sur TIGCC (Moilanen, moi) et ca me déçoit d'autant plus que j'y ait passé du temps (doc sur 'TIGCC internals', j'ai aidé SR sur les chm de TIGCC).
Disons que le problème était que, étant donné ta connexion Internet limitée, il n'y avait pas beaucoup de mises à jour. Moi, j'ai une connexion rapide en flat-rate, ce qui me permet de sortir des mises à jour beaucoup plus régulièrement. (J'en ai sorties 4 en moins d'un mois, et toutes les 4 correspondent à la même bêta Win32, alors qu'avant on avait 18 bêtas Win32 et aucune pour Linux.)
Et j'ai aussi corrigé des bogues embêtants dans
tprbuilder (par exemple, quand il mettait des
-Wl, devant une liste d'arguments, il ne convertissait pas les espaces en virgules dans cette liste d'arguments) et rajouté des fonctionnalités qui manquaient (
tigcc -ar,
tigcc -quill, ...).
Et enfin, ta version de TIGCC 0.93 était la première version utilisable de TIGCC pour Linux, les autres n'ayant pas supporté notre système de patching.
IDE sous Linux: pour l'instant, il n'y en a pas. XEmacs fait de la coloration syntaxique, pas la peine d'aller voir ailleurs.
Personnellement, je conseille plutôt
Kate, c'est plus simple à utiliser.
Oubliez l'emulation Wine, c'est crade et ce n'est pas une solution à long terme.
Entièrement d'accord. Et
Wine n'est pas capable de faire tourner
TIGCC IDE correctement.
Porter le parser et le patcher avec GNU Pascal n'est pas trivial non plus. La tentative s'est soldée par un échec.
Au fait, as-tu lu le message #44? "J'ai réécrit le patcher en C, donc en principe TIGCC devrait tourner sous n'importe quel Unix et sur n'importe quel processeur maintenant. Il n'y a que le switch
-g qui n'est supporté que sous Linux/x86 pour le moment." Il était assez facile à réécrire en C. Ça va bien plus vite que de s'amuser avec
GNU Pascal. Mais pour le
parser, je ne sais pas trop ce que je vais faire, parce que je ne sais pas du tout comment il marche, et parce qu'il doit aussi savoir lire le format COFF.
Porter l'IDE n'est pas possible car Kylix ne connait pas la moitié des classes de Dephi. Porter l'IDE = recoder l'IDE !
C'est ce que je disais aussi, mais il y a des personnes qui croient plus à la publicité de Borland qu'à l'avis des programmeurs expérimentés.
Coloration syntaxique: Scintilla est un éditeur à la XEmacs (coloration syntaxique, configurable, plugins) multi-plateforme grace à GTK. Utilisable en C, C++, ... C'est la solution que j'avais envisagé.
Voir: www.scintilla.org
Un projet LPG l'utilise: http://lpg.ticalc.org/prj_tisce/index.html
Bof.
-> Je rappelle que QT est peut etre multi-plateforme mais à 10000F la license, il n'est utilisable que sous Linux. Win32 & Mac -> oublier.
On peut parfaitement utiliser QT/X11 sous Mac OS X. Il y a même un serveur X en mode "rootless", qui fait qu'on ne voit pas la différence entre une fenêtre X11 et une fenêtre Aqua.
Pour Win32:
1. Il y a déjà une IDE pour Win32. Je n'ai aucune intention de faire de la concurrence à Sebastian.
2. QT/X11 tourne aussi sous Win32 avec Cygwin. Mais pour le mode rootless, on n'y est pas vraiment (quoiqu'il y ait un serveur X sous GPL en Java qui dit permettre le mode rootless sous Win32 - mais je ne l'ai pas essayé).
Kylix: = Linux/x86. Il n'y pas que Linux. John D. Ratliff (tutorials TechnoPlaza) l'utilise sur des UNIX (HP, Sun). Il y aussi les Mac.
C'est ce que j'ai dit moi aussi.
Conclusion: il n'y a pas que Windows, c'est ca qui fait la diversité. Quand on recoit des mails qui vous disent merci parce qu'ils attendaient avec impatience que leur plateforme soit supportée, c tres gratifiant.
Malheureusement, je n'en ai reçu aucun.
Personne n'a même pris le temps d'essayer mes versions.
Il faudra peut-être que je mette la version sur ticalc.org. Pour l'instant, je l'ai annoncée sur tigcc.ticalc.org, sur le forum de la TICT et ici.
[c'est moi]
Personne n'a même pris le temps d'essayer mes versions. 
) : http://www.arklogic.com
[c'est moi]
