Journal Un fichier standardisé pour décrire un projet

Posté par Mildred (site web personnel) le 24 juillet 2005 à 00:22.

Étiquettes : aucune

juil.

2005

Il y a quelques temps, j'ai remarqué un journal d'une personne qui avait voulu réparer un bug mais avait passé plus de temps a adapter le projet à son environnement de développement qu'a réparer le bug en question [1].
Et juste maintenant je me met à étudier les sources de mpd [2] pour implanter une fonctionnalité qui jusqu'a présent me manque.

Et je me disais qu'il pouvait être intéressant de normaliser un format de fichier de projets. Ainsi, les Environnements de Devloppement Intégrés pourraient sans problème importer des projets.
Qu'en pensez-vous ?

[1] http://linuxfr.org/~artefact/18651.html(...)
[2] http://www.musicpd.org(...)

# Y a pas que les IDE dans la vie...

Posté par ahuillet (site web personnel) le 24 juillet 2005 à 00:33. Évalué à -3.

Tout est dans le titre.

Qu'est-ce qu'un IDE est censé faire ? Ouvrir tous les fichiers .c ou .cxx ou .whatever d'un répertoire donné dont le nom est le nom du projet, builder en invoquant make, ... Il y a vraiment besoin d'un fichier de projet pour ça ?!
# Dans le même style

Posté par pifou le 24 juillet 2005 à 00:51. Évalué à 2.

J'avais pensé à une sorte de RSS pour décrire un projet de façon simple et homogéne. Par contre ce n'était pas pour faciliter l'intégration dans un IDE mais plutôt pour permettre d'avoir dans un seul fichier standardisé les liens vers les descriptions, les documentations, les nouvelles, les dépendances, les packages ... Je voyais une structure XML bien conçu pour gérer différents types de projet (librairies, scripts, petits programmes, gros programmes contenant des sous-programmes ou modules ...) et donc différentes sections obligatoires/facultatives (contenant soit du texte ou des liens).

Cela permettrer de facilement écrire un freshmeat like avec plus d'infos en donnant juste pour l'ajout d'un nouveau projet un lien vers le fichier XML comme on le fait avec les RSS.

D'un autre coté, je n'ai pas cherché si ça existait déjà, donc si quelqu'un connait quelque chose se rapprochant de ce que j'ai décrit, je l'invite cordialement à se manifester :).
- [^] # Re: Dans le même style
  
  Posté par Bruno Coudoin (site web personnel) le 24 juillet 2005 à 01:34. Évalué à 1.
  
  Il exitset releaseforge par exemple pour les release de projet sourceforge. Il existe un script aussi pour freshmeat (j'ai pas le lien sous la main).
  http://freshmeat.net/projects/releaseforge/?branch_id=57091&rel(...)
  
  Enfin, ca concerne la partie release du projet.
  
  Pour le projet lui meme, les auto tools de GNU me semblent bien adaptée.
  Un fichier configure.in décrit bien l'ensemble de ton projet et ses dépendances. Les makefile.am permettent de le compiler.
- [^] # Re: Dans le même style
  
  Posté par Sytoka Modon (site web personnel) le 24 juillet 2005 à 09:18. Évalué à -2.
  
  Et pourquoi pas au format YAML. Personnellement, le XML me "gonfle" lorsqu'il s'agit de faire des fichiers de configuration. Avec le YAML, on a quasiment la même chose, mais avec une orientation humaine...
# Comme ca

Posté par Mildred (site web personnel) le 24 juillet 2005 à 07:19. Évalué à -4.

Juste un exemple ...
voir la source pour avoir l'indentation

<?xml version="1.0" charset="utf-8"?>
<project
xmlns="http://purl.org/NET/louve/2005/ref/project/v240702/main/"
xmlns:c="http://purl.org/NET/louve/2005/ref/project/v240702/c/"
xmlns:i="http://purl.org/NET/louve/2005/ref/project/v240702/install/"
xmlns:l="http://purl.org/NET/louve/2005/ref/project/v240702/launcher/">
<files>
<c:header c:name="stdio.h" id="stdio_h" />
<dir name="src" id="srcdir"> 
<c:executable c:name="exe" id="executable">
<c:object c:name="main">
<c:source c:name="main.c">
<c:include c:name="misc.h" />
<file idhref="stdio_h" />
</c:source>
</c:object>
<c:object c:name="misc">
<c:source c:name="misc.c">
<file idhref="stdio_h" />
</c:source>
</c:object>
<c:library c:name="c" c:version_min="6.2" version="6.*" />
</c:executable>
</dir>
</files>
<install>
<dir name="libdir">
<file idhref="executable" />
</dir>
<dir name="bindir">
<l:launcher>
<l:execute l:idhref="executable">
<l:envvar l:name="" l:value="" />
<l:pwd l:path="bindir" />

<l:icon l:file="src/icon.png" />

<l:param l:value="--file" />
<l:param l:idhref="stdio_h" />
</l:execute>
</l:launcher>
</dir>
</install>
</project>
# Maven ?

Posté par Miguel Moquillon (site web personnel) le 24 juillet 2005 à 10:36. Évalué à 2.

Quelque chose comme Maven ?
http://maven.apache.org/(...)

Actuellement, Maven est plutôt centré sur Java, mais rien n'empêche d'écrire des plugins Maven pour supporter d'autres langages, comme d'ailleur des tâches ant peuvent être écrites pour la gestion d'autres langages que Java.
- [^] # Re: Maven ?
  
  Posté par Sytoka Modon (site web personnel) le 24 juillet 2005 à 14:26. Évalué à 1.
  
  Avec le bout d'exemple d'un post ci-dessus, c'est typique des nouveaux outils dérivée d'ANT. Du XML partout. C'est super pour les IDE mais horrible pour l'homme.
  
  Honnêtement, un bon vieux Makefile peut être bien plus lisible. Le plus gros défaut du Makefile à mon avis, c'est la tabulation en début des lignes de commande. Je ne comprends pas qu'on ne puisse dire que les lignes commançant par '->' soient équivalentes aux lignes commençant par une tabulation.
  
  L'inconvénient des outils intégrés autour du XML, à part la mauvaise lisibilité, est le manque de souplesse. Ce qui est génial dans un Makefile est le mélange de deux langages dont l'un est très souple et peut être changé (variable SHELL). Rien n'empêche de développer des scripts 'a la Ant' qui rendrait la compilation pour certains langages plus claire que dans un Makefile actuel. Il n'y a pas besoin de se mouler dans un environnement de type Java comme dans Maven ou Ant.
  
  Enfin, j'en remet une couche sur le YAML. Faites du YAML pour vos fichiers de données (configurations ou résultats) qui doivent pouvoir être ouvert par un éditeur et non du XML ;-).
  - [^] # Re: Maven ?
    
    Posté par Mildred (site web personnel) le 24 juillet 2005 à 18:13. Évalué à 1.
    
    L'avantage du xml: les namespaces.
    On peut étandre le language très facilement.
    l'inconvénient: la redondance des informations
    
    l'avantage des Makefiles: c'est pratique, rapide, des jolies tabulations qui rendent obsolètes tous les éditeurs de texte qui ne savent mettre que des espaces lorsqu'on appuie sur tab.
    Dailleurs, je ne vois pas l'intérêt des espaces, a part que cela prend plus de place que des tabulations. Si les tabulations sont trop grandes, on peut en changer la longeur dans tout bon editeur de texte.
    l'inconvénient majeur: ce n'est pas portable. Mais pas du tout !!!
    
    Ce n'est pas que je veuille mettre du XML partout mais pour ce cas précis, cela m'a paru très adapté a cause de la structure très hierarchisée des données ET parce que c'est modulaire.
    On peut rajouter facilement de nouveaux languages en ajoutant un namespace.
    Et si je devais faire une application qui gère ce type de fichier. Je passerait par les Makefile sous Unix.
    
    Notez aussi que je cherche une alternative aux autotools ... En dehors de n'être que peu portable au delà de l'univers Unix, ils créent des Makefiles illisibles.
    Et lorsqu'on veut changer une option de compilation, il faut relancer le ./configure qui n'est pas assez intelligent pour retrouver les valeurs détectées lors d'un précédant ./configure
    Enfin, ils fournissent au logiciel des chemins absolus (vers les données par exemple). Ce qui fait que si on a envie de changer le logiciel de place, on doit dans certains cas le recompiler.
    je préférerais un simple script shell qui crée des variables d'environnement pour donner lemplacement des données et lance le binaire.
    
    Et si vous avez un meilleur format de documents (que le XML) pour représenter des données hierarchisées et de manière modulaire, je veux bien que vous m'en fassiez part. (sans ironie)
    - [^] # Re: Maven ?
      
      Posté par Sytoka Modon (site web personnel) le 25 juillet 2005 à 00:00. Évalué à 1.
      
      Il existe par exemple aap, c'est écrit en Python et ca utilise une syntaxe voisine du makefile.
      
      http://www.a-a-p.org/
      
      Je ne dis pas que je suis fanat non plus ;-) La syntaxe est plus humaine mais à mes derniers essais, il faut écrire des extensions en Python si on souhaite l'étendre. Or je ne suis pas un fan de Python par gout personnel.
      
      Le fichier 'rules' des paquets debian est un exemple de Makefile travaillé avec des extensions par scripts. On se retrouve avec un Makefile relativement simple au bout du compte.
      
      Mais bon, il y a une mode XML...
      
      Sinon, je n'ai pas fait de namespace en YAML car il est vrai que je l'utilise dans des cas assez simple. Mais tout structure arborescente peux s'écrire en YAML tout comme en XML. Donc il est possible en théorie de faire un outils 'yml2xml' et réciproquement.
  - [^] # Re: Maven ?
    
    Posté par Miguel Moquillon (site web personnel) le 24 juillet 2005 à 19:14. Évalué à 0.
    
    On peut ou aimer ou non le XML. L'avantage de ce dernier est de pouvoir être utilisé quelque soit la plate-forme, ce qui n'est pas le cas des Makefiles.
    
    Les fichiers XML pour Maven ou Ant ne sont pas dédiés aux IDE ou AGL mais permettent au contraire une indépendance à ces derniers. A la charge de ceux-ci d'intégrer ou non l'architecture de build via Ant ou celle de projet via Maven. Dans mon cas, j'utilise ant en ligne de commande et non via un IDE et les fichiers ant que je construit peuvent être utilisés aussi bien par ceux qui développement avec NetBeans, Eclipse ou en encore Emacs (avec JDEE).
    
    Par contre, quant aux points positifs et négatifs entre Makefile et fichiers de build XML, je suis dans l'ensemble d'accord avec tes avis.
    Je rajouterais ceci : dans des projets conséquents, les Makefiles peuvent devenir assez rapidement illisible, ce qui n'arrive que trop rarement avec les document en XML de par leur nature.
# DOAP

Posté par Olivier Grisel (site web personnel) le 24 juillet 2005 à 10:38. Évalué à 3.

DOAP est un vocabulauire RDF standardisé pour la description de projet.

http://usefulinc.com/doap(...)
http://doap-fr.org/(...) (communauté francaise)

Il existe de plus en plus d'outils pour générer et lire automatiquement du DOAP.

Je sais pas si c'est suffisamment expressif de base pour décrire toutes les infos dont un IDE a besoin, mais c'est justement l'avantage du RDF : c'est modulaire, on peut melanger plusieurs vocabulaires dans une meme description. Donc pourquoi pas un voc pour les specificités eclipse, un voc pour les specificité KDevelop, ...

Pour les pythonistes, une excellente lib pour traiter le RDF de manière automatisée (parsing, requetes, génération, ...) : http://www.rdflib.net(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.