Discussion :

[jlassiramzy]

salut,

je cherche un IDE de developpement en C++ sous redhat entreprise 4 .. quelqu'un aurait il une idee? et surtout comment configurer le compilateur g++ pour l'exploiter?

merci

[_shuriken_]

salut,

je cherche un IDE de developpement en C++ sous redhat entreprise 4 .. quelqu'un aurait il une idee?

vi à tout hasard ?

[Invité]

Salut a toi,

Alors voici quelques petites idées supplémentaires :

• Anjuta (sous Gnome)
• KDevelop (sous KDE)
• Eclipse avec le plugin CDT (sous tout )

Voilà !!! Perso anjuta je n'ai jamais vraiment accroché mais il fonctionne pas mal quand même... Eclipse avec CDT me paraît être un bon choix, surtout si tu l'as déjà utilisé pour faire du java par exemple...!

Cordialement,


PierreAd

[Michaël]

j'utilise anjuta pour faire un projet en c et il est assez performant : il propose la compilation, la construction, la distribution bref il est quand même pas si mal et il marche sous tout aussi (je l'utilise avec kde)

j'ai vu qu'il est capable de faire du c++ donc à priori pas de souci à se faire

[temar]

j'utilise anjuta pour faire un projet en c et il est assez performant : il propose la compilation, la construction, la distribution bref il est quand même pas si mal et il marche sous tout aussi (je l'utilise avec kde)

C'est marrant, moi il y a pas longtemps, j'utilisais encore Kdevelop, sous Gnome

[gnto]

vi à tout hasard ?

perdu vi est un éditeur de texte

Un environnement de développement intégré (EDI ou IDE en anglais pour Integrated Development Environment) est un programme regroupant un éditeur de texte, un compilateur, des outils automatiques de fabrication, et souvent un débogueur

Lors de mon dernier stage, sous RHEL 4 j'ai utilisé anjuta 1.2 qui est très bien mais la denière version instable la 2.x est encore meilleur.

[_shuriken_]

perdu vi est un éditeur de texte



Lors de mon dernier stage, sous RHEL 4 j'ai utilisé anjuta 1.2 qui est très bien mais la denière version instable la 2.x est encore meilleur.

Merci pour l'info GNTO

[Luc Hermitte]

perdu vi est un éditeur de texte

Effectivement. Même qu'avec vim, je ne suis pas obligé d'utiliser la souris pour trouver le bon répertoire dans lequel se trouve un fichier que je veux ouvrir (sur les 150 d'un des 10 composants du projet).

A part la gestion automatisée des makefiles ou équivalents, que reste-t-il aux IDE ?

[gnto]

Effectivement. Même qu'avec vim, je ne suis pas obligé d'utiliser la souris pour trouver le bon répertoire dans lequel se trouve un fichier que je veux ouvrir (sur les 150 d'un des 10 composants du projet).

A part la gestion automatisée des makefiles ou équivalents, que reste-t-il aux IDE ?

Un IDE est un programme regroupant :

1. un éditeur de texte,
2. un compilateur,
3. des outils automatiques de fabrication,
4. et souvent un débogueur

Tous ce qui est en gras manque a vim pour qu'il soit un IDE ou EDI

[Luc Hermitte]

2- Si tu parles d'avoir un compilo packagé avec l'IDE, cela n'a pas de sens sous les *nix. Sur ces plateformes, il y a des compilos natifs qui doivent être ceux utilisés. Sans compter que l'on se limite parfois à une version du compilo (celle vendue pour le projet) tandis que l'on peut sans problème mettre à jour les outils de dev. Sur d'autres plateformes, l'EDI est souvent celui de l'éditeur du compilo, sinon un truc livré avec un compilo "libre" capable de se plugger avec d'autres compilos.

Si tu parles de gérer la chaine de compilation. Alors vim comme emacs ont. Et cela marche bien mieux qu'avec des trucs qui sont officiellement des EDI (eclipse pour le citer ; compile avec ant depuis eclipse et oublie le clic sur la ligne de l'erreur pour ouvrir le fichier qui va bien ; il doit y avoir une option, mais bien cachée -- ça ne me parait pas adapté au public, que je suppose, visé par les EDI : un public qui attend que tout soit opérationnel immédaitement)

Concernant la gestion automatique des règles de dépendances et cie. Effectivement, il y a encore un petit vide. Avec des templates qui vont bien, cela ne serait pas le plus compliqué non plus. D'un autre côté, au boulot, avec la gestion de conf qui attend de pouvoir compiler en ligne de commande, on utilise les outils classiques externes aux EDI.

3- des wizards ? Ma foi, je m'en suis rajouté un pour vim qui me demande qu'elle sémantique je veux donner à mes classes c++ (valeur, pile non copiable, entité, entité clonable). Ce sont que des approximations, je n'ai pas encore eu de temps de proposer la liste des classes dont on pourrait hériter pour LSP/extension/implémentation/..., mais je ne connais rien d'équivalent chez les IDE. J'en ai d'autres p.ex. (dans les intelligents) qui me génèrent un squelette pour la doc doxygen de mes fonctions (en tentant de deviner le sens des paramètres).

4- Sorti de VC, je ne connais pas grand chose qui sorte du lot. Je n'ai pas encore été convaincu par les sur-couches de gdb/dbx/...
Vim doit être patché avec clewn, pour linux uniquement. Emacs sait faire depuis des lustres.


Ces éditeurs restent pour moi des éditeurs et ne sont pas des EDI. Mais qu'apportent vraiment ces EDI ? Facilité d'immersion ? Réglages par défaut pour celui qui ne veut pas aller chercher dans les bases de plugins existants ? OK. Moins d'huile de coude au départ, mais après ?

PS: j'avoue que j'ai développé pas mal de plugins vim pour le C++ entre autres.

[azertyman]

Sinon il y a Code::Block, qui semble être le remplaçant open-source de DevC++ ... mais multiplateforme