Discussion :

[Analou]

Bonjour,
J'utilise les autotools et souhaiterais créer deux "niveaux" de configure.ac.
Je m'explique:
J'ai une arborescence de ce type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
PROJET
    |___ SRC
    |     |____ .c
    |
    |___ LIB
          |____LIB1 (.h)
          |____LIB2 (.h)

Je souhaiterais que mes librairies soient portables et facilement compilables(qu'elles aient un propre outil de génération), et je compte créer des configure.ac/makefile.am pour les générer.

Ensuite, j'ai besoin de ces librairies pour créer un exécutable en les linkant aux .c. Pour créer cet exécutable, je vais aussi faire des configure.ac/Makefile.am, et il faudrait que lorsque je vais ./configure dans PROJET, ce configure.ac "appelle" d'abord le configure.ac pour qu'il génère les librairies.

Merci d'avance pour votre aide, et désolée pour l'exotisme de la question.

[kwariz]

Hello,

l'intérêt d'avoir un sous projet géré indépendamment avec les autotools est qu'il peut justement vivre sa vie indépendamment
Il n'y en a en revanche aucun si ta bibliothèque est uniquement utilisée par ton appli.

Pour réaliser ça tu peux simplement utiliser la macro AC_CONFIG_SUBDIRS qui prend pour paramètre la liste des sous répertoires qui sont également à configurer par un configure.
Ensuite dans ton top Makefile.am tu listes dans le bon ordre les sous répertoire à construire dans la variable SUBDIRS.

Tu peux trouver un petit exemple dans la doc autoconf : Nesting Packages.

[Analou]

Super, merci beaucoup!
Est-ce que c'est possible de faire la même chose avec une bibliothèque dynamique?

[kwariz]

oui .... peu importe la profondeur ou la nature des packages.

[Analou]

Ce que je voulais demander, en fait, c'est si une bibliothèque dynamique se construit comme une statique (comme dans l'exemple, en remplaçant les .a par des .so).

[Analou]

Oh, je n'avais pas compris que bibliothèques partagées et dynamiques sont la même chose.

[Analou]

Une dernière question:
Dans le cas du lien que tu m'as donné, la librairie est dans un sous répertoire.
Mais si elle est située dans un répertoire différent, puis-je remplacer "hand" (le sous répertoire avec la librairie) par un lien absolu?

Dans le configure.ac

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AC_CONFIG_SUBDIRS([hand])

Dans le Makefile.am

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SUBDIRS = hand

[kwariz]

Les autotools ne sont pas vraiment prévus pour ça, même si ça pourrait fonctionner.
L'idée des subpackages est surtout de fournir à l'utilisateur, soit une version particulière de bibliothèque, soit de lui éviter d'avoir à downloader/installer séparément une bibliothèque sachant qu'on n'utilisera pas le subpackage si l'utilisateur l'a déjà.

Si tes bibliothèques sont intimement liées à ton programme (seul ton programme les utilise par exemple) alors ça a du sens de n'avoir qu'un projet sans subpackages.
Si tu prévois que ces bibliothèques pourraient être utilisées dans d'autres projets mais que ce n'est pas encore le cas, ça a du sens de les proposer en subpackages de ton projet.
Si elles sont déjà utilisées dans d'autres projets, et qu'elles sont déjà gérées par autotools alors ça a aussi du sens de le proposer en subpackages, mais ça a aussi du sens de les proposer comme packages indépendants.

Maintenant, si tu as un package pour tes bibliothèques, un autre pour ton programme tu peux également mettre les deux projets au même niveau chacun dans leur répertoire et proposer un script de compilation/création qui pourrait être tout aussi bien un script personnel ou un configure.ac. Dans ce dernier cas, cela revient à avoir un nouveau projet ayant deux sous packages : les bilbiothèques d'un côté, ton programme de l'autre.
Quelque chose du genre (seul les répertoires avec un configure.ac sont notés) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
BODY
  |
  +-- ARM
  |
  `-- HAND

Souvent quand on découvre les possibilités d'un outil on essaye de les utiliser même si ce n'est pas forcément une bonne chose
Le découpage de ton projet n'a peut-être pas besoin d'être aussi fin ni d'utiliser une hiérarchie aussi profonde.