Discussion :

[OliBi]

Bonjour tout le monde !

Après avoir lu les tutos sur la création de fichier makefile, je n'arrive toujours pas à me simplifier la vie (ce qui devrait être le cas avec l'utilisation de makefile...)

Mon souci, j'ai développé quelques petits modules me permettant de gérer les différentes options de mon programme. J'ai enregistré chaque module dans un dossier contenant un .c un .h et un makefile.
Les modules sont censés être le plus indépendant possible, mais, on se retrouve avec des liens inévitables comme le module de traitement d'erreur.

Maintenant, je suis en train de faire les programmes qui utilisent chacun de ces modules pour en faire un programme général. Par exemple le module qui émet un message sur la liaison série utilise le module de connexion à la liaison série, de partage de mémoire, et le module de gestion d'erreur.

Bref, un bon schéma vaut mieux qu'un long discours:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
/src/ModuleErreur/erreur.c
                 /erreur.h
                 /makefile
/src/ModuleMemoire/memoire.c // utilise le module erreur
                  /memoire.h
                  /makefile
/src/ModuleSerie/serie.c // utilise aussi le module erreur
                /serie.h
                /makefile
/ModulePrinc/main.c // utilise les modules erreur, mémoire et série.
            /define.h
            /makefile

Actuellement, je suis obligé de copier les fichiers sources dans le répertoire du module principal, de retirer à la main les fonctions main() et les includes des fichiers (sinon je me retrouve par exemple avec 2 fois l'inclusion du module de gestion d'erreur).

Je compile avec un cross-compiler vers un ARM9. Mon makefile (qui ne fonctionne pas) se présente actuellement ainsi:

Code :

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

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
# differents types de fichiers 
.SUFFIXES:.o.c
 
#---------------------------------
# INITIALISATION DES VARIABLES 
#---------------------------------
 
# Indiquer le compilateur (cc ou gcc)
CC=arm-elf-gcc
 
# Les chemins ou se trouvent les fichiers a inclure
#INCLUDES=-I/usr/openwin/include
 
# Options de compilation. Mettre -ggdb (gcc) ou -g pour debugger
#CFLAGS=  ${INCLUDES} -c -O2
 
# Options pour le linker. Mettre -g -static (gcc) ou -g -Bstatic (cc) pour debugger
LFLAGS= -Wl,-elf2flt="-r -z -s 32768"
 
# Les librairies avec lesquelle on va effectueller l'edition de liens
#LIBS= -lX11
LIBS=
 
# Les fichiers sources de l'application
FILES=erreur.c memoire.c serie.c main.c
 
#-----------
# LES CIBLES
#-----------
 
all: modulePrinc clean2
 
modulePrinc: clean $(FILES:.c=.o) 
	$(CC) $(LFLAGS) -o $@ $(FILES:.c=.o) $(LIBS)
 
clean:
	rm -f $(FILES:.c=.o) modulePrinc
 
clean2:
	rm -f *.o *.gdb
 
#-----------------------------------------------------------------------------
# LES REGLES DE DEPENDANCE. Certaines sont implicites mais je recommande d'en mettre une par fichier source. 
#-----------------------------------------------------------------------------
 
#main.o:erreur.c memoire.c serie.c main.c
 
#---------------------------------
# REGLES DE COMPILATION IMPLICITES
#---------------------------------
 
.c.o:; ${CC} ${CFLAGS} $*.c

Voilà c'est un fichier que j'ai trouvé sur le net sur le site d'une université, et je l'ai adapté à ma sauce pour que ça fonctionne ainsi, lorsque tous les fichiers sont importés depuis les autres répertoires.
Pour faire de la compilation multirepertoires j'ai essayé de remplacer erreur.c par ../ModuleErreur/erreur.c
Seulement il me dit que le module ../ModuleErreur/erreur.o n'existe pas au moment ou je compile...
De plus, si tant est que j'arrivais à compiler, j'aurais le problème de multiples instances de main() qui n'est censé exister que dans le module principal (mais nécessaire dans chaque module source pour faire le débug et les tests de base). Bref, toujours en allant chercher sur le net, j'ai trouvé qu'on pouvait définir des variables pour faire de la compilation conditionnelle. Je me suis dit qu'à cela ne tienne, c'est parti !! J'encadre mes fonctions main avec des jolis #ifdef DEBUG et #endif (c'est magnifique n'est-ce pas ?) et j'ajoute le -DDEBUG dans la ligne de compilation de mon programme c'est à dire ici

Code :

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

	$(CC) $(LFLAGS) -DDEBUG -o $@ $(FILES:.c=.o) $(LIBS)

Mais la variable ne semble rien changer puisque les bibliothèques et le main encadré par le #ifdef #endif sont quand même compilés lorsque le debug n'est pas défini...

Du coup, c'est surtout le premier problème que je souhaite résoudre, mais si vous arrivez à m'aider à résourde les 2 c'est encore mieux

[nicolas.sitbon]

Actuellement, je suis obligé de copier les fichiers sources dans le répertoire du module principal, de retirer à la main les fonctions main() et les includes des fichiers (sinon je me retrouve par exemple avec 2 fois l'inclusion du module de gestion d'erreur).

Tu développes un programme avec plusieurs fonctions main()? soit il y a un problème de conception à la base, soit tu n'as pas compris à quoi servait un module.

[OliBi]

Ben j'ai peut être mal employé la définition de module en fait...

Ce que j'entends par "module", c'est une tâche qui tourne en permanence, acquiert des données depuis un périphérique extérieur, et les inscrit dans un segment de mémoire partagée.
D'où la raison d'avoir plusieurs main() (je dois gérer 3 ports série différents, avec des fréquences d'actualisation des données différentes).
Ce ne sont pas réellement des modules, mais plutôt des morceaux de programmes capables de tourner indépendamment et lorsqu'ils sont mis bout à bout, forme mon application finale...
Vu que je n'ai pas beaucoup d'expérience, cette solution me plaisait, mais je ne sais pas trop si c'est adapté... avec un peu de recul maintenant, je me dis que j'aurais mieux fait de tout développer dans un seul main(), celui qui reçoit les informations le plus souvent...

Bref, en fait c'était pas la question de départ et je crois que je m'éloigne du sujet