J'utilise Eclipse pour coder en C++ et je veux faire la doc avec Docbook. Donc je veux faire la doc avec Eclipse. Désolé, je n'ai pas envis de me prendre la tête avec (X)Emacs (éditeur excellent, là n'est pas la question).
J'ai installé WebTools Platform, EclipseXSLT, Orange Volt et FOPBridge.
Grosso-modo les choses ont l'air de marcher. Je dit "grosso-modo" car je débute.
Eclipse je veux principalement l'utiliser pour l'édition (ça marche bien, c'est sympa). Mais il serait bien d'avoir le reste qui marche (traduction vers html, pdf, etc) sous Eclipse.
La traduction vers html, pdf, etc sera faite avec docbook-util (parfait avec un Makefile).
Trève de blabla. Je débute et j'amerai savoir si d'autres font du docbook sous Eclipse, s'ils ont des liens vers de la doc ou des articles intéressants, des "trucs et astuces", etc.
Tout commentaire est le bienvenu.
Journal Eclipse & Docbook
10
nov.
2007
# et hop
Posté par djibb (site web personnel) . Évalué à 3.
[^] # Re: et hop
Posté par IsNotGood . Évalué à 1.
Ce n'est pas un "appel au secours" afin de corriger quelque chose que ne marche pas. C'est pour ouvrir une discussion, faire quelques échanges, avoir des informations, etc.
Tu remarqueras, par exemple, que je ne dis pas quelle version d'Eclipse j'utilise, etc.
[^] # Re: et hop
Posté par Nicolas Schoonbroodt . Évalué à 1.
[^] # Re: et hop
Posté par IsNotGood . Évalué à -1.
J'utilise l'eclipse de Fedora. Comme ça tu pourras dire que j'ai fait un journal de plus sur Fedora.
Content ?
# ne sois pas désolé,
Posté par paul . Évalué à -1.
[^] # Re: ne sois pas désolé,
Posté par IsNotGood . Évalué à 2.
# Le java, oui, le c++ ferrugineux, non
Posté par Val1472 . Évalué à 2.
- Tu peux compiler du C/C++ avec ant et les cpptasks [1] (tes cibles apparaîtront dans l'interface). Par contre, tu seras obligés de régler tes paramètres 2 fois : 1 pour le build automatique, 2 pour ton makefile/antfile.
- Pour la documentation doxygen : eclox [2] : te permet de configurer le doxyfile et de lancer la construction de la doc.
- Pour DocBook, j'ai ça dans mes bookmarks [3], (je n'ai pas eu le temps de tester)
- Pour l'intégration avec SVN : subclipse [4], mais honnêtement subversive [5] est bien mieux. (plante moins...). Par contre, ce qui est particulièrement pénible, c'est l'incompatibilité de la ligne de commande avec l'interface graphique : Si tu fais une opération "svn update" en ligne de commande sur ta copie locale, Les plugins deviennent fous, et t'as plus qu'à refaire un checkout ailleurs...
- L'organisation (valable aussi en Java) : Mylin [6] te permet de "d'organiser" le travail. Tu peux le connecter à ton repository svn et à ton tracker de bugs préférés. Ce qui est assez pratique.
Maintenant, un petit retour d'expérience : autant je suis convaincu par Eclipse quand il s'agit de faire du Java, autant Eclipse pour c++ ne m'a jamais vraiment satisfait.
Finalement, il y a beaucoup d'instabilité entre tous les plugins que l'on assemble pour faire un IDE "perso".
L'autocomplétion c/c++ ne vaut pas celle d'un omnicompletion, et en règle générale, l'interface est très lourde.
Eclipse et tous les plugins consomment beaucoup de ressources et mettent du temps à réagir à chaque petits cliques que tu fais sur l'interface.
Maintenant ... les goûts, les couleurs tout ça... :)
[1] : http://ant-contrib.sourceforge.net/
[2] : http://home.gna.org/eclox/
[3] : http://www.dpawson.co.uk/docbook/ant.html
[4] : http://subclipse.tigris.org/
[5] : http://www.eclipse.org/subversive/
[6] : http://www.ibm.com/developerworks/java/library/j-mylyn1
[^] # Re: Le java, oui, le c++ ferrugineux, non
Posté par IsNotGood . Évalué à 1.
Mouaif. Eclipse me lance make et ça roule. De plus je ne veux pas que eclipse soit indispensable pour le projet. C'est seulement un IDE (excellent). Je fais une appli en C++, pas en java. D'autres pourront utiliser Vim, Emacs, qu'importe.
> - Pour la documentation doxygen : eclox [2] : te permet de configurer le doxyfile et de lancer la construction de la doc.
Merci pour l'info. Je regarderai ça avec beaucoup de sérieux (c'est bookmarker).
Pour la doc developpeur, jusqu'à maintenant j'ai surtout pensé à Doxygen et BoostBook (qui permet entre autre de générer du Docbook via du Doxygen).
> - Pour l'intégration avec SVN : subclipse [4], mais honnêtement subversive [5] est bien mieux. (plante moins...).
Je ne suis pas arrivé à faire marcher subclipse :-(
M'enfin, l'utilisation de la ligne de commande ne me dérange pas. Subversion a une excellente ligne de commande. Subversion a aussi de bon programmes graphiques dédités. Et comme tu me dis que subversive n'est pas encore au top... je crois que je ne vais pas l'utiliser pour le moment.
> autant je suis convaincu par Eclipse quand il s'agit de faire du Java, autant Eclipse pour c++ ne m'a jamais vraiment satisfait.
Ce n'est pas génial, mais ça le fait. C'est plus facile d'accès qu'Emacs, on se balade plus facilement dans l'arborescence des fichiers, c'est adapté à l'utilisation de make, etc.
Je suis globalement très satisfait. J'ai durant 3 ans utilisé Xemacs (il y a longtemps). Maintenant je préfère Eclipse sans l'ombre d'un doute.
> Finalement, il y a beaucoup d'instabilité entre tous les plugins que l'on assemble pour faire un IDE "perso".
Pour la partie C++/make, je suis très satisfait et je n'ai pas de problème (il y a bien 1 ou 2 petits glitchs).
> L'autocomplétion c/c++ ne vaut pas celle d'un omnicompletion
J'ai bien remarqué que l'autocomplétion ne marchait pas nickel, mais ça ne me dérange pas trop (du moins pour le project sur lequel je suis).
> et en règle générale, l'interface est très lourde.
C'est indiscutablement vrai. Peut-être que ça me dérange peu car il y a encore beaucoup de chose que je fais en ligne de commande.
Mais il faut juger l'ensemble. Es-ce que Emacs est mieux ? Pas pour moi. Il y a des menus à n'en plus finir, des tonnes de raccourcis claviers à retenir, la navigation dans les sources n'est pas pratiques, la doc d'eclipse est plus accessible, etc...
Globalement j'adore Eclipse même pour le C++, même si ce n'est pas dans ce language qu'il exprime le meilleur de son potentiel.
Par exemple tu me parles de Mylyn (que je ne connais pas). Je vais regarder de près Mylyn car je veux que bugzilla ait une place centrale dans mon développement (j'aime peu Tracks pour son mélange des genres (wiki, doc, gestionnaire de version, de bug, de planning...).
Es-ce que Mylyn existe sous Emacs ?
Autre aspect important, eclipse marche quasi à l'indentique sous Linux et sous Windows. Il s'installe avec la même facilité aussi, on y retrouve les même fonctionnalité. C'est un gros gros plus quand on développe sous Linux et Windows (comme je le fais actuellement).
Peux tu me confirme que tu penses du bien de Mylyn ?
J'ai survoler le lien que tu m'as donné et ça semble très "cool".
As-tu un avis sur la partie "gestion de planning" ?
Merci pour toutes ces infos.
PS : j'utilise Eclipse depuis plus de 6 mois.
[^] # Re: Le java, oui, le c++ ferrugineux, non
Posté par Val1472 . Évalué à 1.
Maintenant Je ne l'utilise pas sur un autre projet en c/c++ et ça ne me gène pas beaucoup plus que ça.
Comme c'est un outil un peu particulier qui conditionne ta façon de travailler, le mieux est de l'essayer et de se faire une idée "personnelle". C'est un peu pour ça que je n'ai pas donné mon avis sur la question. :)
[^] # Re: Le java, oui, le c++ ferrugineux, non
Posté par IsNotGood . Évalué à 1.
J'ai presque fini d'installer bugzilla, après je teste Mylyn
Il me faut quelque chose pour la gestion et la communication (d'où bugzilla (+ mailing list)).
Si je peux attaquer bugzilla depuis eclipse via une interface sympa (Mylyn), c'est un plus.
Et Mylyn gère d'autres trucs sympa pour le développeur (pas indispensables, mais sympa).
Ici encore, je ne veux pas que le projet soit dépendant d'Eclipse. Eclipse ne fait "que" IDE.
Je vais oublier ce qui est lié à xplanner car çe ne me semble pas une plus pour mon projet.
# Comprends pas
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
> pdf, etc) sous Eclipse.
> La traduction vers html, pdf, etc sera faite avec docbook-util (parfait
> avec un Makefile).
C'est exactement ce que je fais toujours. J'ai horreur des IDE en règle générale car il t'enferme dans leur manière de travailler et si tu les quitte, t'es bon pour en apprendre un autre.
Tu l'as dis toi même, le reste est fait avec un Makefile. Il suffit ensuite de rajouter dans l'IDE, quel qu'il soit, le lancement de la commande 'make' et c'est bon.
En plus, le Makefile est dans le dossier de travail et se retrouve versionné. Que du bon.
Au bilan, je ne comprends finalement pas trop ce que tu cherches puisque tu donnes toi même la réponse à la question.
[^] # Re: Comprends pas
Posté par IsNotGood . Évalué à 2.
La méthode de référence pour construire la doc sera docbook-utils (utilisable depuis make). C'est moi qui le fait et sous Linux. Pour l'édition, Eclipse est une possibilité (moi je vais utiliser Eclipse). Par contre il y aura d'autres personnes (en fait une seule autre personne allergique à Linux :-)) qui vont éditer la doc et il faut qu'ils aient un "preview" en html et/ou pdf. Ceci doit pouvoir être fait avec Windows. Si on peut le faire avec Eclipse, alors ça marchera partout où Eclipse tourne (et donc Windows).
Il faut que je propose au moins une solution pour faire les "preview" sous Windows. Si après l'autre veut utiliser autre chose que Eclipse, c'est ses oignons.
On doit pouvoir installer docbook-util sous Windows. Mais après c'est un peu le "bordel" pour celui qui veut seulement éditer du docbook (il faut installer cygwin, il faut qu'il utilise Make, etc). Avoir une solution que ne demande que eclipse pour l'édition (+ preview) est un gros plus.
NB: l'autre personne qui va s'occuper d'une partie de la doc, n'est pas du tout un développeur.
> Il suffit ensuite de rajouter dans l'IDE, quel qu'il soit, le lancement de la commande 'make' et c'est bon.
C'est exactement ce que je fais. Il y a même des trucs que je fais hors Eclipse car c'est plus efficace de le faire à coup de grep/sed/vim/make.
[^] # Re: Comprends pas
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Personnellement, j'ai abandonné docbook car c'était trop 'chiant'. Mon opinion personnelle est que si on veut écrire des documents, il faut privilégier le texte et qu'il soit facile de baratiner des paragraphes... Or le XML est vraiment inhumain, même au niveau des paragraphe (la dessus, docbook est encore plus pénible que le XHTML).
En science, on fait quasiment tous du TeX (sauf les maso qui écrivent sous MS Office) et cela marche super bien tant sous Linux que MacOS-X, que sous Windows. Au moins, c'est un soucis en moins pour l'administrateur système.
Pour en revenir au sujet, si la doc concernant le programme est 'facile', c'est à dire n'utilise que quelques balises, pourquoi ne pas utiliser une syntaxe de type Wiki ? J'ai fait cela dans le passé en mettant toute la doc sous le format POD (doc de Perl). L'avantage est que le format POD est facile à comprendre et qu'un simple
perldoc mon_fichier_de_doc
Et on a le résultat. Encore une fois, c'est muti-OS, pérenne (le POD est à mon sens plus pérenne que pas mal de format Wiki qui traine ici ou la), simple pour l'utilisateur et ne prends pas trop de temps pour l'administrateur système.
Sinon, on utilise aussi TRAC ou SPIP pour la doc. Cela marche plutôt bien mais ne marche pas dans le TGV ;-)
[^] # Re: Comprends pas
Posté par IsNotGood . Évalué à 2.
Mais il y a quelques problèmes.
Par exemple faire une belle documentation pdf avec wiki est un défit. En général il peut faire un pdf par page wiki.
Autre problème, wiki n'est pas très adapté avec un gestionnaire de version. D'accord wiki a un gestionnaire de version. Mais c'est par page.
Autre problème, comment faire pour bien synchroniser une traduction (on veut faire une doc en français et une en anglais). Avec Docbook c'est possible et dans le même fichier (il faut que je valide la solution que j'envisage).
Ça donnera un truc dans ce goût :
<section>
<title lang="fr">Amusant</title>
<title lang="en">Fun</title>
<para lang="fr">Je veux te tuer !</para>
<para lang="en">I want to kill you !</para>
</section>
Si on veut faire un fichier .chm pour Windows, ça se fait assez facilement avec Docbook.
Enfin, j'ai lu des longues discutions sur la mailing documentation de Fedora pour voir s'il y avait une alternative au "lourdingue" Docbook. Rien de sérieux a été trouvé.
Docbook n'est pas si compliqué que ça. Par contre sa mise en oeuvre (les divers bidules à installer) est assez pénible.
Eclipse (ou pgsml d'emacs) rend l'édition docbook assez simple (validation en un clique, format en un clique, convertit en entité xml automatiquement si c'est nécessaire, liste des balises ou attributs autorisés en fonction du contexte en un clique, une petite fenêtre qui indique la structure du document pour y naviguer rapidement, etc).
J'ai fait le choix Docbook, il y a du subjectif.
Wiki a des atouts indéniables. Par contre restructurer un document avec wiki est assez casse couille. La navigation dans le document aussi (au faut coder des trucs). Avec Docbook ça se fait les doigts dans le nez.
[^] # Re: Comprends pas
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
> version. D'accord wiki a un gestionnaire de version. Mais c'est par
> page.
J'ai parlé de syntaxe wiki et pas forcément de wiki web.
J'ai ensuite évoqué le format POD qui est une forme de syntaxe wiki (en généralisant) mais il y a aussi par exemple textile...
Avec Textile, tu écrit en wiki mais tu peux transformer cela en XML si tu veux donc en docbook. Steve Kemp a par exemple écrit 'chronicle' qui transforme des fichiers textile en blog ce qui permet, entre autres, d'avoir un blog statique.
Ensuite, que ce soit du docbook ou un autre format, ta doc est répartie sur plusieurs fichiers.
> Docbook n'est pas si compliqué que ça. Par contre sa mise en
> oeuvre (les divers bidules à installer) est assez pénible. et sera
> versionnée ligne par ligne.
C'est marrant car c'est souvent ce que je lis ici alors que je pense l'inverse. Sur une debian, il suffit d'installer quelques paquets pour avoir un compilateur docbok qui marchent bien. Bref, c'est pas plus dur que LaTeX ou OpenOffice voir plus simple (car moins de paquet).
Ce que je trouve compliqué, c'est le nombre de balise et de devoir les ouvrir et les fermer pour le moindre truc. Ton exemple bilingue est à mon sens significatif, c'est lourdigue. Je me vois mal faire un document de 200 pages ainsi.
A vrai dire, je n'ai pas de bonne idée pour le multilingue à par faire un truc du genre
intro.fr.tex
intro.us.tex
et ainsi de suite... mais c'est pas terrible à synchroniser ! C'est même pénible.
Sinon il reste ta solution qui fonctionne aussi dans les autres formats. J'avoue que je suis intéressé par une méthode générique qui marche bien dans la vrai vie.
[^] # Re: Comprends pas
Posté par IsNotGood . Évalué à 1.
Ce n'était qu'un exemple. Tu peux faire deux fichiers séparées si tu veux. On peut aussi faire deux documents séparés évidemment.
Tu peux aussi faire un truc dans ce gout :
<section lang=fr>
<title">Amusant</title>
<para>Je veux te tuer !</para>
[plein de blabla]
</section>
<section lang=en>
<title>Fun</title>
<para>I want to kill you !</para>
[plein de blabla]
</section>
> Sur une debian, il suffit d'installer quelques paquets
Sur toutes les distributions c'est comme ça. Juste pour t'énerver :-) j'ai seulement fait :
# yum groupinstall "Authoring and Publishing"
Mais sous Windows c'est une autre histoire (d'où le fait que je suis interessé pour faire marcher ça aussi sous Eclipse).
J'ai bien regardé du côté de MoinMoin qui peut faire aussi du Docbook ou pdf, mais il y a toujours un petit truc qui coinse (en plus de ne pas avoir vraiment la doc dans un gestionnaire de version, le bilingue, arrivé à faire un seul pdf pour toute la doc, etc).
J'ai aussi regardé du côté de Drupal et tikiwiki.
Pour le site web (qui sera modeste), je vais probablement utiliser un wiki ou dotclear (j'ai un faible pour dotclear).
Je le redis, j'ai fait le choix Docbook, il y a du subjectif. Si mon boss me dit d'utiliser un truc type Wiki ou POD, ben je le prendrais sans protester.
[^] # Re: Comprends pas
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
> # yum groupinstall "Authoring and Publishing"
Il en faudrait bien plus ;-) En plus, je viens de me défouller les doigts sur mon accordéon donc je suis hyper ZEN.
A vrai dire, j'ai pris l'exemple de Debian car c'est la seule ou je me trouve compétent, mais je n'ai rien de particulier contre les autres.
Au sujet de docbook, tu fait bien comme tu veux et surtout, il faut savoir profiter de ses connaissances pour être efficasse de suite. C'était pour le débat. J'aime pas spécialement le docbook mais cela n'a que peu d'importance...
Ce qui me casse par contre les pieds, c'est lorsque l'on me sors des fichiers de config dans /etc en XML. J'ai vu cela encore cet après midi en suivant l'un des liens du journal sur PostGreSQL
http://linuxfr.org/~ioguix/25631.html
Il s'agit de Cybercluster, un moyen de clusteriser postgreSQL
http://www.postgresql.at/english/downloads_e.html
Lorsqu'on voit le fichier de configuration en XML, on se dis qu'un YAML ferait la même chose en plus simple.
[^] # Re: Comprends pas
Posté par IsNotGood . Évalué à 2.
Certe XML partout n'est pas une solution à tout.
Mais c'est bien pratique pour les développeurs, la compatibilité, l'interropérabilité, etc...
Faire son parseur à la main c'est sympa mais qu'une fois.
Normalement les fichiers xml ne doit pas être édité à main (même si c'est possible).
Pour docbook il y a des éditeurs pro :
http://www.xmlmind.com/xmleditor/
http://www.xmlmind.com/xmleditor/flash_demos/demo1.htm
Je n'ai pas essayé la version personal edition. Mon projet est commercial. Mais peut-être qu'on se prendra la version pro si la voie Docbook est validée. Mais pour l'instant c'est trop tôt.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.