A voir également:
- Makefile + compilation sans linkage (gcc -c) : petite question.
- Breach compilation c'est quoi - Guide
- Erreur de compilation dans le module caché excel - Forum Logiciels
- Comment faire une compilation de musique - Forum Audio
- Compilation error: expected unqualified-id before '{' token ✓ - Forum C++
- Compilation gcc avec fonctions pow et sqrt ✓ - Forum Programmation
2 réponses
Salut orinym,
Tant que tu es en développement, tu peux utiliser l'option "T" de ar (voir
Une fois ton développement finalisé, tu les copies vraiment dans ta bibliothèque statique.
Dal
Tant que tu es en développement, tu peux utiliser l'option "T" de ar (voir
man ar) pour créer un "thin archive" contenant juste un index des fichiers contenus et les références vers ces fichiers, au lieu de les intégrer réellement à l'archive.
Une fois ton développement finalisé, tu les copies vraiment dans ta bibliothèque statique.
Dal
Tout d'abord merci pour ta réponse.:)
Je ne suis pas sûr de comprendre, tu me conseilles de ne pas ajouter toutes les références, mais d'attendre la fin de mon développement pour faire une archive finie à partir de ce "thin archive"?
J'ai un peu de mal à comprendre en fait, pourquoi attendre la fin? Il risquerait d'y avoir des erreurs dans ma librairie? Il me suffirait juste de la reconstruire dans ce cas non? :/
C'est une librairie que je vais devoir rendre, mais sous forme de sources en C avec un Makefile.
Ma question portait surtout sur les dépendances des différents *.o. dans mon Makefile.
Dois-je considérer file1.c comme une dépendance de file2.c?
Il me semble que non vu que les *.o n'ont pas été linkés, mais je voulais m'en assurer.
à la limite juste le header contenant le prototype mais c'est tout, c'est bien ça?
Le problème, c'est que, comme le dit fiddy :
En revanche, la bibliothèque est dépendante de file1.o et file2.o
Cela signifie donc qu'à chaque changement d'un .o, pour tester ta bibliothèque tu vas devoir mettre à jour l'archive de la bibliothèque pour obtenir un fichier .a mis à jour.
C'est la raison pour laquelle tant qu'on est en développement et que l'on teste la bibliothèque, il est utile d'utiliser l'option "T" (thin archive) qui simule la création de la bibliothèque en utilisant en fait un index et des références vers les .o générés sans les copier dans la bibliothèque, ce qui évite la mise à jour de la bibliothèque à chaque changement de l'un des .o qu'elle contient (sous réserve que tu ne crées pas de nouveaux .o, auquel cas, il faudra de toutes façons les ajouter).
Si ton projet contient des centaines de fichiers .o, cela peut réduire sensiblement le temps de ton cycle de développement et de test.
Une fois ta bibliothèque prête, tu la recrées normalement, sans l'option "T".
Si ton projet ne contient qu'un petit nombre de .o à intégrer à ta bibliothèque, si tu as une machine ultra-rapide ou que tu as du temps, tu peux t'en passer :-)
Dal