Discussion :

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

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.

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

[jabbounet]

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.

L'aspect général de ces deux éditeurs est tres proches on pourrait dire qu'ils sont jumeaux, la plupart des modes d'emacs sont compatible avec xemacs et inversement, certains raccourcis clavier ou certaines façon de faire sont cependant différentes, les quelques fois ou j'ai utilisé xemacs j'ai été surpris par l'effet de certains raccourcis courant sous emacs qui n'etait pas associé à la même fonction.
Ces modes sont effectivement écrit en lisp. C'est un langage fonctionnel apparu en 1958, l'un des tout premier langage informatique (le second officiellement après fortran). D'ou son coté hardu par rapport à un langage récent. pourquoi utiliser le lisp pour ecrire les modes d'emacs? simplement parceque dans les années 70 il n'y avait pas autant de langage disponible que maintenant, C venait de naitre par exemple, et que lisp etait plutôt populaire au MIT à cette époque.

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 .

Il est a noter aussi qu'emacs s'adapte a n'importe quel compilateur, il suffit de lui préciser par expression reguliere ou trouver les informations sur le fichier et la ligne ou se trouve l'erreur. cela s'avère tres utile quand on te demmande de travailler sur un language esothérique et propriétaire que personne ne connais.

Il encapsule aussi nativement les debugger unix. pour la gestion de configuration, CVS est géré nativement, des modes sont aussi disponible pour clearcase et svn.

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

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.

[jblecanard]

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.

Oui mais bon, une bonne chaîne de compilation traite ce genre de cas automatiquement.

[jabbounet]

Oui mais bon, une bonne chaîne de compilation traite ce genre de cas automatiquement.

oui, encore faut-il qu'ils sachent un minimum comment marche une chaine de compilation et en particulier celle qu'ils utilisent.
Dès fois je pense que certains collègues veulent perdre du temps, mais je n'en suis pas certain.

[ruste]

oui, encore faut-il qu'ils sachent un minimum comment marche une chaine de compilation et en particulier celle qu'ils utilisent.

Oui, c'est l'ABC de la compilation. Avec les outils comme Visual C++, c'est l'outil qui s'en charge. Il faut dire que dans le monde de Microsoft, tout est bien intégré à Visual Studio, ça peut suffire. J'avoue que l'ensemble est efficace. Mais, comme pour tout outil spécialisé, il ne faut pas sortir des limites imposées par l'outil, et on est limité à cet outil seulement. C'est l'histoire de Visual Studio, de MS Office et de Windows au complet... Certains savent s'assurer la fidélité de leur clientèle

Mais s'il fallait que Microsoft décline, ce qui n'est pas impossible à l'ère du cloud, j'en connais plusieurs qui vont tomber avec. C'est le prix du logiciel propriétaire, la propriété est mutuelle. Une raison de plus pour apprendre à comprendre les bases d'une chaine de compilation.

[3DArchi]

Dès fois je pense que certains collègues veulent perdre du temps, mais je n'en suis pas certain.

Ces outils ne sont pas non plus la panacée. Exemple typique de cas mal pris en compte : je modifie un fichier, je compile. Je souhaite revenir en arrière : donc je récupère la version antérieure avec mon outil de gestion de conf préféré (svn, clearcase, etc..). Là, la plus part des outils ne recompile pas car la date du fichier source est antérieur à celle du fichier objet ... alors que ce n'est plus le même.
Tout recompiler lorsqu'on modifie un fichier, c'est effectivement assez inefficace. Mais se fier à 100% à la chaine de compilation, ben pas tout le temps.

[jabbounet]

Ces outils ne sont pas non plus la panacée. Exemple typique de cas mal pris en compte : je modifie un fichier, je compile. Je souhaite revenir en arrière : donc je récupère la version antérieure avec mon outil de gestion de conf préféré (svn, clearcase, etc..). Là, la plus part des outils ne recompile pas car la date du fichier source est antérieur à celle du fichier objet ... alors que ce n'est plus le même.
Tout recompiler lorsqu'on modifie un fichier, c'est effectivement assez inefficace. Mais se fier à 100% à la chaine de compilation, ben pas tout le temps.

Un bon vieux touch entre le deux yeux du/des fichier(s) impliqué(s) et c'est reparti comme en 40 ....

http://www.linux-kheops.com/doc/man/...1/touch.1.html

[3DArchi]

Un bon vieux touch entre le deux yeux du/des fichier(s) impliqué(s) et c'est reparti comme en 40 ....

http://www.linux-kheops.com/doc/man/...1/touch.1.html

A deux exceptions près : je suis pas sur *nux et le gestionnaire de conf (par expl clearcase) m'impose la date (je ne suis pas sur qu'une vue dynamique clearcase me laisse le choix dans la date).

[Aleph69]

je ne suis pas sur qu'une vue dynamique clearcase me laisse le choix dans la date.

Joli, respect!

[jblecanard]

Joli, respect!

Pareil, complètement validé

[jabbounet]

A deux exceptions près : je suis pas sur *nux et le gestionnaire de conf (par expl clearcase) m'impose la date (je ne suis pas sur qu'une vue dynamique clearcase me laisse le choix dans la date).

Je n'ai jamais dit que je me fiais a 100% aux chaines de compilation, sinon je n'aurais aucune idée de leur fonctionnement. Simplement, je les connais suffisamment bien pour savoir quand un build complet (qui peu prendre plusieurs heures pour certains cas) est nécessaire et quand il ne l'est pas.

Après que certains outils aient des limites, ça arrive et il faut savoir composer et faire avec.

Cependant sous windows il existe aussi des utilitaires te permettant de modifier la date de modification d'un fichier.


Ensuite si tu es sur d'autre os Vax/VMS, VxWorks, .... là je ne connais pas/plus les commandes.