Skywalker13

Diary of an ex-GeeXboX developer…

Autour de la compilation d'Enna ~ 🇫🇷

Posted at — Dec 17, 2009

Hello,

je tiens juste Ă  donner quelques prĂ©cisions pour les personnes qui dĂ©sirent compiler Enna, et donc Ă©galement les bibliothèques rattachĂ©es. Cet article n’est pas un tutoriel. Si vous ne savez pas comment vous y prendre, il vaut mieux rechercher l’information ailleurs.

Faites aussi un tour Ă  ces adresses (en anglais / in english) :
http://enna.geexbox.org/developers.html
http://captainigloo.wordpress.com/2009/12/21/enna-compilation-on-ubuntu-3/

Evas

Comme vous le savez, Enna se base sur les EFL. Je vous conseil fortement d’utiliser les snapshots ne serait-ce au moins pour ne pas que vous reportiez des “bugs” juste parce que les APIs des EFL auraient trop Ă©voluĂ©es. En partant du principe que vous savez compiler les EFL, je vous rappel de ne pas oublier le flag ––enable–gl–x11 avec Evas, si vous avez l’accĂ©lĂ©ration 3D avec votre PC. Les performances graphiques d’Enna sont nettement meilleurs. Toujours concernant Evas, il y a une petite modification dans les sources qui vous permettra d’avoir des textures anti-aliasĂ©es. Dans le cas contraire, Enna est plus beau (mais plus lent) en X11 Software plutĂ´t qu’en OpenGL. Il faut tout simplement modifier les dĂ©finitions GL_NEAREST en GL_LINEAR dans toutes les sources.

cd ~/e17_src/evas
sed -i "s/GL_NEAREST/GL_LINEAR/g" \
    `grep -Rl GL_NEAREST . | grep "\.c$"`

Libgeexbox

Libgeexbox est une manière naĂŻve de parler de toutes les bibliothèques que nous dĂ©veloppons en parallèle Ă  la distribution et Ă  Enna. Depuis quelques temps, des releases sont apparues pour libnfo, libplayer et libvalhalla. Il faut savoir que se sont les toutes premières releases! LĂ  oĂą je veux en venir c’est qu’il Ă©tait totalement justifiĂ© de toujours se baser sur les versions de dĂ©veloppement pour compiler Enna. Par exemple le premier import de libplayer date de 2006 et c’Ă©tait une habitude que de faire un hg pull -u rĂ©gulièrement. Mais maintenant que les versions 1.0.0 sont disponibles, veuillez s.v.p. vous baser uniquement sur celles-ci (ou sur n’importe quelles nouvelles releases de ces libs dans le futur).

Il y a deux solutions, en passant sur les sites web respectifs des projets (les liens sont disponibles à droite des articles de ce blog) ou alors avec Mercurial. Mais dans ce cas veuillez préciser la version de la dernière release. Tel que par exemple :

hg clone -r v1.0.0 http://hg.geexbox.org/libvalhalla

Si vous chargez la devel (donc le “tip”) vous ne pourrez pas compiler Enna ou alors vous avez de la chance :-). Depuis qu’il y a les releases je me permets de casser les APIs des bibliothèques parce que je suis un Ă©ternel insatisfait (je rigole…) et ça faisait longtemps que je voulais faire un peu de mĂ©nage dans certaines en-tĂŞtes publiques.

Et après l’installation des libgeexbox, n’oubliez pas de faire un sudo ldconfig. Question que le chargeur de programme ait les nouvelles bibliothèques de rĂ©fĂ©rencĂ©es.

libvalhalla

Quand vous exĂ©cutez le configure de libvalhalla, jetez un Ĺ“il aux informations retournĂ©es avant de faire bĂŞtement un make. Le configure dĂ©sactive les Ă©lĂ©ments en fonction des bibliothèques qu’il ne trouve pas. Par exemple, si vous n’avez pas la libcurl-dev, le support des grabbers est complètement dĂ©sactivĂ© mais cela n’empĂŞche pas la compilation.

Admettons que vous avez toutes les libs nĂ©cessaires et que vous voyez certains grabbers de dĂ©sactivĂ©s. Je pense par exemple Ă  lyricsfly. Ce n’est pas un bug. Lyricsfly n’est pas utilisable car la clef de l’API pour le webservice Ă©tait provisoire. Ce grabber est donc dĂ©sactivĂ© par dĂ©faut. Si vous utilisez ––enable–grabbers pour ĂŞtre sĂ»r d’activer tous les grabbers vous n’aurez rien Ă  gagner. Vous ferez perdre du temps Ă  libvalhalla sur lyricsfly qui ne retournera jamais rien (je parle de lyricsfly, mais ça peut ĂŞtre d’autres Ă  l’avenir).

A noter Ă©galement que dès que vous forcez les grabbers ou seulement quelques grabbers, leurs dĂ©pendances deviennent obligatoires. Par exemple si vous faites ––enable–grabber–ffmpeg vous forcez la dĂ©pendance sur libavcodec. Si vous avez vraiment libavcodec et que ça Ă©choue, c’est simplement que votre version est trop ancienne. Par exemple, le libavcodec que vous trouvez avec Ubuntu Karmic ne supporte pas la fonction av_lockmgr_register() qui garanti l’utilisation des codecs Ă  ĂŞtre multi-thread safe.

libplayer

Concernant libplayer, c’est la dĂ©pendance indirecte avec MPlayer qui est la plus importante. Assurez-vous que votre MPlayer est en anglais uniquement. Libplayer peut dĂ©tecter les MPlayer incompatibles jusqu’Ă  un certain point. En fonction de la manière dont MPlayer a Ă©tĂ© compilĂ©, libplayer ne peut pas savoir s’il est en anglais ou non et va donc l’utiliser (pour les curieux, je parle de la variable d’environnement LINGUAS Ă  la compilation d’MPlayer; libplayer ne dĂ©tecte la langue que si celle-ci est passĂ©e avec ––language–msg= ou ––language=).

DĂ©marrer Enna

Contrairement Ă  certains tutoriels sur Enna, il n’est pas nĂ©cessaire de copier le fichier d’exemple enna.cfg qui se trouve Ă  la racine des sources, dans le dossier ~/.enna. Parce que ce fichier est automatiquement crĂ©Ă© au premier dĂ©marrage de l’interface. Et allez jeter un Ĺ“il au contenu. Si vous voulez que libvalhalla puisse faire son travail, vaut mieux lui dire oĂą il doit scanner. Dans le cas contraire 100% des fichiers seront traitĂ©s en ondemand (je vous laisser chercher dans ce blog si vous ne comprenez pas).

Et maintenant que vous avez l’OpenGL, vous remarquerez assez vite qu’en le spĂ©cifiant dans ~/.enna/enna.cfg ça ne change pas grand chose. Pire que cela, ça ne change absolument rien ;-).

Pour l’instant il faudra le faire Ă  la main depuis un terminal, avec :

ELM_ENGINE=gl enna

A bientĂ´t,
Mathieu SCHROETER