2010-10-15 18 views
7

J'ai déjà eu des problèmes lorsque j'ai essayé de transférer du code C++ écrit sur Mac OS X vers un système Linux, ou d'essayer de compiler du code écrit sur une ancienne version de gcc/g ++ avec un code plus récent:Comment puis-je contrôler la manière dont gcc/g ++ inclut automatiquement les en-têtes?

Il semble que certaines versions (plus anciennes?) De gcc/g ++ incluraient automatiquement des fichiers d'en-tête pour vous. Par exemple, le code qui utilise printf doit exiger #include <stdio.h>. Et le code qui utilise memcpy devrait exiger #include <string.h>. Mais en fonction de la version de gcc que j'utilise, il sera parfois inclus pour moi.

Il fait des ravages lorsque j'oublie d'inclure quelque chose et puis jamais obtenir des erreurs jusqu'à ce que je vais compiler le code sur un autre système. À ce stade, il s'agit d'un jeu de courir partout dans le projet et de fixer les inclus.

Est-ce que quelqu'un d'autre a rencontré cela? Existe-t-il un moyen de forcer gcc à s'auto-exclure ou à ne pas s'auto-exclure? Ou, est-il un moyen de savoir ce c'est autoincluding?

+0

Peut être si gcc-t-il, il serait automatiquement devenu trop subtil pour elle de comprendre les noms des mêmes méthodes dans les différentes bibliothèques. Mais s'il y a une solution automatique, j'aimerais savoir. –

+3

Etes-vous sûr que ce ne sont pas les autres en-têtes qui tirent ceux-là, et sur les autres plates-formes qui ne le font pas? –

+1

gcc n'inclut pas "auto-include" - vous n'obtenez probablement que des inclusions indirectes via des en-têtes explicitement # inclus, comme le suggère Preet ci-dessus. Bottom line: vous devez corriger votre code. –

Répondre

2

Etes-vous sûr que ce ne sont pas les autres en-têtes qui tirent ceux-là, et sur les autres plates-formes qui ne le font pas?

0

Lors de la compilation sur différents systèmes, vous pouvez rencontrer des problèmes différents et pas seulement. Je vous suggère d'investir dans un système de compilation continue qui compilera sur tous les systèmes d'exploitation dont vous avez besoin après chaque mise à jour du code, de sorte que vous êtes rapidement au courant de tout problème de portabilité.

Vous pouvez également placer tous les fichiers d'en-tête système communs dans un fichier d'en-tête spécifique que vous allez écrire et l'inclure systématiquement dans tous vos fichiers.

+0

Ceci est une bonne suggestion , mais dans un cas, il s'agissait d'une bibliothèque tierce (une ancienne version d'OpenSceneGraph) et d'un ancien code qui s'est cassé lors de la mise à niveau vers une version plus récente de gcc. La compilation automatique pour plusieurs OS n'aurait pas aidé ici, et je soupçonne que peut-être le problème était juste que #includes dans le système incluaient des fichiers ont été réorganisés entre les versions de gcc: / – Dave

5

-include file Traite le fichier comme si #include "fichier" apparaissait comme première ligne du fichier source principal. Cependant, le premier répertoire recherché est le répertoire de travail du préprocesseur au lieu du répertoire contenant le fichier source principal. S'il n'est pas trouvé, il est recherché dans le reste de la chaîne de recherche #include "..." comme d'habitude. Si plusieurs options -include sont fournies, les fichiers sont inclus dans l'ordre dans lequel ils apparaissent sur la ligne de commande.

http://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html