compilation de programme multi-modules

Version imprimable

11/04/2012, 11h54
denispir

compilation de programme multi-modules

Bonjour,

Je commence à avoir besoin de modulariser et ai un petit souci sur la méthode pour compiler.

D'abord, quelle est la logique pour répartir le code entre fichiers .c et .h? Je croyais que les .h servaient juste à déclarer l'interface d'un module (ce qui est exporté), mais non seulement il semble qu'un .h puisse contenir du "vrai code", mais je suis tombé sur des exemples de .c qui importent (ou plutôt incluent) leur propre .h ! Ce qui montre que mes présuppositions sont fausses...

Ensuite, par exemple à propos d'un module "toolkit" que j'incluerais partout, malgré l'usage d'un .h et son inclusion, la phase de lien m'envoie des erreurs dès que j'utilise une fonction définie en fait dans le fichier .c (mais bien déclarée dans le .h avec tout son typage de paramètres et de retour). Est-ce que C ou les compilateurs (gcc) ne font pas le lien implicite entre fichiers .c et .h correspondants? Sinon, comment faire moi-même ce lien pour qu'ils "comprennent" (sic)?

Enfin, comment inclure des fichiers qui ne sont pas dans le même répertoire, mais par exemple dans un répertoire au-dessus, parallèle, ou tout autre sous-répertoire dans le super-répertoire de mon projet?

Merci,
Denis
11/04/2012, 12h16
Bousk

Bonjour,

je suppose que tu travailles avec un IDE.
Qu'entends-tu par modules ? S'agit-il de module à part entière (header, lib) ou juste de header et .c d'un même projet ?
Dans le premier cas, il faut inclure le header correspondant, afin que le fichier connaisse les types, prototypes utilisables, et correctement linker la lib.
Dans le second cas, il faut... compiler le fichier, éventuellement inclure des header nécessaires, et inclure le header quand nécessaire par la suite, le fichier étant compilé avec le reste du programme.

Citation:

mais non seulement il semble qu'un .h puisse contenir du "vrai code", mais je suis tombé sur des exemples de .c qui importent (ou plutôt incluent) leur propre .h !

Oui un .h peut contenir du code.
Qu'y a-t-il de choquant à ça ?
Oui un .c inclut généralement (tout le temps ?) son propre .h, ne serait-ce que pour inclure les structures adéquates, et connaître tous les prototypes.

Regarde comment fonctionne la compilation, en particulier le préprocesseur et la directive include.
include insère le contenu du fichier. Donc du code dans le .h, ça ne dérange en rien. (attention aux erreurs "multiple définition")

Citation:

Ensuite, par exemple à propos d'un module "toolkit" que j'incluerais partout, malgré l'usage d'un .h et son inclusion, la phase de lien m'envoie des erreurs dès que j'utilise une fonction définie en fait dans le fichier .c (mais bien déclarée dans le .h avec tout son typage de paramètres et de retour). Est-ce que C ou les compilateurs (gcc) ne font pas le lien implicite entre fichiers .c et .h correspondants? Sinon, comment faire moi-même ce lien pour qu'ils "comprennent" (sic)?

Le C, contrairement à certains langages type JAVA a une particularité : il ne cache rien.
Ton programme fait exactement ce qui est écrit. Aucun lien implicite, aucune inclusion cachée, rien.
Si la phase de lien échoue, tu as très certainement oublié de lier le .lib (.a) correspondant. Dans le cas d'une lib externe.
S'il s'agit d'une lib interne, tu as dû oublier les dépendances, ou tout simplement d'implémenter la fonction, voire d'indiquer au compilateur de compiler le fichier source qui implémente la méthode.

Citation:

Enfin, comment inclure des fichiers qui ne sont pas dans le même répertoire, mais par exemple dans un répertoire au-dessus, parallèle, ou tout autre sous-répertoire dans le super-répertoire de mon projet?

Dans un IDE, tu peux aisément définir des include_path, tu peux réaliser le chemin relatif à un des include_path pour inclure le fichier.
Tu peux aussi réaliser le chemin relatif au fichier courant.
Un include n'est pas limité à un simple non de fichier (#include "header.h"), il s'agit d'un chemin, donc tout ce qu'on connait sur les chemins est utilisable (#include "../../dossier1/headder.h")

La majorité de tes questions trouveront réponse dans un cours qui traite de la chaîne de compilation. Il s'agit en général d'un des premier cours que l'on suit lorsqu'on suit un cursus pour apprendre le C.
11/04/2012, 13h26
bpy1401

Bonjour à tous

Code:

mais non seulement il semble qu'un .h puisse contenir du "vrai code", mais je suis tombé sur des exemples de .c qui importent (ou plutôt incluent) leur propre .h !

un .h est un fichier d'inclusion, il peut mais ne doit pas contenir du code. Il est la juste pour déclarer des objets utilisables pour d'autre modules.

Et la on va me dire: c'est quoi un module:

Un module permet de réaliser une fonctionnalité. Par exemple, dans du code embarque, un module pourras gérer une liaison série, une second module pour le timer, ou tout simplement une fonctionnalité applicative.

Le .h d'un module permet aux autre modules de connaitre les interfaces de ce module. En aucun cas, on doit y mettre du code. Si par exemple, ton .h est inclus par plusieurs modules différents, ton code sera dupliqué et tu va recevoir une rafale de messages d'injure.

Oui, un module C doit contenir son .h. La raison: Cela permet de vérifier que ton .h est cohérent avec ton C. Si tu as une déclaration de fonctions dans le .h avec un nombre de paramètres différent de ce que tu as dans un .c , le fait d'inclure le .h dans le .c va générer des messages d'erreurs.

Tout logiciel C dans l'industrie est modulaire. Tu es sur la bonne voie
A+
11/04/2012, 17h54
denispir

Citation:

Envoyé par bpy1401

Bonjour à tous

Code:

mais non seulement il semble qu'un .h puisse contenir du "vrai code", mais je suis tombé sur des exemples de .c qui importent (ou plutôt incluent) leur propre .h !

[...]
Le .h d'un module permet aux autre modules de connaitre les interfaces de ce module. En aucun cas, on doit y mettre du code. Si par exemple, ton .h est inclus par plusieurs modules différents, ton code sera dupliqué et tu va recevoir une rafale de messages d'injure.

D'accord, c'est comme ça que je comprenais les choses (avant de voir des contre-exemples ;-)

Citation:

Oui, un module C doit contenir son .h. La raison: Cela permet de vérifier que ton .h est cohérent avec ton C. Si tu as une déclaration de fonctions dans le .h avec un nombre de paramètres différent de ce que tu as dans un .c , le fait d'inclure le .h dans le .c va générer des messages d'erreurs.

Pour que cet sorte d'auto-contrôle fonctionne, en plus des définitions de choses déclarées mais non définies dans le .h (disons les fonctions), ne faut-il pas aussi re-coder dans le .c les éléments comme constantes ou types (pour lesquels il n'y a peut-être pas vraiment de distinction déclaration / définition qui fasse sens) ?

Je vais donc faire ainsi: pour chaque module (au sens courant du terme en programmation, pas seulement C) exporter toutes les déclarations dans le .h ; l'inclure et coder les définitions dans le .c. Et si c'est utile, je réintroduis les constantes et types dans le .c pour auto-contrôle.

Ca ne m'explique toujours pas pourquoi je n'arrive pas à inclure mon toolkit (un module avec des petits utilitaires). En fait, il est bien programmé comme indiqué juste ci-dessus: un .h avec les déclas, un .c qui donne les defs. Les modules qui l'utilisent incluent le .h avec "#include "toolkit.h" (il est placé dans le même dossier pour ces essais -- un problème à la fois); est-ce que ce n'est pas suffisant? Qu'est-ce que je ne comprends pas? En fait, il me semble que je procède exactement comme avec les modules de la stdlib... donc ça devrait marcher (?).

Denis
11/04/2012, 19h52
gerald3d
Comme nous n'avons pas les messages d'erreur que tu obtiens nous sommes obligés de supposer.

Lorsque tu crées un "module", c'est à dire un .h avec .c il faut interdire la déclaration multiples de ces mêmes fonctions. Pour faire cela il faut inclure toutes tes déclarations dans le .h entre :
Code:

1 2 3 4 5 6 #ifndef MA_BIBLIO #define MA_BIBLIO /* À partir d'ici on trouve les déclarations des structures et prototypes. */ ... #endif

Citation:
Lorsque tu crées un "module", c'est à dire un .h avec .c il faut interdire la déclaration multiples de ces mêmes fonctions. Pour faire cela il faut inclure toutes tes déclarations dans le .h entre :
Code:

1 2 3 4 5 6 #ifndef MA_BIBLIO #define MA_BIBLIO /* À partir d'ici on trouve les déclarations des structures et prototypes. */ ... #endif
Oui, c'est bien ce que je fais (j'ai vu ce schéma dans d'autres fichiers). Voici la structure de toolkit.h:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 #ifndef H_TOOLKIT #define H_TOOLKIT #include <stdlib.h> #include <stdio.h> #include <string.h> #include <assert.h> [...] /* common output funcs */ void line (void) ; void write (char * str) ; void end_test () ; [...] #endif
Mais c'est pas là mon problème: voir ci-dessous.

Citation:

Envoyé par gerald3d

Comme nous n'avons pas les messages d'erreur que tu obtiens nous sommes obligés de supposer.

Excusez-moi, j'ai été trop implicite. Voici:
Code:

1 2 3 4 5 6 7 gcc -Wall -o "Text" "Text.c" (in directory: /home/spir/prog/C) Compilation failed. /tmp/ccKIinM3.o: In function `test_creation': Text.c:(.text+0x9fb): undefined reference to `line' Text.c:(.text+0xa00): undefined reference to `end_test' [... et bis repetita plusieurs fois ...]
Visiblement à l'édition de liens, il ne trouve pas certaines fonctions (des utilitaires: line, end_test, ...). Dans le fichier que je compile là, il y a bien "#include "toolkit.h" (avant l'usage desdites fonctions). Les fonctions en question sont déclarées dans toolkit.h --comme montré ci-dessus-- et définies dans toolkit.c (qui lui-même inclut maintenant toolkit.h et compile sans problème).

Denis

11/04/2012, 21h18
gerald3d

hum...

Pourrait-on aussi voir toolkit.c?

Citation:
Envoyé par denispir
Code:

1 2 3 4 5 6 7 gcc -Wall -o "Text" "Text.c" (in directory: /home/spir/prog/C) Compilation failed. /tmp/ccKIinM3.o: In function `test_creation': Text.c:(.text+0x9fb): undefined reference to `line' Text.c:(.text+0xa00): undefined reference to `end_test' [... et bis repetita plusieurs fois ...]
Visiblement à l'édition de liens, il ne trouve pas certaines fonctions (des utilitaires: line, end_test, ...). Dans le fichier que je compile là, il y a bien "#include "toolkit.h" (avant l'usage desdites fonctions). Les fonctions en question sont déclarées dans toolkit.h --comme montré ci-dessus-- et définies dans toolkit.c (qui lui-même inclut maintenant toolkit.h et compile sans problème).

Denis
Salut,

tu essayes de créer un exécutable, et celui doit savoir où trouver les fonctions déclarées dans ton .h. Il faut donc lui dire de linker Test.c et toolkit.c pour créer ton exécutable :
Code:

1 2 gcc -o Test -Wall Test.c toolkit.c
Pour faire plus "propre", tu pourrais faire un makefile et de la compilation séparée :
Code:

1 2 3 4 gcc -c -Wall Test.c gcc -c -Wall toolkit.c gcc -o Test Test.o toolkit.o

Citation:

Envoyé par gerald3d

hum...

Pourrait-on aussi voir toolkit.c?

Voilà. J'ai viré des trucs exportés dans d'autres modules (comme des conversions int/uint -> string) depuis le début de mon problème d'include. J'ai aussi viré un certain nombre de défs de constantes et types (comme "typedef enum {false, true} bool;") qui généraient des erreurs depuis que toolkiit.c inclue toolkit.h . Mais ledit problème persiste sans changement.

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
 
/* basic toolkit
*/
 
// === code ===================================================================
 
#include "toolkit.h"
#include <stdarg.h>
 
/* types for count/size & position/index
   Nat is unsigned to allow for negative index à la Python,
   and for tricks such as 'not-found' = -1
*/
typedef unsigned int Uint ;
typedef int Nat ;
 
/* common output funcs
*/
void line (void) {
   putchar (EOL) ;
}
void write (char * str) {
   printf ("%s", str) ;
}
void end_test () {
   puts ("=================================================================") ;
   line() ;
}
 
/* string funcs
   * format: sprintf returning a new string
     see also:
      int asprintf  (char **strp, const char *fmt, ...) ;
      int vasprintf (char **strp, const char *fmt, va_list ap) ;
*/
char * format (char * form, ...) {
   va_list args ; va_start (args, form) ;
   char *s, *s0 ;
   Uint weight ;
 
   // Determine weight (count of bytes) in output (NUL excluded):
   s0 = malloc (1 * sizeof(char)) ;
   assert (s0 != NULL) ;
   weight = vsnprintf (s0, 1, form, args) ;
   printf ("weight:%i\n", weight) ;
   assert (weight > 0) ;
   weight ++ ;                                  // for NUL terminator
   free (s0) ; s0 = NULL ;
 
   // Write into new string of that weight:
   s = malloc (weight * sizeof(char)) ;
   assert (s != NULL) ;
   weight = vsprintf (s, form, args) ;
//~    printf ("weight:%i\n", weight) ;
 
   va_end (args) ;
   return s ;
}
 
/* debug tool func
*/
int stop (void) { exit (EXIT_SUCCESS) ;}
 
 
 
// === test ===================================================================
void test () {
   char * s = format ("int:%05i float:%+9.3f string:'%9s'",
      123, 1.23, "123") ;
   puts (s) ;
}
int main (void) {
   test () ;
   return EXIT_SUCCESS ;
}

Denis

12/04/2012, 09h04
Bktero

D'abord les messages du compilateur, c'est plutôt dans Test.c qu'il ne trouve pas les fonctions. Tu as bien inclus ton toolkit.h je suppose ? As-tu compilé en utilisant les commandes de kwariz ?
12/04/2012, 11h10
kwariz

Salut,

je pense que le problème est là : inclure un header (par exemple truc.h) n'indique en rien au compilateur où trouver ce qui manque (ni même qu'il manque quelque chose) :

* si truc.h ne contient que des #define par exemple aucun besoin de source (pas de truc.c)

* truc.h peut inclure des déclarations de fonctions définies ensuite dans machin.c, et d'autres de chouette.c sans qu'aucun truc.c n'existe.

Un #include est équivalent à copier le contenu du fichier à l'endroit où tu écris le #include, les seules facilités sont que si tu ne donnes pas un chemin complet alors le fichier est cherché dans un liste de répertoires connus, il n'y a pas de renumérotation des lignes du fichier original (la ligne 124 affichée dans ton éditeur reste la ligne 124 dans les messages du compilo). C'est de la facorisation brute de code. C'est très différent des import/using que tu trouves dans d'autres langages.
12/04/2012, 12h52
bpy1401
Bonjour à tous

Citation:

inclure un header (par exemple truc.h) n'indique en rien au compilateur où trouver ce qui manque

Un compilateur n'a pas besoin de savoir ou se trouve code, mais uniquement comment on doit l'utiliser. C'est le linker qui doit trouver tous ce qui est utile pour générer l'executable.

Ici tes erreurs sont dues au linker qui ne trouve pas les objets issu de la compilation certaines fonctions dont 'line' ou 'end_test'. Donc ne cherche pas du coté des inclusion de .h , le problème n'est pas la.

Dans toolkit.c, je vois ceci

Citation:

void line (void) ;
void write (char * str) ;
void end_test () ;

Ce n'est pas une définition de fonction, mais juste une déclaration. Donc normal que le linker ne trouve pas ces fonctions.
Code:

1 2 3 void line (void) {} ; void write (char * str) {} ; void end_test () {} ;
devrait déjà être mieux, même si elle ne font rien
12/04/2012, 14h09
Bousk

@bpy
ce que tu as vu comme toolkit.c est le .h
le .c est dans son dernier message
et il s'agit donc très certainement de fichiers qu'il ne compile pas
12/04/2012, 14h26
bpy1401

@bousk

Désolé, je n'ai pas tout compris alors.
Il y a donc du oublier d'inclure toolkit.c dans son projet
15/04/2012, 13h13
denispir

nouvelle discussion sur le même sujet, d'une autre perspective

Bonojur,

J'ouvre une autre discussion sur cette thématique, mais en l'abordant d'un autre angle, plus sytématique et complet:
http://www.developpez.net/forums/d12...on-prog-multi-
modules-bis/#post6620592
Je vais clore ce fil-ci.

Merci à tous,
Denis