Journal X.org et la modularisation

Posté par  .
Étiquettes : aucune
0
21
mai
2005
La prochaine release de X.org sera modulaire[1,2,3].
En fait on aura 2 releases pour le prix d'une : la 6.9, qui sera toujours sous la forme que l'on connaît (à savoir un bon gros arbre monolithique) et la 7.0 qui devrait avoir exactement le même contenu que la 6.9, mais qui aura l'attrayante propriété d'être allée faire un tour chez nos "amis" autotools.

C'est en effet ce qu'il y a dans les cartons de X.org pour réaliser la transition.
On ne va pas rappeler (tous) les avantages d'une modularisation (barrière plus basse pour les nouveaux arrivants, possibilité de ne travailler que sur un tout petit morceau du code sans gêner trop de monde et sans avoir à connaître trop du reste du monde,...) mais il est aussi intéressant de connaître tous les désavantages.
La plupart des développeurs X.org sont bien habitués à Imake et pour eux la transition va sans doute être un peu douloureuse (en fait comme toute transition, hein). Il fallait donc attendre (ou être sûr) qu'il y aurait assez de devs maîtrisant suffisamment les 2 (Imake+autotools).
De plus, et au début tout du moins, certaines architectures seront mises de côté lors de la transition s'il n'y a pas assez (ou pas du tout) de développeurs pour assurer la transition (et réaliser les changements nécessaires).
Enfin, il faut bien voir que les autotools sont extrêmement "version dépendants" et que certaines plateformes n'auront pas *la* version qu'il faut... Sans parler des dépendances cachées qui peuvent être introduites lors de l'autodétection (pendant le ./configure) quand le gentil développeur (GD) vérifie que tout compile (et tourne) comme prévu. (Leur stratégie pour contrer cela, c'est de spécifier très exactement les dépendances dans le build-script... Moi je leur conseillerais bien CMT[4] à la place :)

Apparemment, il y a eu une vraie démarche qualité la-dessus, ou en tout cas une vraie réflexion et un vrai travail préparatoire. La casse devrait donc être très limitée.

Pour finir sur les développements, j'ai découvert qu'il semblerait que les gens bossent sur un hotplug pour X11[5] : c'est pas la classe ça ?!

A noter que le dernier snapshot en date est labellé "xorg-x11-6.8.99.7" :
Bye-bye 6.8 !
Hello 6.9/7.0 !!

[1] : http://wiki.x.org/wiki/ModularizationWorkingGroup(...)
[2] : http://wiki.x.org/wiki/ModularizationProposal(...)
[3] : http://wiki.x.org/wiki/ModularizationDevelPlan(...)
[4] : http://www.cmtsite.org(...)
[5] : http://wiki.x.org/wiki/XInputHotplug(...)

PS: non, je n'ai pas trouvé de date de sortie... Même s'il est à peu près sûr qu'il y aura une 6.8.3...

  • # autotools ?

    Posté par  (site web personnel) . Évalué à 5.

    Je suis surpris qu'ils aient choisi autotools. Il y a quelques annees, la question ne se posait pas, mais aujourd'hui, il y a un certain nombre d'alternatives qui pointent leur nez et qui ont l'air tres interessante (citons scons par exemple).

    A l'heure ou KDE envisage de se debarasser d'autotools, j'espere qu'ils ont bien reflechi a la chose.

    • [^] # Re: autotools ?

      Posté par  . Évalué à 4.

      Moi aussi ça m'a intrigué mais c'est ce qu'il y a de plus éprouvé sur le marché (et la solution pour laquelle il y a le plus d'expertise)...

      En effet : ne serait-ce pas un peu une espèce de gros saut dans le vide de se marrier avec SCons ?
      Je veux dire que pour un gros projet comme X.org, faut être sûr de ce que l'on fait et pas prendre le "premier remplaçant" venu qui va enterrer automake et consort.

      Et puis une fois modularisé, ce n'est "que" le mécanisme de build qui change. Hum. Enfin, sur le papier.

      Prendre SCons ou unsermake à ce stade de leur développement me semble un peu prématuré quand même, non ?

  • # Bon pour Debian

    Posté par  (site web personnel) . Évalué à 5.

    En tout cas c'est une bonne nouvelle pour tous les utilisateurs de Debian.
    Les développeurs attendaient en effet cette modularisation pour pouvoir switcher completement de XFree vers Xorg (meme si certaines choses avaient déja été portées de Xorg vers Xfree sur Debian).

    • [^] # Re: Bon pour Debian

      Posté par  . Évalué à 4.

      oui, et sa devrait permettre d'eviter les update de 100Mo des qu'il y a la moindre modif dans X...

  • # Et plus tard ?

    Posté par  . Évalué à 3.

    Les développeurs vont-ils continuer à entretenir deux branches pour les prochaines versions (la monolithique et la modularisée) ou la version monolithique est condamnée d'ici à la version 7.1 ?

    • [^] # Re: Et plus tard ?

      Posté par  (site web personnel) . Évalué à 2.

      normalement, si j'ai bien compris le document expliquant la roadmap, la prochaine version sortira de 2 façon, une monolithique (6.9) et une modulaire (7.0). Ensuite, le développement ne se fera plus que sur la branche modulaire.

  • # CMT ???

    Posté par  . Évalué à 1.

    Je soupçonne cmt d'être une grosse merde made in IT HEP, qui ne fonctionne que dans l'environnement très particulier de l'HEP ... Autotools est loin d'être parfait. Disons que c'est le meilleur du pire à l'heure actuelle. Je voudrais bien quelque chose de mieux. Mais je vois rien de sérieux comme alternative. Les Autotools sont largement utilisé, donc générique, et bien documenté.

    • [^] # Re: CMT ???

      Posté par  . Évalué à 2.

      une grosse merde made in IT HEP
      Ahah... Et ben ça dénigre sévère :P
      C'est pas parce que ROOT sucks que tout HEP sucks.

      Mais : perdu ! C'est une appli développée par le meilleur laboratoire de physique des particules de l'Univers connu et inconnu : le LAL[*] ;)

      De plus CMT est une "surcouche" au dessus des Autotools. Il génère à la volée les makefile nécessaires à partir d'un fichier requirements dans lequel sont définis les packages dont dépend le package que tu es en train de compiler. Et il ne recompile que ce qui est nécessaire.

      Disons que c'est le meilleur du pire à l'heure actuelle
      Je dirais plutôt que c'est le moins pire de ce qu'il y a à l'heure actuelle :P

      Les Autotools sont largement utilisé, donc générique, et bien documenté.
      Ben ATLAS et LHCb utilisent quotidiennement CMT. Ça fait du monde quand même, même si je te le concède, moins que tous les projets opensource de part le monde qui utilisent les autotools.

      qui ne fonctionne que dans l'environnement très particulier de l'HEP
      Plateformes : http://www.cmtsite.org/CMTDoc.html#Supported%20platforms(...)
      C'est pas trop mal comme environnement particulier spécifique HEP.

      [*] S'il y a un ponte du LAL qui passe par là (ce dont je doute quand même fortement), je cherche un poste permanent :) Et j'espère que vous apprécierez la valorisation que je fais de votre laboratoire et de son travail.

      • [^] # Re: CMT ???

        Posté par  . Évalué à 2.

        Ben ATLAS et LHCb utilisent quotidiennement CMT, ça fait du monde quand même,

        Sa représente 0.0000...1% des cas d'utilisations. Et vue le genre de tordues, je dirais plutôt 0%. D'ailleurs, le LAL est spécialisé dans le développements de framework utilisé par personne. C'est pas parce que ça compile un type de soft sous SL ou Red Hat, que on peut l'utiliser pour 99.99999...9% des autres cas. Ils suffit de voir la convention des répertoires pour comprendre que c'est du 100% génie HEP. D'ailleurs les besoins sont un peu particulier. Pkgconfig par exemple, n'a pas été conçue pour gérer plusieurs version d'un même package, tout simplement parce que sa n'a pas de sens d'avoir 10 versions de Gnome. Par contre, sa un sens en HEP.

        • [^] # Re: CMT ???

          Posté par  . Évalué à 2.

          Sa représente 0.0000...1% des cas d'utilisations
          Boah... Si compiler un projet tel qu'Athena[1] (le soft d'ATLAS qui a une grosse base en C++ plus plein de petits modules en Fortran, Java, Python, XML,...) représente un poullième des cas d'utilisations...

          Ce que l'on veut c'est un truc qui :
          - compile des machins
          - recursivement
          - gère les dépendances cycliques
          - ne recompile que ce qui a changé depuis la dernière fois
          - gère l'ordre de compilation entre les packages (à partir de leurs relations de dépendance)
          - soit facile à comprendre même pour des physiciens qui n'ont pas tous la science du Makefile...

          Ben je crois que CMT remplit ce cahier des charges. Tu peux même gérer la géneration de bindings C++->Python, compiler ton thesis.tex, utiliser distcc, parler avec ton repository CVS/SVN, intéroger en interactif les dépendances que tu utilises...
          Mais surtout il permet d'avoir le même environement de développement pour tout le monde.

          D'ailleurs, le LAL est spécialisé dans le développements de framework utilisé par personne.
          Ça va être dur le recrutement ;)

          Ils suffit de voir la convention des répertoires pour comprendre que c'est du 100% génie HEP
          Comprend pô.

          [1] : http://atlas-sw.cern.ch/cgi-bin/viewcvs-atlas.cgi/offline(...)

          PS : je n'ai pas d'actions dans CMT (c'est libre) mis à part les impôts que je paye

Suivre le flux des commentaires

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