Citation:
Envoyé par
ruste
J'ai utilisé xemacs pendant longtemps, au risque de déplaire au dieu de FSF. Son interface graphique est plus avancée que celle de emacs. Personnellement, je compilais XEmacs en mode Motif, pour avoir un look et un comportement un peu plus standard. Même si je me suis converti aux plates-formes modernes, comme netbeans, eclipse, code::blocks et autres, j'ai encore la nostalgie de ce genre de logiciel compliqué mais très modulaire. Dans le cas de XEmacs (et emacs), ses «plugins» sont programmés en lisp, un vieux langage, basé sur la récursion je crois. Donc, pas évident tout de suite, et rien pour être populaire au dernier congrès des développeurs.
Xemacs est un fork d'emacs qui est apparu dans les années 90 dont le but est d'offrir une interface graphique plus élaborée et avoir une partie du code réécrite en C++. emacs quand a lui est apparu dans les années 70 d'abords comme une extension d'un autre éditeur appelé TECO, puis comme un logiciel complet au milieu des années 80.
Citation:
En gros, je fonctionnais avec les Makefile. XEmacs permets d'exécuter les Makefiles sans quitter l'IDE. Lorsque les erreurs ou Warning sont générés lors d'une compilation, on peut cliquer sur l'erreur dans la fenêtre et XEmacs nous ouvre le fichier et la ligne en erreur. Donc, très pratique pour ceux qui ne désirent pas se lier à un standard spécifique, comme Code::Blocks. Ce dernier, que j'apprécie malgré tout beaucoup, utilise son interface propre, qui tiens lieu de Makefiles. Il demande un certains temps d'apprentissage. KDevelop de son côté est mieux standardisé, mais il faut vouloir apprendre à maîtriser les autoconf, automake, libtools & cie. NetBeans utilise son standard propre pour définir ses projets, basés en partie sur ant (donc on s'éloigne du C). Ça ne s'apprend en criant ciseau, et si pour une raison xyz le rachat d'Oracle par Sun fait disparaître NetBeans (ils sont rendus avec NetBeans, JDevelopper et BEA Workshop/Eclipse), ça sera un apprentissage vain.
KDevelop, en particulier, peut impliquer un temps d'apprentissage. Mais une fois cet apprentissage fait, je crois qu'il n'a pas tant que ça à envier à MS Visual C++. Aussi, il existe une version commerciale de KDevelop, mais je ne me souviens plus du nom.
D'apres ce que j'ai vu, Tous les éditeurs type eclispe/studio/.... lancent des lignes de commandes a un moment ou un autre pour compiler (que ce soit en appelant des equivalant de make ou directement le compilateur), en connaissant bien les fichiers de configuration de son éditeur préféré il est possible de les modifier, on peut aussi les faire apparaitre dans les logs en montant son niveau de traces, cela m'a souvent été utile pour retrouver ce que lancait l'éditeur lorsque j'avais besoin d'automatiser certains traitements par scripts, ou tout simplement faire la même chose sous emacs :).
Citation:
Pour ma part, je crois que tout programmeur C++ devrait avoir été familiarisé avec le concept des Makefile et des compilateurs en ligne de commande, avant de sauter sur des outils IDE comme Code::Blocks ou Eclipse. UNIX est comme ça, il peut décourager ceux qui tentent de passer de Windows (c'est-à-dire ceux qui sont habitués de manger à la cuillère) à UNIX mais avec le temps on se rend compte que UNIX exige de savoir ce que l'on fait. Ça fini toujours par nous être utile, même en revenant à Visual C++ et Windows. Ça a surtout l'avantage de nous découpler d'un fournisseur particulier pour nous coupler d'avantage au standard. Je parle par expérience :D
Surtout le concept de compilation séparée. c'est impressionnant le nombre de personne que je vois recompiler tout un projet alors qu'ils n'ont modifié qu'un seul fichier.