Outils TIGCC supplémentaires - Page 1

Etant doné que TIGCC a _quelques rapports_ () avec mingw,
je me demandais s'il était possible de faire quelques choses en rapport:

- Makefiles
- CVS ?

Moi je vois vraiment pas le rapport avec TIGCC.
Si t'as envie d'utiliser make ou cvs, alors il y en a déjà plusieurs pour Windows...

- echo CC=tigcc >>Makefile
- ???

Et je ne vois pas du tout le rapport avec MinGW, si ce n'est que TIGCC a été compilé avec pour Windows...


PS : je crois qu'il y en a qui vont pas franchement apprécier "ton" avatar...

EDIT : croisé

Les Makefile et CVS fonctionnent deja tres bien...
Tu sais que les Makefile et CVS sont independants de tout langage ?

Tu vas voir, il va te répondre oui...

PpHd > Oui (Sasume > )
Mais ça aurait été bien si ça avait été intégré dans TIGCC comme Dev-C++ et VC 2003.
(Et que les variables d'environnement soient définies et ne causent pas un si gros bordel...)

Et un accès à CVS depuis l'IDE aussi serait pas mal...

Tu peux utiliser mingw32-make ou MSYS make avec TIGCC. Mais non, l'IDE n'utilise pas les makefiles, il n'y en a pas besoin.

Quand à CVS ?

Ce n'est pas intégré dans l'IDE, mais rien ne t'empêche de l'utiliser.

Il existe déjà plein de GUI performants pour CVS, quel serait l'interêt ?

Celui de poster un topic où on étale à la fois sa "connaissance" de MinGW, des makefiles et de CVS ? (ou alors il y a un rapport secret entre ces trois choses et TIGCC IDE que je n'ai pas saisi, bien sûr )

Ben, Dev-C++, LUI, l'intègre. Mais c'est pô grave, c'est surtout que comme c'est pas intégré personne penserait à l'utiliser.

Pollux > Mais c évident voyons...
TIGCC IDE -> TIGCC -> GCC -> MinGW (c'est basé sur GCC) -> GPL -> makefiles et aussi (pas de relation directe entre les 2) CVS

Si, la relation directe c'est que ce sont deux outils plutôt utiles en compilation GNU qui ne sont pas utilisés sur TI.

Dans ce cas le rapport passe uniquement par le site/les développeurs GNU, pas par un outil quelconque (même et surtout MinGW)... Et il est donc très faible

Surtout que l'intérêt est relativement faible :
- makefile : bof, on n'a quasiment pas de préprocesseurs pour TI (à part maintenant Moka, mais Kevin ne veut pas le supporter parce que ça salirait l'image de TIGCC )
- CVS : bof, programmer sur TI à plusieurs c pas évident... et les projets sont tout petits en général. Et puis si par hasard un projet en avait qd même besoin, il pourrait toujours l'installer séparément.


Et en plus, j'imagine que ta demande ne vient pas d'un besoin réel

Pollux
: à part maintenant Moka, mais Kevin ne veut pas le supporter parce que ça salirait l'image de TIGCC

Non, parce que c'est Windows-only.

Pollux > Non, mais ça pourrait être intéressant. (Pas URGENT, mais quand m^)

Kevin> Je pense pas qu'il y ait besoin d'un toolkit graphique non portable ou ce genre de chose... Donc ça doit être portable sans trop de pb

C'est du Delphi. Donc il faut tout réécrire, comme je suis en train de le faire pour l'IDE.

Tu réécris l'IDE en quoi? C++?

Kevin > Nan mais arrête de dire n'importe quoi Du delphi ça peut très bien se complier sous linux, d'autant plus lorsque ça n'utilise que des fonctions standardes.

Oui, d'où le ./20

Ximoon> Oui, QT je crois.

Ximoon
: Tu réécris l'IDE en quoi? C++?

Je la réécris avec Qt Designer, donc oui, c'est du C++.

GoldenCrystal :
Kevin > Nan mais arrête de dire n'importe quoi Du delphi ça peut très bien se complier sous linux, d'autant plus lorsque ça n'utilise que des fonctions standardes.

* Kylix est Linux/x86 only, et ne compile pas toutes les sources Delphi parce que la librairie de composants est différente (CLX contre VCL).
* FreePascal est x86 et 68k only (Au passage, remarquez la présence du backend 68k. Ça vous dirait, du Pascal pour les calculatrices? ), et ne compile pas toutes les sources Delphi parce que certaines extensions de langage ne sont pas (encore) gérées, et parce que la LCL (Lazarus Component Library, le clone de la VCL) n'est pas (encore) complète.
* GNU Pascal ne compile pas du tout les sources Delphi, son support pour les extensions de langage de Borland est très limité.

Donc non, aucune de ces solutions ne convient pour TIGCC/*nix.

texte.txt"); Reset(F); WriteLn(F, "texte"); Close(F); end;

nan, mais tu vas pas me faire croire que Kylix peut pas compiler un var F: file;
begin
  Assign(F, "

Parce que je doute que Moka utilise des fonctions bcp plus complexes

Kevin Kofler
: * Kylix est Linux/x86 only, et ne compile pas toutes les sources Delphi parce que la librairie de composants est différente (CLX contre VCL).

Il y a une raison profonde à ce que ça soit x86 only ?

Je répète: "Kylix est Linux/x86 only". Donc comme ça, au lieu de supporter un triplet, on en supporte deux. <SARCASM>Ça nous avance beaucoup pour les dizaines de triplets supportés par TIGCC/*nix...</SARCASM> Non, franchement, Kylix ne nous sert strictement à rien.

Si je me suis fait ch**r à réécrire patcher et parser en C (roms avait fait un portage Kylix vite fait à l'époque), ce n'est pas pour réintroduire cette dépendance non-portable.

Pollux
:

Kevin Kofler
: * Kylix est Linux/x86 only, et ne compile pas toutes les sources Delphi parce que la librairie de composants est différente (CLX contre VCL).

Il y a une raison profonde à ce que ça soit x86 only ?

C'est propriétaire, donc il n'y a aucun moyen de lui attacher un backend pour une autre machine. Ni pour un autre OS (il n'y a pas que Windows et Linux au monde).

Il y a une raison profonde à ce que ça soit x86 only ?

Heu c'est quoi ce que tu appelle une raison profonde . C'est le choix de Borland c'est tout

Uther> je parlais de Kylix, pas de Delphi...

Kevin Kofler
:

Pollux
:

Kevin Kofler
: * Kylix est Linux/x86 only, et ne compile pas toutes les sources Delphi parce que la librairie de composants est différente (CLX contre VCL).

Il y a une raison profonde à ce que ça soit x86 only ?

C'est propriétaire, donc il n'y a aucun moyen de lui attacher un backend pour une autre machine. Ni pour un autre OS (il n'y a pas que Windows et Linux au monde).

Argl


De deux choses l'une : comme Delphi est relativement vieux (par rapport à C#, par exemple), soit il y a un réel manque de compilos, soit c'est un langage qui doit avoir de gros gros défauts...