IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

 C Discussion :

compilation de programme multi-modules


Sujet :

C

  1. #1
    Membre habitué
    Profil pro
    amateur
    Inscrit en
    Avril 2012
    Messages
    145
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : amateur
    Secteur : Arts - Culture

    Informations forums :
    Inscription : Avril 2012
    Messages : 145
    Points : 144
    Points
    144
    Par défaut 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

  2. #2
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 131
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 131
    Points : 33 072
    Points
    33 072
    Billets dans le blog
    4
    Par défaut
    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.

    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")

    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.

    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.

  3. #3
    Membre éprouvé
    Avatar de bpy1401
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2003
    Messages
    510
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : France, Eure (Haute Normandie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : Mars 2003
    Messages : 510
    Points : 1 007
    Points
    1 007
    Par défaut
    Bonjour à tous

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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+

  4. #4
    Membre habitué
    Profil pro
    amateur
    Inscrit en
    Avril 2012
    Messages
    145
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : amateur
    Secteur : Arts - Culture

    Informations forums :
    Inscription : Avril 2012
    Messages : 145
    Points : 144
    Points
    144
    Par défaut
    Citation Envoyé par bpy1401 Voir le message
    Bonjour à tous

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 ;-)

    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

  5. #5
    Expert confirmé
    Avatar de gerald3d
    Homme Profil pro
    Conducteur de train
    Inscrit en
    Février 2008
    Messages
    2 303
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Conducteur de train
    Secteur : Transports

    Informations forums :
    Inscription : Février 2008
    Messages : 2 303
    Points : 4 967
    Points
    4 967
    Billets dans le blog
    5
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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

  6. #6
    Membre habitué
    Profil pro
    amateur
    Inscrit en
    Avril 2012
    Messages
    145
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : amateur
    Secteur : Arts - Culture

    Informations forums :
    Inscription : Avril 2012
    Messages : 145
    Points : 144
    Points
    144
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : 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
     
    #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 Voir le message
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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

  7. #7
    Expert confirmé
    Avatar de gerald3d
    Homme Profil pro
    Conducteur de train
    Inscrit en
    Février 2008
    Messages
    2 303
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Conducteur de train
    Secteur : Transports

    Informations forums :
    Inscription : Février 2008
    Messages : 2 303
    Points : 4 967
    Points
    4 967
    Billets dans le blog
    5
    Par défaut
    hum...

    Pourrait-on aussi voir toolkit.c?

  8. #8
    Membre expert
    Avatar de kwariz
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    Octobre 2011
    Messages
    898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Chef de projet en SSII
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2011
    Messages : 898
    Points : 3 352
    Points
    3 352
    Par défaut
    Citation Envoyé par denispir Voir le message
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    gcc -c -Wall Test.c
    gcc -c -Wall toolkit.c
    gcc -o Test Test.o toolkit.o

  9. #9
    Membre habitué
    Profil pro
    amateur
    Inscrit en
    Avril 2012
    Messages
    145
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : amateur
    Secteur : Arts - Culture

    Informations forums :
    Inscription : Avril 2012
    Messages : 145
    Points : 144
    Points
    144
    Par défaut
    Citation Envoyé par gerald3d Voir le message
    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 : 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
    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

  10. #10
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 484
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 484
    Points : 13 691
    Points
    13 691
    Billets dans le blog
    1
    Par défaut
    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 ?

  11. #11
    Membre expert
    Avatar de kwariz
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    Octobre 2011
    Messages
    898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Chef de projet en SSII
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2011
    Messages : 898
    Points : 3 352
    Points
    3 352
    Par défaut
    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. #12
    Membre éprouvé
    Avatar de bpy1401
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2003
    Messages
    510
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : France, Eure (Haute Normandie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : Mars 2003
    Messages : 510
    Points : 1 007
    Points
    1 007
    Par défaut
    Bonjour à tous

    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
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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

  13. #13
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 131
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 131
    Points : 33 072
    Points
    33 072
    Billets dans le blog
    4
    Par défaut
    @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

  14. #14
    Membre éprouvé
    Avatar de bpy1401
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2003
    Messages
    510
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : France, Eure (Haute Normandie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : Mars 2003
    Messages : 510
    Points : 1 007
    Points
    1 007
    Par défaut
    @bousk

    Désolé, je n'ai pas tout compris alors.
    Il y a donc du oublier d'inclure toolkit.c dans son projet

  15. #15
    Membre habitué
    Profil pro
    amateur
    Inscrit en
    Avril 2012
    Messages
    145
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : amateur
    Secteur : Arts - Culture

    Informations forums :
    Inscription : Avril 2012
    Messages : 145
    Points : 144
    Points
    144
    Par défaut 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

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. compilation de prog multi-modules (bis)
    Par denispir dans le forum Débuter
    Réponses: 18
    Dernier message: 19/04/2012, 16h40
  2. Réponses: 2
    Dernier message: 25/04/2007, 18h44
  3. [Compilation] Dev ne peut pas compiler mon programme
    Par Rémaill dans le forum Dev-C++
    Réponses: 9
    Dernier message: 01/11/2005, 01h41
  4. Delphi 2005 : Erreur de compilation du programme
    Par bigbestboy dans le forum Langage
    Réponses: 6
    Dernier message: 03/08/2005, 19h14
  5. Programmation par module : applications multilingues
    Par argoet dans le forum Langages de programmation
    Réponses: 13
    Dernier message: 03/02/2004, 12h28

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo