Autour de la compilation d’Enna

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

Advertisement