La bibliothèque SDL est sortie en version 2.0

50
21
août
2013
Jeu

SDL (Simple DirectMedia Layer) est une bibliothèque multiplateforme orientée vers les jeux vidéo.

Elle permet de gérer la majorité des aspects nécessaire au développement afin de rendre le code portable. Elle fournit ainsi des API pour prendre en charge l'affichage, le son, les différents événements d'entrée (clavier, manette, souris…), les interactions avec le gestionnaire de fenêtre ; ainsi que des bibliothèques optionnelles de facilité (pour le réseau, les polices de caractère, les formats d'images, le mixage de son).

Après une très longue période de maturation, SDL 2.0 arrive enfin ! Pour cette version 2, en plus d'un mise à niveau majeure de l'API, la licence passe de la LGPL v2 à la licence zlib afin de faciliter son adoption.

Logo SDL

Les principaux changements

Plate-forme

Le support officiel des plate-formes iOS et Android est assuré. On notera également une mise à niveau de l'API pour profiter des spécificités de tels matériels comme les écrans tactiles, le niveau de batterie, ou l'utilisation du clavier virtuel.

Les plate-formes OS/2 et Mac OS 9 ne sont actuellement plus supportées, mais les patchs sont les bienvenus.

Sous Linux, SDL est traditionnellement conçu pour fonctionner avec un serveur X via la bibliothèque Xlib, mais des portages de la communauté sont en cours pour Wayland et pour Mir.

Binding

La bibliothèque est écrite en C et ne dispose pour le moment que de quelques bindings : pour Python, Pascal et C#. Nul doute que la situation va évoluer pour prendre en charge l'éventail de son ancêtre.

Système

Vidéo

  • API 3D (OpenGL 3 avec différents profils, OpenGL ES) ;
  • API 2D accélérée matériellement ;
  • gestion des contextes OpenGL ;
  • meilleure gestion du plein écran.

Périphérique d'entrée

  • gestion de plusieurs périphériques d'entrée ;
  • gestion de la connexion à chaud de périphériques (ControllerDeviceEvent)
  • gestion du retour de force dans les joysticks ;
  • gestion des molettes de souris horizontales ;
  • API pour mapper les contrôleurs
  • gestion du multipoints.

Son

  • gestion des systèmes sonores 7.1 ;
  • gestion de plusieurs périphériques audio ;
  • gestion de la capture audio ;
  • l'API de lecture de CD audio a été retirée.

Logo SDL 2.0

Recommandé pour les portages Linux

La bibliothèque SDL est, entre autre, maintenue par Sam Lantinga (précédemment chez Loki Software, puis Blizzard Entertainment) qui est aujourd'hui chez Valve Software. Steam, et les portages des jeux Valve utilisent évidement SDL. Le dernier, non le pire (enfin… les goûts et les couleurs) doit être Dota 2.

Dans une récente conférence présentée en polonais mais aux diapos en anglais, Leszek Godlewski (de The Farm 51) recommande d'utiliser SDL et Steam Linux runtime pour porter des jeux vers Linux.

  • # SFML

    Posté par (page perso) . Évalué à 10.

    Juste un commentaire pour appeler à l'aide pour compléter la dépêche sur la version 2.0 de la SFML, qui est sortie il y a un moment maintenant : http://linuxfr.org/redaction/news/la-bibliotheque-sfml-est-sortie-en-version-2-0
    La SFML étant en concurrence avec la SDL ça me paraissait approprié.

    • [^] # Re: SFML

      Posté par (page perso) . Évalué à 0.

      Ils ne sont pas du tout en concurrence, l'un est un outil pour utiliser plus facilement le second (ou son pote openGL si le cœur nous en dit). La crème chantilly n'est pas en concurrence avec la boule de glace au chocolat.

      • [^] # Re: SFML

        Posté par . Évalué à 5.

        Ils ne sont pas du tout en concurrence, l'un est un outil pour utiliser plus facilement le second

        Non.
        Jusqu’à preuve du contraire, la SFML n‘est pas basée sur la SDL.

        • [^] # Re: SFML

          Posté par (page perso) . Évalué à 2.

          Ah oui en effet. Au temps pour moi, je croyais vraiment qu'elle s'occupait d'OpenGL ET de SDL.

  • # Tutoriel d'installation et de création d'un premier projet SDL 2.0

    Posté par . Évalué à 8.

    Bonjour à tous,

    Si vous souhaitez vous lancer rapidement dans cette nouvelle version de la bibliothèque de jeux, vous pouvez découvrir un tutoriel tout en français sur sa compilation, son installation et sa configuration au sein d'un projet : http://alexandre-laurent.developpez.com/tutoriels/sdl-2/installation-et-configuration/

    En espérant voir de nouvelles création avec cette bibliothèque :)

  • # Comment ça se passe du côté de Pygame ?

    Posté par (page perso) . Évalué à 4.

    je n'ai encore jamais utilisé, mais ça m'intéresse quand même: est que pygame supporte SDL 2.0, ou est-ce que c'est en cours ? Sur leur site ils félicitent les auteurs de SDL 2, mais ne précisent pas si le support est en cours d'implémentation (ni si ça va casser les modules tiers).

    Je vois aussi qu'il est question d'un pgreloaded (pygame reloaded) qui est apparemment un « pygame 2 », et qui implémente le support de SDL 2.0 (mais avec une API différente, je suppose qu'on peut donc dire adieu aux modules tiers). Qu'en est-il ? Est-ce que c'est à privilégier par rapport à Pygame ?

    Bref, si quelqu'un qui suit/utilise tout ça peut en dire plus… Merci :)

  • # le dilemme du dev

    Posté par (page perso) . Évalué à 8.

    La plupart des API C++ pour les jeux changent de version majeure: SDL, SFML, clanlib, allegro…

    Malheureusement, contrairement aux beaux gosses qui font du Java ou du Python, les développeurs C++ n'ont pas de gestionnaire de dépendances.

    Il va falloir des années avant que les distributions stables majeures intègrent ces nouvelles versions, d'où le dilemme du développeur qui commencerait un jeu aujourd'hui:

    • installer les dernières versions à la main?
    • utiliser des versions packagées mais déjà obsolètes?

    http://devnewton.bci.im

    • [^] # Re: le dilemme du dev

      Posté par (page perso) . Évalué à 5.

      Je suis pas développeur, mais je connais un FPS écrit majoritairement en C qui propose au choix (via un fichier cmake) la possibilité au distributeur d'utiliser les "bundle libs" (libs embarquées?) à compiler en statique, ou alors d'utiliser les libs systèmes si elle sont disponibles.

    • [^] # Re: le dilemme du dev

      Posté par . Évalué à 4.

      La première chose à mon avis et de savoir qu'en est-il de la compatibilité des ABI et des API. Est-ce qu'une appli SDL1.2 tourne avec SDL2 ? La dépêche ne dis rien là dessus en suite il faut voir si cela t'apporte réellement quelque chose de passer à la version supérieur. Obsolète c'est aller un peu vite en besogne, si ça marchait la semaine dernière ça doit encore pas trop mal marcher pendant quelques temps, non ?

      Dernier point, il doit être possible d'architecturer ton logiciel pour avoir une couche d'abstraction entre une bibliothèque et le reste de ton application. Ça permet de changer de version de cette dernière à moindre frais. Le faire pour tout est probablement une mauvaise idée, mais pour une bibliothèque qui a tendance à évoluer un peu vite ça peut être intéressant.

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

      • [^] # Re: le dilemme du dev

        Posté par (page perso) . Évalué à 7.

        Est-ce qu'une appli SDL1.2 tourne avec SDL2 ?

        Nop. En fait, l'architecture a été complètement revue, le bliting ne se fait plus de la même manière, ainsi que l'usage des inputs. Même SDL_Main a été viré, donc tout programme SDL 1.2 doit être porté.

    • [^] # Re: le dilemme du dev

      Posté par . Évalué à 2.

      D'un point de vue de packageur, je dirais tu prends une config type (Debian stable, la dernière Fedora, etc.), et tu développes avec les version de lib inclut dans ta config type.

      Ensuite, c'est aux packageurs des autres distributions de faire évoluer leurs versions.

      Le seul soucis étant quand une nouvelle version de bibliothèque casse la compatibilité ascendante. Là il faudra gérer les cas « anciennes version » et « nouvelles versions », jusqu'à ce que la bibliothèque soit intégrée partout. Sinon certaines distributions resterons avec une ancienne version de ton logiciel, jusqu'au passage à la nouvelle bibliothèque.

      • [^] # Re: le dilemme du dev

        Posté par (page perso) . Évalué à 3.

        D'un point de vue de packageur, je dirais tu prends une config type (Debian stable, la dernière Fedora, etc.), et tu développes avec les version de lib inclut dans ta config type.

        C'est valable pour les distribs linux où la version la plus stable et disponible est la mieux packagée. Pour les autres OS, c'est la dernière release qui compte. Si tu fais un jeu multiplateforme, ça devient vite l'enfer.

        http://devnewton.bci.im

        • [^] # Re: le dilemme du dev

          Posté par . Évalué à 3.

          Si tu fais un jeu multiplateforme, ça devient vite l'enfer.

          Je veux bien le croire. Tu peux aussi prendre comme référence la dernière version de la bibliothèque pour tes nouvelles versions. Si tu ne dépends pas de trop de bibliothèque, les distributions packagerons « avec un peu de retard », en prenant la dernière version de ton logiciel compatible avec l'éco-système déjà existant. Par contre ça oblige à maintenir des versions plus anciennes, ce qui est contraignant, mais pas forcément un mal.

    • [^] # Re: le dilemme du dev

      Posté par . Évalué à 5.

      Moi perso, je garde mon baril de 1.2 quelques temps encore :
      le temps qu'il arrive dans les distro majeurs, et qu'il y ai eut suffisement de retours.

      A ce propos je voyais hier je sais plus trop où que celui qui avait implenté le "LogicalSize" voulait peut être revoir sa copie…

      bref, je sais que je ne migre pas avant 2 ans ;)
      Et d'ici là ils auront encore etoffé le guide de migration qui est déjà excellent.

    • [^] # Re: le dilemme du dev

      Posté par (page perso) . Évalué à 8. Dernière modification le 21/08/13 à 16:02.

      Comme beaucoup de « grosses » bibliothèques, il est probable que les distributions proposeront les deux versions en parallèle pendant un certain temps.
      D’ailleurs Debian le fait déjà :

      $ aptitude search --disable-columns -F'%p %v' ~ilibsdl
      libsdl-image1.2 1.2.12-4                          
      libsdl-mixer1.2 1.2.12-8
      libsdl1.2debian 1.2.15-6
      libsdl2-2.0-0 2.0.0+dfsg1-1
      libsdl2-image-2.0-0 2.0.0~rc1+dfsg-1
      
      $ for lib in /usr/lib/x86_64-linux-gnu/libSDL* ;do print "$lib: ";objdump -p $lib | sed -ne '/SONAME/ s/\s*SONAME\s*/\t/p' ;done
      /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0: 
              libSDL-1.2.so.0
      /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0.11.4: 
              libSDL-1.2.so.0
      /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0: 
              libSDL2-2.0.so.0
      /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.0.0: 
              libSDL2-2.0.so.0
      /usr/lib/x86_64-linux-gnu/libSDL2_image-2.0.so.0: 
              libSDL2_image-2.0.so.0
      /usr/lib/x86_64-linux-gnu/libSDL2_image-2.0.so.0.0.0: 
              libSDL2_image-2.0.so.0
      /usr/lib/x86_64-linux-gnu/libSDL_image-1.2.so.0: 
              libSDL_image-1.2.so.0
      /usr/lib/x86_64-linux-gnu/libSDL_image-1.2.so.0.8.4: 
              libSDL_image-1.2.so.0
      /usr/lib/x86_64-linux-gnu/libSDL_mixer-1.2.so.0: 
              libSDL_mixer-1.2.so.0
      /usr/lib/x86_64-linux-gnu/libSDL_mixer-1.2.so.0.12.0: 
              libSDL_mixer-1.2.so.0
      

      Donc pour un nouveau projet, il faut mieux à mon avis partir sur la nouvelle version afin d’éviter de se taper un portage dans deux ans.

      • [^] # Re: le dilemme du dev

        Posté par (page perso) . Évalué à 1.

        C'est en unstable…

        http://devnewton.bci.im

        • [^] # Re: le dilemme du dev

          Posté par (page perso) . Évalué à 6.

          C'est en unstable…

          What else?

          Plus sérieusement, je pense que pour commencer le dev d’un jeu (ou autre) aujourd’hui, il vaut mieux cibler unstable, de toute façon, si tu veux faire entrer un paquet dans la distribution, il arrivera par là. Je ne connais pas les plans pour une introduction de SDL2 dans backports, mais il y a quelques français dans le groupe de mainteneurs SDL pour Debian dont certains traînent un peu ici de temps en temps, on aura peut-être une réponse.

          Après, c’est sûr que sans backport des bibliothèques, il va être difficile de dire à d’éventuels testeurs en stable (ou si ton projet est prêt avant deux ans), installez juste « watever-dev », puis ./configure && make && sudo make install, mais je ne suis pas sûr que la cible majoritaire pour ça ne soit pas déjà en testing au moins. Si le dev veux faire des paquets lui même, le travail supplémentaire pour intégrer les libs nécessaires dans le paquet et tout mettre dans /opt n’est pas forcément monstrueux (et de toute façon, si le jeu est multiplate-forme, ce sera un boulot obligatoire pour celles sans gestionnaire de paquet).

          Et là, on ne parle que de Debian, qui est l’une des distributions les plus « lentes » (mais je n’avais que ça pour illustrer le fait qu’avec soname et un packaging propre, on peut très bien avoir plusieurs version majeurs d’une lib sur un même système), si tu cibles Fedora, Arch, Ubuntu… qui ont toutes des cycles de 6 mois à un an maximum, il vaut également mieux cibler la dernière version majeure de la bibliothèque…

          • [^] # Re: le dilemme du dev

            Posté par (page perso) . Évalué à 0.

            Plus sérieusement, je pense que pour commencer le dev d’un jeu (ou autre) aujourd’hui, il vaut mieux cibler unstable

            Pour l'instant la seule solution sérieuse, c'est peut être d'attendre qu'un des projets de gestionnaire de dépendances pour C++ s'imposent et de faire du python/java/… en attendant.

            https://github.com/Offirmo/cvm
            https://github.com/bcachet/DMC

            http://devnewton.bci.im

            • [^] # Re: le dilemme du dev

              Posté par . Évalué à 5.

              Malheureusement aucun de ce genre de projets n'arrive à décoller.
              CVM n'a pas eu de commit depuis 4 mois, DMC depuis 7.
              Dans le même genre, encore plus ambitieux, Ryppl, pourtant supporté par des mecs de Boost, semble également au point mort : pas de commit depuis 5 mois, et il ne passe plus grand chose depuis un temps (cf la ML).
              Aura-t-on un jour un pip/gem pour C++ ?

              • [^] # Re: le dilemme du dev

                Posté par (page perso) . Évalué à 3.

                Comme il faut coder en C++, c'est pas très pratique et ça en démotive plus d'un :)

                • [^] # Re: le dilemme du dev

                  Posté par . Évalué à 1.

                  CVM est en shell, DMC quant à lui on ne sait pas, le projet n'a visiblement jamais dépassé le simple stade d'idée (pas une ligne de code à part les tests).
                  Ryppl était codé par des C++ enthusiasts (et la ML continue de recevoir des candidatures de volontaires), mais visiblement, déjà que le C++ ne se prêtait pas au jeu, Boost non plus, qui demandait un redécoupage et une modularisation (et Dieu sait que Boost est complexe) ainsi qu'un changement de système de build (de jam vers cmake), et l'équipe semble avoir baissé les bras devant le volume et la difficulté du travail (et le fait que l'initiateur du projet, Dave Abrahms, eut été recruté par Aplle).

            • [^] # Re: le dilemme du dev

              Posté par (page perso) . Évalué à 6.

              Ah non, pitié, le pire du monde Python/PHP/Ruby en C++ ><

              • [^] # Re: le dilemme du dev

                Posté par (page perso) . Évalué à 5.

                Un gestionnaire de dépendance, c'est bien, même les langages plus nobles en ont (Haskell, OCaml, perl…).

                http://devnewton.bci.im

                • [^] # Re: le dilemme du dev

                  Posté par . Évalué à 8.

                  Tu veux dire les machins qui font double/triple emploi avec le gestionnaire de paquets de ta distribution et des gestionnaires customs existants (genre pkg-config et compagnie) ?

                  À moins que tu parle des dépôts publics insécurisés ou tout le monde peut publier des backdoorées et télécharger sans aucune authentification de la somme de contrôle, voire sans somme de contrôle du tout ?

                  Sérieusement, ça apporte quoi par rapport à des projets éparpillés sur le net, mis à part de la centralisation ?

                  • [^] # Re: le dilemme du dev

                    Posté par . Évalué à 2.

                    Un des avantages que je vois au gestionnaire de paquets des langages de scripts comme Ruby ou Python est qu'il s'intègre très bien avec des outils pour isoler les environnements de programmation. Exemple avec ruby utilisé avec RVM (Ruby Version Manager) qui te permet d'avoir plusieurs versions de Ruby installées en parallèle. Couplé avec Gem (le "gestionnaire de paquets" de Ruby donc), on peut avoir des environnements bien définis entre différents travaux et on peut identifier les gems qui sont requis par un projet pour fonctionner et celles qui ne le sont pas. Une simple ligne de commande à taper ensuite pour changer de versions de ruby et de gems disponibles.
                    Bien sûr tout cela est faisable à la main, mais il faut être très strict pour bien savoir ce que l'on a installé comme extension, comment la désinstaller proprement et complètement, et garder toujours un environnement de travail qui s'éxecute correctement.

                    • [^] # Re: le dilemme du dev

                      Posté par . Évalué à 3.

                      Quel est l'avantage par rapport à un dépot logiciel type deb ou rpm ?

                      A part réinventer la roue (en moins bien) je ne vois pas très bien, tout ce que tu raconte, c'est la base de tout gestionnaire de paquets…

                      • [^] # Re: le dilemme du dev

                        Posté par (page perso) . Évalué à 2.

                        C'est portable et à jour?

                        http://devnewton.bci.im

                        • [^] # Re: le dilemme du dev

                          Posté par . Évalué à 5.

                          Tout à fait.

                          Par exemple; on pourrait imaginer qu'un projet ait son propre dépot deb. Ainsi c'est à jour, avec un packaging bien fait tu gère tout à fait les différentes versions, c'est très très simple à inclure dans les distribution après.

                          La question de la portabilité n'a pas de sens : Au lieu de développer un truc genre gem pour toutes les plate-formes, on pourrait imaginer intégrer un truc genre dpkg ou rpm dans le langage en question, à première vue ça ne semble pas beaucoup plus difficile.

                          Au final je pense que c'est vraiment une quetsion de vision : le gestionnaire de paquet pense toute la chaine de distribution, ce qui peut être contraignant. Les gestionnaires genre gems ne pensent qu'à l'aspect "je balance mon truc vite fait". Evidemment ça va plus vite, mais bon c'est l'arrache totale.

                          • [^] # Re: le dilemme du dev

                            Posté par (page perso) . Évalué à 1. Dernière modification le 23/08/13 à 11:30.

                            on pourrait imaginer intégrer un truc genre dpkg ou rpm dans le langage en question, à première vue ça ne semble pas beaucoup plus difficile.

                            J'attends le lancement d'un tel projet après seconde vue avec impatience :-)

                            Les gestionnaires genre gems ne pensent qu'à l'aspect "je balance mon truc vite fait". Evidemment ça va plus vite, mais bon c'est l'arrache totale.

                            Je ne connais pas bien gem, mais avec Maven & co, tu as un gestion des releases (pour bosser proprement) et des snapshots (pour l'arrache).

                            http://devnewton.bci.im

                          • [^] # Re: le dilemme du dev

                            Posté par . Évalué à 5.

                            Par exemple; on pourrait imaginer qu'un projet ait son propre dépot deb. Ainsi c'est à jour, avec un packaging bien fait tu gère tout à fait les différentes versions, c'est très très simple à inclure dans les distribution après.

                            On peut imaginer pleins de choses. Mais les deb ça marche sur Debian et dérivé uniquement (et encore modulo quelques incompatibilités) plus RH&Fed avec alien. Là on parle de choses qui sont utilisé sur n'importe quelle distribution linux, sur XP/Vista/Seven/8, sur OS X et sur les BSD évidement. Ça fait une dizaine d'années que rpm est le standard LSB et assez peu de distribution en définitive s'en servent. Bref faut quand même pas mal d'imagination pour imaginer créer un dépôt deb et l'utiliser partout. Même si demain apt deviens utilisable et utilisé sur toutes les plateformes tu aura toujours un tas de problème :

                            • système wide
                            • pas de possibilité simple universel pour avoir n version d'une même bibliothèque

                            La question de la portabilité n'a pas de sens : Au lieu de développer un truc genre gem pour toutes les plate-formes, on pourrait imaginer intégrer un truc genre dpkg ou rpm dans le langage en question, à première vue ça ne semble pas beaucoup plus difficile.

                            Ça veut dire quoi « intégrer un truc genre dpkg ou rpm dans le langage en question » ? C'est un vrai question.

                            Au final je pense que c'est vraiment une quetsion de vision : le gestionnaire de paquet pense toute la chaine de distribution, ce qui peut être contraignant. Les gestionnaires genre gems ne pensent qu'à l'aspect "je balance mon truc vite fait". Evidemment ça va plus vite, mais bon c'est l'arrache totale.

                            Je ne les connais pas tous, mais pour CPAN tu a une panoplie de test (exemple avec Mosse). Maven possède une gestion précise des releases assez contraignante mais conçu pour rendre le build aussi reproductible que possible. Je ne doute pas que les autres ont aussi leur critère dans leur coin.

                            Mais note que c'est nécessaire de pouvoir balancer ton truc vite fait sur ton dépôt à toi, pour pouvoir le partager avec ceux qui veulent développer leur logiciel sur la prochaine version de ta bibliothèque par exemple.

                            Bref c'est plus qu'une question de vision c'est une question de besoin. dpkg/rpm ne répondent pas à ces besoins entre autre car :

                            • ils ne permettent pas simplement la cohabitation de plusieurs versions
                            • ils sont au niveau système :
                              • installer une bibliothèque à tendance à impacter l'ensemble du système
                              • il faut être root de la machine pour s'en servir
                            • ils sont liés à quelques systèmes d'exploitation et non pas à tous (Win, OSX et BSD compris)

                            Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                      • [^] # Re: le dilemme du dev

                        Posté par . Évalué à 7.

                        Quand tu utilise un langage dis portable. Te fader plus de packaging différent qu'il n'existe de système d'exploitation, ça n'a pas de sens.

                        deb, rpm et autres sont système, ils vont installer des trucs pour l'ensemble des utilisateurs utilisateurs système compris.

                        Toi tu es sur ta machine, tu veux utiliser la toute dernière version de dev de perl et de Moose, mais ta pas envie de casser ton système pour autant. Aucun gestionnaire de paquet de distribution ne gère ce genre de chose. Ce que tu peut éventuellement faire c'est créer un chroot et te faire toute ton installe.

                        Il est aussi bien plus pratique d'avoir dans les fichiers projets (ceux qui sont versionnés), la liste des dépendances qui sont ensuite automatiquement résolue de manière indépendante du système d'exploitation. Ça permet à tout les développeurs de travailler rapidement ensemble sans pour autant être forcé d'utiliser le même SE que les autres.

                        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                        • [^] # Re: le dilemme du dev

                          Posté par . Évalué à 7.

                          C++ n'est rien d'autre qu'une spécification sur le langage. Il n'y a pas d'implémentation de référence ou quoi que ce soit. Il n'y a pas de moyen standard pour compiler et lancer un logiciel. Le langage ne dicte par exemple pas que ton système doit supporter les bibliothèques dynamiques, et tu a des systèmes ou ce n'est pas le cas. Tu à des systèmes ou ton implémentation de la norme C++ est incomplète (pas d'exception, par exemple).

                          À partir de ce moment là, tu à un gros problème à gérer, rien que pour compiler et lancer un logiciel sans dépendances. Il te faut un système de build bloaté pour supporter plusieurs systèmes, plusieurs compilos (avec des bugs divers et variés) les architectures éxotiques sans virgule flottante matérielle, les bibliothèques standard avec plus ou moins de lacunes (parfois causées simplement par les limitations matérielles), la cross compilation (greuh), et ne parlons pas des options de compilation.

                          En fait, tu te retrouve avec tout les problèmes qu'ont les systèmes de builds, les distributions et les gestionnaires de paquets avec les logiciels C depuis 20 ans. Et à ce que je sache, personne n'a pour l'instant résolu le problème pour Windows, ou il y a encore plus de segmentation avec les compilos Visual C++ incompatibles entre eux.

                          Alors oui, quand je dit que ça fait double emploi avec $PACKAGE_MANAGER, c'est que c'est vraiment le cas, puisque ça en est un.

                          La seule vraie solution à ce problème, ça serait une meta distribution générique qui s'intègre avec tout les OS qui existent. Or on sais très bien que ça va poser encore plus de problème que ça va n'en résoudre.

                          • [^] # Re: le dilemme du dev

                            Posté par . Évalué à 1.

                            Je ne sais pas pour le C++, mais pour le C tu as cc qui est au moins un standard de fait sur les unix-like. Ensuite, rien ne t'empêche d'avoir un gestionnaire de dépendances qui pour chaque bibliothèque donne un certain nombre de prérequis système (architecture, gestion de tel ou tel fonctionnalité du langage, etc) et dans tes fichiers projet tu indique les prérequis de ton système cible. Ensuite c'est une gestion des dépendances tout ce qu'il y a de plus classique. La différence avec apt c'est qu'il peut se charger lui même de mettre tout ça dans un dossier à toi et choisir les directive du compilateur pour les inclures (une énorme partie existe déjà dans CMake).

                            Mais bon même si ça ne marche pas pour certains langages comme le C et le C++, ce n'est pas pour ça que c'est idiot dans les autres contrairement à ce que tu affirmais.

                            Alors oui, quand je dit que ça fait double emploi avec $PACKAGE_MANAGER, c'est que c'est vraiment le cas, puisque ça en est un.

                            Non.
                            Dans ce commentaire tu dis que le C++ s'il en existait un pour du C++ ça ferrait double emplois avec le gestionnaire de paquet. Alors que dans les précédent tu disais que gem c'est de la merde fait pour les bouts de code fait à l'arrache.

                            Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                            • [^] # Re: le dilemme du dev

                              Posté par . Évalué à 4.

                              Je ne sais pas pour le C++, mais pour le C tu as cc qui est au moins un standard de fait sur les unix-like.

                              Mais pas sous Windows. Or si il y a bien un OS qui à besoin d'un gestionnaire de dépendance de toute urgence, c'est bien cet OS (quoi que j'en pense). Le reste a déjà des gestionnaire de paquets…

                              La différence avec apt c'est qu'il peut se charger lui même de mettre tout ça dans un dossier à toi et choisir les directive du compilateur pour les inclures (une énorme partie existe déjà dans CMake).

                              Debian ça n'est pas qu'apt, il y a aussi toute la gestion de la compilation et de la cross compilation des paquets, en plus de l'infrastructure qui permet de compiler tout ça automatiquement.

                              D'ailleurs, Debian a (avait ?) discuté de la possibilité d'installer des paquets en tant qu'utilisateur. Comme quoi les problématiques ne sont pas aussi éloignées que tu ne le crois.

                              Dans ce commentaire tu dis que le C++ s'il en existait un pour du C++ ça ferrait double emplois avec le gestionnaire de paquet.

                              Dans le précédent aussi.

                              Alors que dans les précédent tu disais que gem c'est de la merde fait pour les bouts de code fait à l'arrache.

                              Je n'ai jamais dit ça. L'autre reproche principal que je faisais concerne la sécurité de certains dépôts de ces systèmes de dépendances, ou les utilisateurs exécutent automatiquement du code uploadable par n'importe qui sans aucune vérification ni cloisonnement.

                              Même si pour le coup, avec un langage aussi expert-friendly que C++, on va forcement avoir des problème de qualité des codes uploadés.

                              • [^] # Re: le dilemme du dev

                                Posté par (page perso) . Évalué à 6.

                                D'ailleurs, Debian a (avait ?) discuté de la possibilité d'installer des paquets en tant qu'utilisateur.

                                Et ça a donné quoi ?

                  • [^] # Re: le dilemme du dev

                    Posté par (page perso) . Évalué à 1.

                    $ wget http://libriste-integriste-barbu.plop/superprojet_qui_utilise_plein_de_libs.zip
                    $ aunpack superprojet_qui_utilise_plein_de_libs.zip
                    $ cd superprojet_qui_utilise_plein_de_libs
                    $ mvn package
                    ...
                    BUILD SUCCESSFULL
                    

                    http://devnewton.bci.im

                    • [^] # Re: le dilemme du dev

                      Posté par . Évalué à 3.

                      Tu peux arriver au même résultat avec debian par exemple :

                      apt-get source superprojet
                      apt-get build-dep superprojet
                      cd superprojet
                      debuild -us -uc

                      (pas sûr de moi sur les commandes, mais l'idée est là)

                      En bonus, c'est sécurisé.

                      • [^] # Re: le dilemme du dev

                        Posté par (page perso) . Évalué à 3.

                        En malus, il faut que tous les devs soient sur debian et deviennent grand maître du packaging deb…

                        http://devnewton.bci.im

                      • [^] # Re: le dilemme du dev

                        Posté par . Évalué à 1.

                        En quoi c'est plus sécurisé que les autres ?

                        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                        • [^] # Re: le dilemme du dev

                          Posté par (page perso) . Évalué à 1.

                          • [^] # Re: le dilemme du dev

                            Posté par (page perso) . Évalué à 3.

                            En quoi est-ce plus sécurisé qu'un dépôt Maven avec signature PGP & co?

                            http://devnewton.bci.im

                            • [^] # Re: le dilemme du dev

                              Posté par (page perso) . Évalué à 1.

                              Je ne sais pas pourquoi tu es venu avec Maven dans la discussion. Cet outil n'a rien à voir avec Pip, Gem, et autres rustines mal-pensées.

                              C'est un peu comme si tu m'opposait Git dans une discussion autour des formats d'archives : ça n'a aucune pertinence.

                              Maintenant, Maven ne semble pas être un outil de diffusion automatique de vers, je n'ai donc pas d'opinion sur ce gestionnaire de build.

                              • [^] # Re: le dilemme du dev

                                Posté par . Évalué à 4.

                                Je ne sais pas pourquoi tu es venu avec Maven dans la discussion.

                                Tu rigole ? C'est lui qui a commencer à parler des gestionnaires de version propre à des langages particulier et il a commencé avec python et java en exemple…

                                Cet outil n'a rien à voir avec Pip, Gem, et autres rustines mal-pensées.

                                Pip, Gem, cpan et autres sont un sous-ensemble de ce que fait maven. Je crois que maven c'est plutôt gem + bundler + rake.

                                Mais au final comme on parle de gestion de dépendance du logiciel avec ces bibliothèques propre à un langage et indépendant du système d'exploitation, je ne vois pas en quoi il est pas pertinent (mis à part le fait qu'il ne rentre pas dans ton argumentation).

                                C'est un peu comme si tu m'opposait Git dans une discussion autour des formats d'archives : ça n'a aucune pertinence.

                                Faut arrêter les comparaisons c'est systématiquement foireux.

                                Maintenant, Maven ne semble pas être un outil de diffusion automatique de vers, je n'ai donc pas d'opinion sur ce gestionnaire de build.

                                Les autres le sont plus ? Tu as des liens à ce sujet ?

                                Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                                • [^] # Re: le dilemme du dev

                                  Posté par (page perso) . Évalué à 2.

                                  Un lien ? On peut trouver ce genre de blagues : https://bugzilla.redhat.com/show_bug.cgi?id=749378

                                  Les comparaisons ne sont foireuses que pour ceux qui ne les comprennent pas.

                                  Maven n'est pas pertinent parce qu'il ne va pas, au petit bonheur la chance, butiner sur des serveurs plus ou moins de confiance pour trouver comment satisfaire ses dépendances. Il faut spécifiquement indiquer à Maven quelles sources consulter pour étancher son désir de dépendance.
                                  Alors qu'avec pip et compagnie, tu te retrouves souvent avec des scripts s'exécutant, provenant de serveurs dont tu n'as jamais entendu parler. Sans compter que ce sont généralement des serveurs où n'importe qui déposer une version d'un composant, sans qu'il n'y ait aucun contrôle. Tout ça parce que le comportement par défaut de PIP, c'est de jeter tout principe de sécurité de base et de se tremper joyeusement dans le premier paquet qui semble correspondre à ses désirs.

                                  Oui, tu peux spécifier que tu ne veux pas installer, que tu ne veux que télécharger : mais ce n'est pas le comportement par défaut. Donc à la moindre erreur, s'il y a un ver qui traîne dans un paquet, tu le choppe à ton tour. Et évidement, il va se loger dans tes propres sources, que tu vas empaqueter dans un pip et uploadé (ou il va le faire tout seul, pour peut que ton trouseau de clés n'est pas protégé par une passphrase).

                                  Pip, c'est comme la base de registre de MS Windows : une bonne idée à la base, une implémentation merdique à l'arrivée.

                                  • [^] # Re: le dilemme du dev

                                    Posté par (page perso) . Évalué à 4.

                                    Maven n'est pas pertinent parce qu'il est bien fait?

                                    http://devnewton.bci.im

                                    • [^] # Re: le dilemme du dev

                                      Posté par (page perso) . Évalué à 1.

                                      Disons qu'il est moins pire que les autres, parce que ces auteurs pratiquent une politique de sécurité raisonnable. Cependant, le problème des gestionnaires de paquets par dépôt reste ouvert, en ce sens qu'ils ne bénéficient pas des mises à jour de sécurité du système.

                                    • [^] # Re: le dilemme du dev

                                      Posté par . Évalué à 2.

                                      Si c'était bien fait, il n'aurai pas besoin de télécharger le monde et répliquer le contenu de mon répertoire /usr/share/java déjà bien rempli par Debian.

                                      Ça plus le fait que ça soit du Java quoi…

                                      • [^] # Re: le dilemme du dev

                                        Posté par (page perso) . Évalué à 3.

                                        Si c'était bien fait, il n'aurai pas besoin de télécharger le monde et répliquer le contenu de mon répertoire /usr/share/java déjà bien rempli par Debian.

                                        Maven est un système portable. La prise en compte des spécificités de Debian est du ressort de… Debian!

                                        Ça plus le fait que ça soit du Java quoi…

                                        Un système de build et gestion de dépendances pour Java écrit en Java, ça me semble logique. C'est pareil pour les autres: gem est en ruby, pip en python, cabal est en Haskell…

                                        http://devnewton.bci.im

                                  • [^] # Re: le dilemme du dev

                                    Posté par (page perso) . Évalué à 1.

                                    Un lien ? On peut trouver ce genre de blagues : https://bugzilla.redhat.com/show_bug.cgi?id=749378

                                    Pourquoi c'est une blague?

                                    Écrit en Bépo selon l’orthographe de 1990

                        • [^] # Re: le dilemme du dev

                          Posté par . Évalué à 2.

                          Debian à toute une infrastructure à base de logiciels libres, disponibles (et packagés pour Debian) pour permettre de construire des paquets dans des environnements isolés pour éviter qu'un rigolo te lance une backdoor lors d'un ./configure. Ils ne sont peut-être pas parfaits et entièrement sécurisés, mais c'est déjà bien mieux que certains gestionnaires de dépendances ou c'est totalement open bar. Par contre, ils ne te protégeront pas contre la compilation de code malveillant (ou de code tout simplement pourri).

                      • [^] # Re: le dilemme du dev

                        Posté par . Évalué à 2.

                        apt-get build-dep $PROJECT
                        apt-get --compile source $PROJECT
  • # nimage cassée

    Posté par (page perso) . Évalué à 8.

    Je ne vois pas le logo SDL dans la dépêche (oui, oui, j'ai bien le certificat de img.linuxfr.org)
    Ces deux adresses (cache et originale) répondent toutes les deux par un 404.
    http://img.linuxfr.org/img/687474703a2f2f7777772e6c696273646c2e6f72672f696d616765732f53444c5f6c6f676f2e706e67/SDL_logo.png
    http://www.libsdl.org/images/SDL_logo.png

    J'ai trouvé ces images là :

    https://upload.wikimedia.org/wikipedia/fr/2/26/SDL_logo.png
    logo SDL

    http://www.libsdl.org/media/SDL_logo.png
    logo SDL

    http://wiki.libsdl.org/wiki_static/SDL_logo20_sm.png
    logo SDL 2.0

    La dernière est peut-être plus appropriée pour l'annonce de version, mais c'est la plus petite.

    ce commentaire est sous licence cc by 4 et précédentes

  • # Xlib,/XCB

    Posté par . Évalué à 4.

    Sous Linux, SDL est traditionnellement conçu pour fonctionner avec un serveur X via la bibliothèque Xlib, mais des portages de la communauté sont en cours pour Wayland et pour Mir.

    Il n'est pas prévu d'avoir un équivalent de Xlib/XCB, qui offre une abstraction du serveur d'affichage (au moins entre Xorg et Wayland) ? Voir réimplémenter Xlib ou XCB sur Wayland ? Je sais que chaque bibliothèque graphique va faire cette abstraction, mais ça me paraît dommage de ne pas le faire au niveau en dessous pour ça puisse profiter au plus grand nombre.

    Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

    • [^] # Re: Xlib,/XCB

      Posté par . Évalué à 1.

      Justement, SDL est fait pour ça. Il abstrait meme de l'OS utilisé.

      Wayland et Mir ont des couches de compatibilités pour que les applis X puissent tourner.

      • [^] # Re: Xlib,/XCB

        Posté par . Évalué à 4.

        Justement, SDL est fait pour ça. Il abstrait meme de l'OS utilisé.

        Qt aussi. Mais c'est du travail que chacun fait dans son coin et maintenu à l’extérieur du projet des serveur graphique.

        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

  • # facilité

    Posté par . Évalué à 5.

    Ça fait plusieurs fois que je le vois utilisé dans ce sens (traduction de facility). Serait-il entré dans le dictionnaire ?

    • [^] # Re: facilité

      Posté par . Évalué à 0.

      (traduction de facility)

      Je le vois plus souvent en anglais être utilisé pour ses autres sens. C'est souvent un faux ami.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: facilité

        Posté par . Évalué à 1.

        En l’occurrence, c'est le mot français que j'ai mis, ce n'est pas une traduction. Mais "service" est peut-être plus convenable.

Suivre le flux des commentaires

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