Depuis un temps non négligable, j'essaie de compiler une bibliothèque qui utilise les autotools. pour ceux que ca intéresse, il sagit de Ogre: http://www.ogre3d.org/(...)
Les autotools c'est bien lorsque ca marche. par exemple:
./configure --disable-cg
make
Et on en reste là pour l'instant.
je ne sais pas d'ou vient le problème, des autotools ou alors des Makefiles.am mais il se trouve que sur les 5 bibliothèques qui devraient être construites, je n'en trouve qu'une seule: libOgreMain.so
En effet, les autres bibliothèques:
- libOgrePlatform.so
- Plugin_BSPSceneManager.so
- Plugin_OctreeSceneManager.so
- Plugin_ParticleFX.so
ne sont pas construites. Il se trouve qu'après la compilation, j'ai bien des fichiers qui ont presque ce nom ... Leur extension est juste différente. Au lieu du .so adoré, j'ai des .la ou encore des .lai
ce n'est pas que je ne les aime pas, non au contraire. par contre, je préfère les .so qui peuvent être chargés comme bibliothèques par mon application.
Une fois même j'ai failli obtenir des fichiers .so. mais manque de chance, c'était des fichiers .soU
Après toutes ces divagations dans l'univers étrange des autotools, je tente d'autres méthodes de compiltaion comme par exemple CMake: http://www.cmake.org(...)
Sauf que je ne connais pas plus CMake, et les Makefiles.am, même si ils sont vbeaucoup plus simples à lire que les Makefiles ne me permettent pas de facilement réer mes CMakeList.txt
C'est alors que j'en viens à me demander l'utilité de pkg-config. A quoi cela sert-il de mettre tous les headers dans /usr/include /usr/local/include si c'est pour que pkg-config donne pour chaque paquet
- Le dossier où se trouve les headers
- Le dossier où se trouve les bibliothèques
- Le nom de la bibliothèque qu'on a déja du donner à pkg-config
- Des constantes à définir. ne pourraient elles pas êtres comprises dans les headers ?
bref, a quoi bon séparer les fichiers dans l'arborescence /usr et /usr/local si c'est pour stoker leur emplacement avec pkg-config. Autant mettre tout dans C:/Program_Files ou /opt ...
L'idéal serait de compiler un programme avec:
gcc -llib1 -llib2 -o progname *.c
Au lieu de
gcc `pkg-config --cflags --libs lib1` `pkg-config --cflags --libs lib2` -o progname *.c
Il serait alors tellement plus simple de comprendre les Makefiles.am
Et un dernier point qui m'énerve depuis longtemps: Porquoi la programme à besoin de savoir a la compilation où il va être installé ??? Si ces informations sont utilisées, il faudra recompiler le programme a chaque déplacement ...
Le plus simple ne serait-il pas de collecter ces informations lors de l'execution par exemple avec des variables d'environnement. Un script shell dans */bin serait chargé de les positionner sur les bonnes valeurs et d'appeler le programme qui serait alors situé dans */lib
Juste une idée ...
Qu'est ce que j'aime les choses simples.
Ce que j'imagine comme remplacant des autotools, c'est un programme simple, qui prend en entrée un fichier dans un format simple, qui présente de manière simple quels fichiers doivent être compilée et des bibliothèques dont ils ont besoin.
Cela devrait suffire à compiler.
--
Si vous pensez que ce post va mieux dans les forums, je ne le pense pas car sa fonction n'est pas de demander de l'aide mais de raler contre un outil qui est parfois bien embêtant: les autotools.
Journal Les autotools: lorsque ca ne marche pas ...
31
juil.
2005
# RTFM
Posté par David . Évalué à 2.
par exemple, sous Debian, "apt-cache search automake" donne le resultat :
automake1.4 - A tool for generating GNU Standards-compliant Makefiles.
automake1.6 - A tool for generating GNU Standards-compliant Makefiles.
automake1.7 - A tool for generating GNU Standards-compliant Makefiles
automake1.8 - A tool for generating GNU Standards-compliant Makefiles
automake1.9 - A tool for generating GNU Standards-compliant Makefiles
Si tu ne peux pas compiler avec ton automake actuel, change de version.
[^] # Re: RTFM
Posté par Mildred (site web personnel) . Évalué à 1.
Sachant que Ogre est prévu pour Automake 1.6+ (c'est ce qu'on m'a dit)
# ..
Posté par M . Évalué à 3.
Pour info dans l'arbre de source elle sont souvent dans des repertoires cache qui commence par un '.'.
[^] # Re: ..
Posté par Mildred (site web personnel) . Évalué à 1.
# Une bidouille :)
Posté par melian_ . Évalué à 10.
En principe lors de la création des .so qui se fait lors de l'install, y a un soucis et une floppée d'erreur de STL arrive ( sous Debian en tout cas ).
Tu retrouves dans les sous repertoires suivant les .la et .lai ( en principe libOgreMain.so est la seule qui est crée correctement )
OgreMain/src/.libs/
RenderSystems/GL/src/.libs
PlatformManagers/SDL/src/.libs/
etc... ( je detaille pas pour Plugins/ )
En plus de ces fichier il y a des .soU ( pour la version 1.0.2 en tout cas ), qu'il suffit de renommer en .so et d'installer à la main :
/usr/local/lib/libOgreMain.so
/usr/local/lib/libPlatformManager.so
/usr/local/lib/OGRE/Plugin_BSPSceneManager.so
/usr/local/lib/OGRE/Plugin_CgProgramManager.so
/usr/local/lib/OGRE/Plugin_OctreeSceneManager.so
/usr/local/lib/OGRE/Plugin_ParticleFX.so
/usr/local/lib/OGRE/RenderSystem_GL.so
S'il n'existent pas, il reste la resource de lancer des "make clean" dans chacun des repertoires du platform mananger, du render system et des plugins, supprimer toi même les .a, la et .lai non virés.
Aprés en faisant un make, make install dans ces repertoires, tu devrais générer les .so
En te souhaitant bonne chance :)
PS : si tu comptes developper avec Ogre, pense a copier le fichier OgreMain/include/config.h dans /usr/local/include/OGRE/ ( ce n'est pas toujours fait )
# Code "relocatable"...
Posté par benja . Évalué à 1.
http://cia.navi.cx/stats/project/e/e17/apps/e/.message/6202325(...)
# mouais...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Utiliser des variables d'enviornnement peut vite devenir assez bordélique et arrivent finalement un à truc qui peut ressembler à une certaine base de registres...
"La première sécurité est la liberté"
[^] # Re: mouais...
Posté par Dring . Évalué à 1.
Ca dépend des petits en question. Moi, ça ne me choque pas d'imaginer en tout cas que tout ça se fasse dynamiquement ; par contre, tout définir à la compilation me paraît un peu frapadingue.
Ben c'est un peu ce qu'on fait avec $PATH, $SH_LIB, et j'en passe.
Là où je rejoins complètement Mildred, voire le dépasse, c'est que pour un novice (que je suis) les autotools semblent être un incroyable merdier, complexe et lent.
Pour compiler kmymoney2 (excellent soft au demeurant), il me faut presque 1 heure sur mon Athlon 1ghz, et j'ai franchement l'impression qu'un tiers du temps est consommé par les autotools et non par gcc et autres générateurs de code.
Je sais qu'ils ne servent pas à rien, et notamment assurent la compilation multiplateforme en s'assurant des éléments disponibles sur la machine, mais quand même, ça fait chier. J'oserais jamais compiler un KDE, ou installer une Gentoo, dans ces conditions.
Quant à trouver une alternative, je ne rêve pas trop...
# libtool
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
# Compilation vs configure
Posté par dab . Évalué à 5.
Plus précisément, la destination du logiciel est précisée au configure et non à la compilation.
Supposons par exemple que tu ais fait un ./configure --prefix=/usr/local/cestlaquecest lors de la configuration de ton programme et que celui-ci ait été installé par conséquent dans ce répertoire, rien ne t'empêche plus tard de refaire un ./configure --prefix=/maintenantcestlaquecest et que le programme soit installé dans ce nouveau répertoire sans que tous les fichiers soient recompilés.
[^] # Re: Compilation vs configure
Posté par qstone . Évalué à 1.
Faut pas confondre la configuration du build avec ./configure et la configuration de l'appli, qui peut passer par exemple par un fichier texte dans /etc
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.