Diffusion d'un programme utilisant SFML sous Linux

Bonjour à tous!
Je développe actuellement un jeux-vidéo, plutôt simple mais que j'aimerais partager sous LINUX!! :D
J'utilise SFML, le seul problème c'est que l'installation n'est pas "trivial", et donc monsieur et madame tout le monde, ne saura pas installer les dépendances de mon programme.
Quelle est la solution à ce problème? J'ai penser à la compilation static...

Sinon plus généralement comment diffuse-t-on un programme sous linux?
L'utilisateur peut-il télécharger le programme et l'installe aussi facilement?

Merci d'avance pour vos lumières! :zoubi:

Bonjour,

En théorie, il te suffit de passer au choix :

• un .rpm (??)
• un .deb (pour les debian-based )
• une archive des sources
• les binaires

Dans l'archive, l'installation doit être expliquée dans un README avec, selon les fichiers de projets utilisés :

• sudo make && make install
• sudo ./configure && make && make install
• sudo cmake && make && make install

Pour l'archive, il suffit de demander d'installer la dépendance (en décrivant la procédure dans le README par exemple) et il se débrouillent :

• apt-get install libsfml-dev
• aptitude install libsfml-dev
• téléchargement de l'archive puis cmake && make && make install

Sinon, oui la compilation statique peut être une solution, même si je te conseillerais plutôt de l'éviter.

Citation:

---

J'utilise SFML, le seul problème c'est que l'installation n'est pas "trivial"

---

Tu l'installes comment aussi? Parce que la SFML est une des bibliothèques les plus faciles à installer et c'est à la porté de tous de copier/coller une ligne dans un terminal.

Merci beaucoup pour cette réponse, je vais creuser pour essayer de faire ce qu'il faut ^^

Pour l'installation de la sfml, j'ai voulu installer la 2.1 mais impossible de compiler le moindre programme, sinon j'ai télécharger les bibliothèques sfml 2.0 pour 64 bits sur le site officiel tout simplement. Je me suis ensuite fait insulter par le compilateur pour les dépendances manquantes. J'ai donc télécharger les bibliothèques nécessaires, qui en passant n'étaient pas dans les paquets de ma debian --'.
Voila j'ai finit par m'en sortir mais je ne trouve pas que ce soit l'installation la plus simple au monde ^^. La sdl m'a prise 30s à installer par exemple.
Je suis conscient que la sfml est disponible dans les paquets, mais il s'agit de la 1.6.

Citation:

---

Pour l'installation de la sfml, j'ai voulu installer la 2.1 mais impossible de compiler le moindre programme

---

Si tu as la 1.6 d'installée, tu peux en effet avoir un conflit.

Peux-tu nous dire exactement ce que tu as fait et les erreurs qui tu as obtenu?
Parce qu'en théorie, la sfml, tu la compiles et tu l'installes à partir des sources en moins de 30 secondes.

La 1.6 n'est pas installée sur mon ordinateur.
Pour la 2.1 j'ai l'erreur suivante : /[..]/SFML-2.1/lib/libsfml-graphics.so: undefined reference to `memcpy@GLIBC_2.14'
Impossible de trouver l'origine de l'erreur =/
Pour la 2.0 c'était simplement, undefined reference to ...
J'ai dû installer libglew1.5, et libjpeg62.

Voilà =)

As-tu bien lancé cmake pour compiler ? :koi:
Théoriquement tu ne devrais pas pouvoir avec ce genre d'erreurs en utilisant cmake.

Je n'ai rien compilé. J'ai récupéré ici : http://www.sfml-dev.org/download/sfml/2.1/index-fr.php, Linux GCC 64 bits

Essaye plutôt de la compiler, il est possible que le compilateur que tu as sous Linux ne soit pas compatible avec celui utilisé pour créer les bibliothèques.

Je me suis pris la tête la dessus aussi, toute les distrib ne sont pas forcément équipé avec le nouveau gcc prenant en compte le C++11, je trouve ça dommage et bloquant dans pas mal de cas. c'est pour ça que mes applications ne tourne pas encore avec SFML2.

Pour le partage, je te conseil de précompiler ton application et d'avoir un linux vierge en VM. Tu mets ton application dans un dossier et tu la lance dans le linux vierge, tu obtiendras la liste des dépendance dont ton application à besoin. Ensuite tu prend toute les dépendances nécessaire, que tu integres dans ton dossier (les .so par exemple). Comme ça tu obtiens une archive qui peut être lancer sur tout les linux possédant la même architecture sans avoir besoin d'installer les libs :).
Le même fonctionnement existe avec les .deb, .rpm .... ils vont vérifier les dépendance que tu auras renseigner dans ton package pour les installer si elles sont manquante, cela demande un peu plus de travail que de livrer un dossier zipper contenant toute les dépendance, mais c'est beaucoup plus propre. :)

L'autre solution est de faire un petit script sh qui va vérifier les dépendance et si elles ne sont pas satisfaites, les installer. Un peu comme le ferait le ./configure ou le cmake.

Par ailleurs le cmake reste une très bonne option pour partager une application mais cela implique que tu livres les sources afin de les recompiler sur le système cible.

Tout dépend de ce que tu veux livrer:
1) Une application sans le code source -> obligation de précompiler pour chaque architecture. livrer via un package (.deb, .rpm ....) ou un dossier zipper contenant toute les dépendance.
2) Une application avec le code source -> CMake est une très bonne solution (surtout avec la SFML).

Merci Skeud, c'est exactement les infos que je voulais ^^

Mais avant de clôturer ce sujet j'aimerais savoir si je peux demander d'installer SFML 2.0 par exemple grâce à un fichier .deb, malgré la version de la SFML disponible dans les paquets, la 1.6?

Tout dépend de la version disponible dans le gestionnaire de paquet.SI la 2 est disponible, oui tu peux, sinon, il faut:
1) Que tu fournisse le package de la SFML2
2) Que l'utilisateur installe manuellement la SFML2.

Pour l'instant honnetement, je te conseille de faire un dossier avec toute les dépendance dedans et de le partager, il y a très peu de distrib avec un compilo cxx11, donc tu auras très peu de distrib avec un package de la SFML2. :)

D'accord, je vais procéder ainsi! ;)

Pour trouver les dépendances, pourquoi ne pas utiliser la commande ldd ?

Citation:

---

ldd ./monProgramme

---

Cela liste les .so utilisés par le programme.