[LINUX] se passer d'IDE ?

Bonjour,
depuis longtemps je compile des logiciel -non ecrit par moi même- via la console en tapant des commandes comme :

Code:

---

1 2 3

./configure make make install

---

par contre j'ai toujours que travaillé avec code::blocks. Aujourd'hui j'aimerais faire comme les grands et me passer d'IDE.

Le problème ? avec code::block je me contenté de lui dire dans quels répertoires cherches les lib, include...
alors qu'avec un makefile il faut taper des fichiers comme configure.ac galère galère quand on un un projet avec plein de fichier et qui cherche des en-tête à l'autre bout du disque dur dans un dossier reculé...

ce problème ma semblé résolu quand j'ai découvert autotools. Problème les tuto que j'ai trouvé disent d'employer autoscan et de renommer le fichier de sortie configure.scan en configure.ac... et bien j'ai des erreurs lorsque je tape make...

et le pire c'est que aucun tutorial que j'ai vu ne précise comment définir un dossier contenant des fichiers en-têtes qui se situe dans un dossier lointain...

et bien entendu il y a quand même des fichiers à taper à la main!...


CMake quant à lui me semble plus simple d'utilisation, mais là je n'ai pas trouvé comment lui dire de prendre en compte des fichiers en-tête situé dans moins lointain dossier...

bref
je suis perdu,
je vois pas comment m'en sortir,
je manque d'expérience,
je demande votre aide...

Salut,

Citation:

---

Envoyé par TocTocKiéLà?

ce problème ma semblé résolu quand j'ai découvert autotools. Problème les tuto que j'ai trouvé disent d'employer autoscan et de renommer le fichier de sortie configure.scan en configure.ac... et bien j'ai des erreurs lorsque je tape make...

---

Les fichiers configure.ac ne sont pas encore prêts à être utilisés avec sh : il faut encore lancer dessus aclocal, autoconf et automake.



À part ça, tu peux opter pour une autre solution, pour générer tes makefiles : un outil comme qmake peut te les fournir. Il est prévu pour Qt, mais il n'utilisera aucun des outils (rcc, moc...) s'ils ne sont pas nécessaires. En le lançant dans un répertoire, il va te générer tes makefiles. Si les paramètres par défaut te suffisent, pas besoin de sortir une plus gross artillerie.

En fait, pourquoi veux-tu utiliser les scripts configure ? Il est censé générer des makefiles et d'autres fichiers d'en-tête pour adapter un logiciel ou une librairie à une configuration particulière. Quand il n'y en a pas besoin, on distribue directement un Makefile.

Citation:

---

Envoyé par TocTocKiéLà?

CMake quant à lui me semble plus simple d'utilisation, mais là je n'ai pas trouvé comment lui dire de prendre en compte des fichiers en-tête situé dans moins lointain dossier...

---

Tu dois utiliser la macro INCLUDE_DIRECTORIES.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

PROJECT (MonProjet)   INCLUDE_DIRECTORIES (MonDossier)   ADD_EXECUTABLE (MonExe MonSource1.cpp MonSource2.cpp )   TARGET_LINK_LIBRARIES (MonExe MaLibrairie)

---

Si les entêtes que tu cherches sont ceux d'une librairie plutôt connue, il y a de fortes chances que quelqu'un ait écrit un module CMake pour le trouver. L'emplacement des entêtes est alors paramétrable via l'interface de CMake. Cela donnerait quelque chose comme

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

PROJECT (MonProjet)   FIND_PACKAGE (MaLibrairie REQUIRED)   INCLUDE_DIRECTORIES (${MaLibrairie_INCLUDE_DIRS})   ADD_EXECUTABLE (MonExe MonSource1.cpp MonSource2.cpp )   TARGET_LINK_LIBRARIES (MonExe ${MaLibrairie_LIBRARIES})

---

Je t'invite à lire l'initiation de Developpez.com.
http://florian-goujeon.developpez.co...ke/initiation/

Citation:

---

Envoyé par TocTocKiéLà?

ce problème ma semblé résolu quand j'ai découvert autotools.

---

Je travaillais avant avec les autotools mais j'ai très vite laissé tombé quand j'ai découvert CMake. Les autotools étaient beaucoup trop compliqués à utiliser (vive sh et m4 :-( ), limités aux Makefiles alors que CMake dispose d'un langage très intuitif et permet de générer des Makefiles mais aussi des projets pour des IDEs.

merci de ta réponse,
j'arrive à compiler comme je veux maintenant avec CMake. Par contre j'ai une question, si je mets :

Code:

---

1 2 3 4 5 6 7 8

(...) LINK_DIRECTORIES(../lib) (...) target_link_libraries( toto libtest.so )

---

je compile bien en dynamique ? si oui et sachant que ma bibliothèque se trouve dans le dossier /home/user/toto/lib, pourquoi quand je renomme le dossier lib par bil je peux exécuter mon programme ?

edit ::
en fait il semblerait que la ligne :

Code:

---

LINK_DIRECTORIES(../lib)

---

est ignoré, car j'arrive à faire (après un make clean) un cmake suivi d'une compilation sans accro. Donc qu'il utilise la librairie que j'ai dans /usr/lib/local, ce que je ne veux pas!

Code:

---

target_link_libraries(toto ../lib/libtest.so)

---

Pour les raisons que tu évoques, il est recommandé de passer le chemin complet (un peu comme dans Visual Studio finalement).

Je suis un peu surpris par le fait qu'il semble ignorer ta commande LINK_DIRECTORIES. Pour vérifier la librairie utilisée par un exécutable, un petit coup de ldd.

Code:

---

ldd MonExe

---

Pour information, CMake utilise le rpath à la compilation. L'exécutable retient le chemin des librairies dynamiques qu'il utilise. A l'installation, cette information est supprimée de l'exécutable.

EDIT
Au passage, petite question mais je ne pense pas que ce soit le cas, est-ce que libtest est une librairie de ton projet ? Tu sembles indiquer qu'elle vient d'un projet externe.

Citation:

---

Au passage, petite question mais je ne pense pas que ce soit le cas, est-ce que libtest est une librairie de ton projet ? Tu sembles indiquer qu'elle vient d'un projet externe.

---

Il s'agit des bibliothèques Ogre3D et OIS.

j'ai fait un test, j'ai renommé les bibliothèques respectivement libAffichage.so et libClavierSouris.so (ceux de mon répertoire lib), puis j'ai mis à jour le CMakeLists.txt avec cette nouvelle nomination. J'ai effacé toute trace de makefiles et des fichiers générés par cmake. Une fois compilé j'ai utilisé la commande ldd comme tu me l'as proposé (un type de commande que je cherchais depuis longtemps, merci) et là je vois que le binaire pointe sur les bibliothèques Ogre et OIS installées dans /usr/local/lib!

Visiblement il y a quelque chose qui m'échape...

pour expliquation, j'utilise actuellement un linux 32bit mais j'aimerais passer sous 64bit, par contre je devrais compiler en 32bits sous mon environnement 64bits. Je sais que ça n'a rien à voir, mais c'est pour expliquer pourquoi j'essai de forcer mon programme à utiliser les bibliothèques situées dans un repertoire lib que j'ai choisi.

Si il n'y a pas d'information dans le binaire sur où sont situés les librairies (via rpath donc), le linker dynamique cherche dans les chemins contenus dans $LD_LIBRARY_PATH l'emplacement possible des bibliothèques. Si tu n'a pas renseigné cette variable, il doit chercher dans les chemins par défault tel que /usr/lib:/usr/local/lib etc

Pour résoudre ton problème, tu dois donc éditer cette variable d'environnement pour pointer en premier lieu vers tes librairies installées en local.

Par curiosité, pourquoi installer un système 64bits pour compiler en 32bits derrière ?

Je ne suis pas tout dans tes essais... mais bon comme le propose zul, joue avec le LD_LIBRARY_PATH.

Citation:

---

Envoyé par zul

Par curiosité, pourquoi installer un système 64bits pour compiler en 32bits derrière ?

---

Pour trois raisons :
1) parce que j'ai des ordinateurs équipés de proc 64bits.

2) compiler en 32bits pour un maximum de compabilité avec les ordinateurs où installer mon programme, qui eux ne sont pas forcément en 64bits.

3) j'ai par le passé, eu du mal à compiler (voir incapable...) certaines bibliothèques écrites à la bases pour du 32bits, j'étais donc revenus en 32bits. Bon je me rappelle plus lesquelles...

par contre pour rpath, je n'arrive pas à l'utiliser avec cmake, je ne comprends pas la doc de cmake à ce sujet.

Si vous avez un exemple, je suis preneur...

bien, j'ai avancé à l'aide de ce lien :
http://www.cmake.org/Wiki/CMake_RPATH_handling

Code:

---

SET(CMAKE_INSTALL_RPATH "/home/user/toto/lib")

---

me permet de définir un chemin "prioritaire" pour la recherche de bilbiothèque au moment de l'exécution du binaire.

Par contre ça été la galère pour trouver le bon chemin relatif... je rappel mon arborescence :

Citation:

---

/home/user/toto
/home/user/toto/bin

toto (fichier binaire)

/home/user/toto/src

main.cpp

/home/user/toto/lib

libtest.so

---

j'ai un CMakeLists.txt dans /home/user/toto "la racine de mon projet" contenant :

Code:

---

1 2 3

cmake_minimum_required(VERSION 2.6) PROJECT(toto) ADD_SUBDIRECTORY(src)

---

et un CMakeLists.txt dans /home/user/toto/src contenant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

# use, i.e. don't skip the full RPATH for the build tree SET(CMAKE_SKIP_BUILD_RPATH FALSE)   # when building, don't use the install RPATH already # (but later on when installing) SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)   # the RPATH to be used when installing SET(CMAKE_INSTALL_RPATH "lib")   # add the automatically determined parts of the RPATH # which point to directories outside the build tree to the install RPATH SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)     LINK_DIRECTORIES(../lib)   LINK_LIBRARIES(test)   SET(main main.cpp) ADD_EXECUTABLE(toto ${main})     set_target_properties( toto PROPERTIES RUNTIME_OUTPUT_DIRECTORY ../bin )

---

comme vous pouvez le constater j'ai

Code:

---

SET(CMAKE_INSTALL_RPATH "lib")

---

et non pas

Code:

---

SET(CMAKE_INSTALL_RPATH "../lib")

---

ce que j'explique par le fait que je lance cmake et make depuis le dossier /home/user/toto alors que je pensais que le lien dans le CMakeLists.txt été relatif au dossier (et j'y ai passé de temps avant de comprendre...) le contenant comme par exemple pour la ligne

Code:

---

LINK_DIRECTORIES(../lib)

---

J'en conclu que les commandes SET() devraient plutôt être inscrites dans le CMakeLists.txt contenu dans le dossier toto.

Qu'en pensez-vous, remarque, curiosité, critique ?

Personnellement, je n'utilise pas le rpath à l'installation. L'exécutable est alors figé avec un chemin en dur et il n'est plus possible de déplacer la librairie ou l'exécutable, mais cela reste à vérifier. A mettre en relation avec les paquets relogeables.

Par contre, je trouve le rpath très pratique pour exécuter des tests unitaires dans l'arbre de compilation. Inutile de se soucier du lancement de l'exécutable de test, il est assuré d'être lancé avec les bonnes librairies. Sous Windows, il faut placer DLLs et exécutables dans le même répertoire pour être sûr que les exécutables se lancent avec les bonnes DLLs.

Tu as essayé la variable LD_LIBRARY_PATH ? Ca me paraît beaucoup moins contraignant que le rpath fixé à l'installation.

j'aurai effectivement pu me passer de la commande rpath à l'installation et l'utiliser à l'exécution, mais c'est parce que j'avais temporairement déplacer la librairie libtest.so du dossier /usr/local/lib donc l'installation aurait échouée.

pour la commande que tu me proposes :

Code:

---

LD_LIBRARY_PATH

---

si je ne dis pas de bétise - il faudrait que je configurer tous les ordinateurs sur lesquels j'aimerais employer mon programme non ?

mon objectif étant de le diffuser, j'aimerais un binaire et toutes les bibliothèques dans un fichier compressé afin de facilité l'installation et la supression.

je m'y prends peut-etre mal ?

Citation:

---

Envoyé par TocTocKiéLà?

mon objectif étant de le diffuser, j'aimerais un binaire et toutes les bibliothèques dans un fichier compressé afin de facilité l'installation et la supression.

---

C'est ce qu'on appelle un paquetage. CMake permet de générer des RPMs et des paquets Debian. De manière plus simple, il permet aussi de générer des scripts d'installation. Tu devrais t'y intéresser si tu veux diffuser ton programme.

Pour ce qui est du LD_LIBRARY_PATH, tu peux écrire un petit script sh qui s'assure de positionner le bon LD_LIBRARY_PATH avant de lancer l'exécutable. Bon, d'accord ce n'est pas l'exécutable qui est directement lancé mais bon ça peut passer.

Citation:

---

Envoyé par TocTocKiéLà?

J'aurai effectivement pu me passer de la commande rpath à l'installation et l'utiliser à l'exécution

---

Euh... je n'ai pas tout compris. Tu parles de l'exécution une fois installé. Cela ne change pas grand chose. Une fois installé, l'exécutable est marquée avec le chemin vers la librairie en dur. Je ne sais pas ce qui se passe quand on déplace la librairie dans ce cas. Est-ce que le système se débrouille quant même ?

Est-ce si grave le mélange entre les librairies 32 et 64 bits ? Est-ce que le système ne se débrouille pas pour choisir la bonne librairie dynamique ?

Si ça peut t'aider...
http://www.redhat.com/magazine/009ju...ures/multilib/

Citation:

---

Euh... je n'ai pas tout compris. Tu parles de l'exécution une fois installé. Cela ne change pas grand chose. Une fois installé, l'exécutable est marquée avec le chemin vers la librairie en dur.

---

En fait ce que je voulais dire c'est que on peut définir un rpath qui peut être utilisé pendant l'installation (<=> compilation) ET/OU peut être utilisé pendant l'exécution, est-ce que je suis clair ? car il est tard...

Citation:

---

Je ne sais pas ce qui se passe quand on déplace la librairie dans ce cas. Est-ce que le système se débrouille quant même ?

---

pour faire cours, oui.
Dans l'ordre il va d'abord chercher la bibliothèque dans le dossier indiqué par rpath, s'il ne la trouve pas il ira chercher dans les dossiers du système de fichiers indiqués comme contenant des bibliothèques.

Citation:

---

Est-ce si grave le mélange entre les librairies 32 et 64 bits ? Est-ce que le système ne se débrouille pas pour choisir la bonne librairie dynamique ?

---

On peut utiliser des bibliothèques 32bits sur un système 64bits, je l'ai déjà fait; l'exemple le plus commun est la bibliothèque d'adobe pour lire les flashs, la version 64bits n'existait pas il y a quelques mois, fallait se rabattre sur la 32bits. Aujourd'hui je ne sais pas si elle existe, je verrai ça assez prochainement quand j'installerai à nouveau mes linux en 64bits...
Par contre je ne pourrais plus dire comment j'avais fait (j'avais trouver la solution sur un forum ubuntu)...
j'espère avoir été à peu près clair, car là je suis claqué... j'irai voir ton lien demain.

Citation:

---

Envoyé par TocTocKiéLà?

On peut utiliser des bibliothèques 32bits sur un système 64bits

---

Oui avec des exécutables 64 bits. Mais est-ce qu'un exécutable 32 bits peut utiliser des librairies 64 bits ? J'en doute fortement.

Citation:

---

Envoyé par aoyou

Oui avec des exécutables 64 bits. Mais est-ce qu'un exécutable 32 bits peut utiliser des librairies 64 bits ? J'en doute fortement.

---

je n'ai jamais fait de tests mais j'avais pu lire sur un autre forum que la réponse est non.

Citation:

---

Oui avec des exécutables 64 bits. Mais est-ce qu'un exécutable 32 bits peut utiliser des librairies 64 bits ? J'en doute fortement.

---

ça va dépendre de l'archi de ton OS, s'ils ont fait un effort la dessus ou pas....

http://www-03.ibm.com/systems/power/...ons/index.html

merci pour vos divers infos, comme on est entrain de déborder du sujet initial, je le mets en résolu, puisque aujourd'hui je travail sans IDE, le problème est réglé

merci à vous :ccool: