Discussion :

[Analou]

Bonjour,
Je souhaite développer un programme avec les autotools (jusque là, pas de problèmes).
Le truc, c'est que je voudrais que ceux-ci créent d'abord une bibliothèque statique (à partir de .c et de .h).
Est-ce possible?
Merci d'avance

[kwariz]

Bonjour,

oui c'est possible.
Ensuite c'est un peu différent si tu utilises ou non libtool (je te conseille fortement de l'utiliser), et si cette bibliothèque statique est une bibliothèque que tu vas distribuer ou si ce n'est qu'une bibliothèque de confort, c'est-à-dire que tu vas la créer puis uniquement l'utiliser pour la lier avec d'autres cibles sans jamais la distribuer.

[Analou]

Cette bibliothèque ne sera jamais distribuée, elle me servira seulement à créer un exécutable en la liant avec des .c .
Je n'ai jamais utilisé libtool, mais je viens de lire sur wikpédia :

libtool s'utilise très mal dans les environnements de compilation croisée, le fait qu'il enregistre des informations en dur dans les fichiers .la (chemin vers les bibliothèques...) peut poser plus de problèmes que cet outil n'en résout.

Or, à terme, mon programme sera compilé sur d'autres cibles.

Sinon, j'ai trouvé ça:

Building a library is much like building a program. In this case, the name of the primary is LIBRARIES. Libraries can be installed in libdir or pkglibdir.

See A Shared Library, for information on how to build shared libraries using libtool and the LTLIBRARIES primary.

Each _LIBRARIES variable is a list of the libraries to be built. For instance, to create a library named libcpio.a, but not install it, you would write:

noinst_LIBRARIES = libcpio.a
libcpio_a_SOURCES = …

Est-ce que ça pourrait convenir?

[kwariz]

Ah oui ... j'ai oublié que tu avais déjà posté une question sur la compilation croisée.
Tu n'auras pas de problème avec libtool même en compilation croisée si tu utilises une bibliothèque de confort.
Mais l'exemple que tu donnes est parfait

[Analou]

Ok, dernière question alors :
J'ai énormément de .h pour créer ma bibliothèque, et ceux-ci sont regroupés dans différents répertoires INCLUDE.
Est-ce possible de faire quelque chose comme :

Code :

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

1
2
noinst_LIBRARIES = libcpio.a
libcpio_a_SOURCES = dossier1/dossier2/INCLUDE dossier3/dossier4/dossier5/INCLUDE

(Il n'y a que des .h dans les INCLUDE)

[Analou]

Je crois que je raconte n'importe quoi, on ne doit pas mettre les .h dans _SOURCES.

[kwariz]

non ... pas dans les souces
mais il va falloir indiquer où les trouver avec libcpio_a_CFLAGS (je crois) et indiquer aussi aux cibles où les trouver ensuite.

Le plus simple est de tout regrouper dans un répertoire ...

[Analou]

Le plus simple est de tout regrouper dans un répertoire ...

J'ai pas le droit

Je vais regarder ce que tu m'as dit.

[Analou]

J'ai trouve ça :

The value of the make variable VPATH specifies a list of directories that make should search. Most often, the directories are expected to contain prerequisite files that are not in the current directory; however, make uses VPATH as a search list for both prerequisites and targets of rules.

For example,

VPATH = src:../headers

specifies a path containing two directories, src and ../headers, which make searches in that order.

With this value of VPATH, the following rule,

foo.o : foo.c

is interpreted as if it were written like this:

foo.o : src/foo.c

assuming the file foo.c does not exist in the current directory but is found in the directory src.

Mais je ne suis pas sûre que cela puisse m'aider.

Sinon j'ai ça :

So what if we want to start putting our .h files in an include directory, our source code in a src directory, and some local libraries in a lib directory? Also, can we somehow hide those annoying .o files that hang around all over the place? The answer, of course, is yes. The following makefile defines paths to the include and lib directories, and places the object files in an obj subdirectory within the src directory. It also has a macro defined for any libraries you want to include, such as the math library -lm. This makefile should be located in the src directory. Note that it also includes a rule for cleaning up your source and object directories if you type make clean. The .PHONY rule keeps make from doing something with a file named clean.
Makefile 5

IDIR =../include
CC=gcc
CFLAGS=-I$(IDIR)

ODIR=obj
LDIR =../lib

LIBS=-lm

_DEPS = hellomake.h
DEPS = $(patsubst %,$(IDIR)/%,$(_DEPS))

_OBJ = hellomake.o hellofunc.o
OBJ = $(patsubst %,$(ODIR)/%,$(_OBJ))


$(ODIR)/%.o: %.c $(DEPS)
$(CC) -c -o $@ $< $(CFLAGS)

hellomake: $(OBJ)
gcc -o $@ $^ $(CFLAGS) $(LIBS)

.PHONY: clean

clean:
rm -f $(ODIR)/*.o *~ core $(INCDIR)/*~

So now you have a perfectly good makefile that you can modify to manage small and medium-sized software projects. You can add multiple rules to a makefile; you can even create rules that call other rules. For more information on makefiles and the make function, check out the GNU Make Manual, which will tell you more than you ever wanted to know (really).

Mais là, je comprends pas tout...

[Metalman]

En gros, ça dit que c'est un beau Makefile qui va chercher les .h dans le dossier include (../include), les libs dans le dossier lib (../lib), et les .o dans le dossier obj (obj)

En gros l'arborescence semble être ça :

projet
projet/src
projet/src/Makefile (celui ouvert contenant le blabla)
projet/src/foo.c
projet/src/obj
projet/src/obj/foo.o
projet/include
projet/include/foo.h
projet/lib
projet/lib/bar.a

EDIT : mais si ton but est d'utiliser les tototools (chose que je n'ai jamais réussi encore...), pas sûr que ça soit la bonne idée que de mettre un simple Makefile ^^'

[Analou]

Merci, je vais étudier ça de plus près.
Mon but est bien d'utiliser les autotools, je vais donc caser ce bout de code dans un Makefile.am

[Metalman]

Mais attention !

Car ce bout essaye de compiler uniquement hellomake.o et hellofunc.o il me semble....
Je ne sais pas trop où il faut déclarer les .c/.h...

[kwariz]

Tu n'as pas le droit de modifier l'architecture de ton projet ?
Quelle est l'arborescence que tu utilises et où sont les headers que tu utilises ?

L'idée c'est de définir les flags par cible (ou pour totues les cibles) en spécifiant l'option -I<chemin vers les includes> (c'est un i majuscule),

[Analou]

Tu n'as pas le droit de modifier l'architecture de ton projet ?

Non, je dois séparer les .h et les .cpp

Quelle est l'arborescence que tu utilises et où sont les headers que tu utilises ?

Voici mon arborescence:
PROJET

LIB TEST

INCLUDE SRC_C SRC_C
.h .cpp .cpp

Je dois d'abord créer un bibliothèque statique avec les fichiers présents dans LIB, puis créer un programme en utilisant cette bibliothèque avec les .cpp dans TEST/SRC_C

[Analou]

Je vais créer un autre sujet, car sans parler de mes problèmes de localisation de .h, je n'arrive même pas à créer ma librairie en mettant les .h et les .cpp dans le même dossier, je ne peux donc pas tester si modifs proposées marchent.
En tout cas, je continue à suivre cette discussion avec attention.

[kwariz]

Si je comprends bien tu as une arborescence qui ressemble à :

Code :

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

1
2
3
4
5
6
7
PROJET
|-- LIB
|   |-- INCLUDE
|   `-- SRC_C
`-- TEST
    |-- INCLUDE
    `-- SRC_C

Dans PROJET ton Makefile.am pourrait ressembler à :

Code :

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

SUBDIRS=LIB TEST

On commence par construire la biliothèque puis ensuite le programme TEST.

Dans LIB tu en as un autre qui pourrait être :

Code :

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

1
2
3
noinst_LIBRARIES=libtest.a
libtest_a_SOURCES=SRC_C/source1.cpp SRC_C/source2.cpp
libtest_a_CPPFLAGS=-I$(sourcedir)/INCLUDE

La dernière ligne signifie que tu ajoutes lors du preprocessing de tes sources un chemin où on ira chercher tes includes. Ici on donne $(sourcedir)/INCLUDE qui va se traduire par «un chemin relatif vers l'endroit où se trouve Makefile.am puis on descend dans INCLUDE».
Comme on l'a préfixé avec libtest_a cette option ne sera appliquée que lorsqu'on va compiler libtest. Si on avait voulu avoir cette option active pour toutes les cibles on aurait utilisé un AM_CPPFLAGSOn peut d'une manière similaire configurer le programme dans le répertoire TEST avec un Makefile.am :

Code :

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

1
2
3
bin_PROGRAMS=test
test_SOURCES=SRC_C/test_source1.cpp SRC_C/test_main.c
test_CPPFLAGS=-I$(sourcedir)/INCLUDE -I$(sourdir)/../LIB/INCLUDE

Le CPPFLAGS contient cette fois-ci deux options. La première pour indiquer l'endroit des headers de l'application et la seconde pour indiquer où trouver les headers de la bibliothèque.

Remarque: CPPFLAGS est utilisé lors de la phase de preprocessing et ce flag est utilisé aussi bien quand on compile en C qu'en C++.

[Analou]

Merci pour ta réponse.
Je fais autoreconf et configure, et ça se passe bien.

Cependant, j'ai encore une erreur :
Quand je fais make, il est dit qu'il me manque certains .h, alors qu'ils sont bien dans le bon sous dossier (LIB/INCLUDE) avec les autres .h.

[kwariz]

C'est make qui râle sur une dépendance ou ton compilateur ?
Quel est la message d'erreur que tu reçois ?

[Analou]

Voici les erreurs:

Code :

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

1
2
3
4
SRC_C/recalage_translation.cpp:42:48: error: recalage_translation.h: No such file or directory
SRC_C/recalage_translation.cpp:44:29: error: cops_tifdai_api.h: No such file or directory
SRC_C/recalage_translation.cpp:52:25: error: Matrix_vc6.h: No such file or directory
SRC_C/recalage_translation.cpp:60:37: error: cops_trace_elapsed_time.h: No such file or directory

Et pourtant, quand je fais ls dans PROJET/LIB_/INCLUDE, les librairies sont bien présentes.

[kwariz]

Et la ligne de la commande exécutée contient bien l'option -I ?