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/
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 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.
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.
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=
).
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