Un IDE de developpement C++ sous Linux

[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_]

Envoyé par jlassiramzy

salut,

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

vi à tout hasard ?

[PierreAd]

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]

Envoyé par 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)

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

[azertyman]

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

[gnto]

Envoyé par ablinux

vi à tout hasard ?

perdu vi est un éditeur de texte

Envoyé par wikipédia

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_]

Envoyé par gnto

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]

Envoyé par gnto

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]

Envoyé par Luc Hermitte

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.

[gnto]

Envoyé par 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.

Alors si on prend le cas de anjuta(c'est celui que je connais le mieux), il fonctionne avec Gcc (g++) qui tourne sur *nix. il n'est pas packagé mais très liés.

Sur ces plateformes, il y a des compilos natifs qui doivent être ceux utilisés.

Qui te force ?

Dans anjuta, tu peux gérer la chaine de compilation, régler ton systeme d'indentation, tu as la completion de fonction, le debogage a la MVC++, etc...

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).

Encore heureux qu'il est des choses deja faite parceque si a chaque fois que t'achete une voiture tu dois trouver des pièces détachées pour la monter ta pas fini.soi-dit en passant je ne fais pas confiance au wizard, trop deçu de microsoft.
D'ailleur dans le dernier anjuta tu peux faire un makefile a la main et aprés anjuta peut l'intégrer dans un projet, ainsi je n'ai pas a bidouiller dans la config de anjuta.

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/...

Ben qu'as tu essayé ? le dernier anjuta sortira meme un diagramme de classe.
Qu'ententu par sur-couche de gdb ?

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 ?

Perso j'utilise les EDI comme editeur avancé parceque je n'ai pas le tps et l'envie de me faire des plugin vim. Je pense que l'EDI est un outils pour facilité l'immersion.
Certes les puristes preferes contruirent leurs plugins !

[Luc Hermitte]

Envoyé par gnto

Qui te force ?

Je me suis mal exprimé. Il n'y a aucun intérêt pour un IDE sous ces plateformes à imposer un compilo, et il ne peut pas distribué/imposé par un IDE (lourdeur du packaging, problèmes de licence, ...). Le compilo natif est généralement le bon réglage par défaut. L'IDE n'est plus qu'un environnement en sur-couche pour developper. Et du coup ... peut-on toujours vraiment parler d'IDE vu que le compilateur ne vient pas avec l'environnement de développement ?

Dans anjuta, tu peux gérer la chaine de compilation, régler ton systeme d'indentation, tu as la completion de fonction, le debogage a la MVC++, etc...

J'ai tout ça avec mon éditeur. Si je soulève la question du "pourquoi un IDE?", c'est parce que je les avais utilisés dans un temps où ils offraient plus de choses que les éditeurs disponibles sur les plateformes sur lesquelles je débutais. Aujourd'hui, ce n'est plus vrai. Leur avantage, c'est un peu le côté install-and-go, et souris pour accéder aux fonctionalités supposées avancées -- tout ce qui n'est pas de la saisie de texte.

J'ai tout et bien plus avec un vrai éditeur de texte orienté développement. Ca me gêne un peu que l'on écarte les propositions orientés développeurs qui savent se passer de la souris sous prétexte qu'ils ne répondent pas exactement à la définition d'IDE.

Ben qu'as tu essayé ? le dernier anjuta sortira meme un diagramme de classe.

Pour le C++, divers trucs. anjuta et kdelelop il y a longtemps. Le workshop de sun, VC, emacs, vi, vim, BCB, TC++. Un truc fait par redhat dont j'ai oublié le nom. Eclipse aussi. BCB-X. J'ai souvent fini par les écarter pour leurs éditeurs de texte trop simplistes (surtout quand on aligne plus de ligne de code que ce que l'on a besoin de la souris) et/ou mauvaise intégration du débuggueur. Certains j'ai abandonné au bout de quelques heures, d'autres je les ai utilisés pendant des années.

Maintenant, la situation est assez viciée dans la mesure où je peste quand je suis obligé d'utiliser un outil qui ne dispose pas des nombreux raccourcis claviers, et autres fonctionnalités, auxquels je suis habitué.

Pour le diagramme de classe, je suis assez sceptique en général. Je ne suis pas sûr qu'il y ait un seul outil qui sache faire du reverse pour déduire les sémantiques et les DPs que j'utilise -- sans parler de l'aspect meta-prog. Sans ça, l'intérêt du diagramme de classes est vite limité je trouve. En attendant, je me contente de doxygen. Qui a l'avantage d'être assez répandu et d'être indépendant d'un EDI => utilisable par les gens de la gestion de conf.

Qu'ententu par sur-couche de gdb ?

Un front-end pour gdb. Cela qualifie tous les débugueurs *nix que tu ne lances pas avec gdb ou dbx. Vu que ddd ou n'importe quel autre editeur ou EDI délègue toujours le boulot à gdb/dbx/...