URL: https://linuxfr.org/users/mildred/journaux/les-autotools-lorsque-ca-ne-marche-pas Title: Les autotools: lorsque ca ne marche pas ... Authors: Mildred Date: 2005年07月31日T19:28:00+02:00 Tags: Score: 0 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/(...)](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(...)](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.