2009-12-08 6 views
93

J'ai un projet qui utilise des bibliothèques log4cxx, boost, etc. dont les en-têtes génèrent beaucoup d'avertissements (répétitifs). Existe-t-il un moyen de supprimer les avertissements de la bibliothèque (c'est-à-dire #include < some-header.h >) ou inclut certains chemins? Je voudrais utiliser -Wall et/ou -Wextra comme d'habitude sur le code du projet sans que les informations pertinentes soient obscurcies. J'utilise actuellement grep sur make sortie mais j'aimerais mieux.Comment supprimer les avertissements GCC des en-têtes de bibliothèque?

Répondre

95

Vous pouvez essayer d'inclure des en-têtes de bibliothèque à l'aide de -isystem au lieu de -I. Cela en fera des "en-têtes de système" et GCC ne rapportera pas les avertissements pour eux.

+9

Si vous essayez de le faire dans XCode, insérez le chemin -isystem dans vos "autres drapeaux C++" dans les "drapeaux du compilateur personnalisé" dans vos paramètres de construction cible. –

+2

Un inconvénient potentiel est que sur certaines plates-formes, g ++ encapsulera automatiquement tout en-tête système dans 'extern 'C" ', conduisant à des erreurs étranges sur la liaison C si vous # incluez un en-tête C++ dans un chemin' -isystem'. –

+0

+1 m'a aidé à résoudre des problèmes avec des avertissements de boost ennuyeux http://stackoverflow.com/questions/35704753/warnings-from-boost – mrgloom

4

Vous pouvez essayer d'utiliser precompiled headers. Les avertissements ne disparaîtront pas mais au moins ils n'apparaîtront pas dans votre compilation principale.

+1

Cela pourrait être une bonne idée. Les inclusions tierces ne changent pas tous les jours. – AdSR

+0

Exactement. Bien que je ne les utilise pas beaucoup sous Linux, ils fonctionnent plutôt bien sur Visual Studio. –

8

#pragma sont des instructions au compilateur. vous pouvez définir quelque chose avant le #include et le désactiver après. Vous pouvez également le faire à l'adresse command line.

Une autre page de GCC spécifiquement sur disabling warnings.

Je pencherais pour la possibilité d'utiliser #pragma est dans le code source, puis fournir une son raison (comme commentaire) pourquoi vous désactivez les avertissements. Cela signifierait raisonner sur les fichiers d'en-têtes.

GCC approche cela par classifying les types d'avertissement. Vous pouvez les classer pour être des avertissements ou pour être ignorés. Les articles précédemment liés vous montreront quels avertissements peuvent être désactivés.

Remarque: vous pouvez également masquer le code source pour empêcher certains avertissements en utilisant attributes; Cependant, cela vous lie assez étroitement à GCC.

Remarque2: GCC utilise également le pop/push interface tel qu'il est utilisé dans le compilateur de Microsoft - Microsoft désactive les avertissements via cette interface. Je suggère que vous étudiez ceci plus loin, car je ne sais pas si c'est même possible.

+0

J'ai considéré les pragmas mais si je supprime un avertissement avant d'inclure un en-tête, comment puis-je le remettre à l'état * précédent après #include? Je veux voir tous les avertissements pour le code du projet (m'a aidé déjà plusieurs fois) mais avoir le contrôle depuis la ligne de commande. – AdSR

+0

ajouté plus d'informations. –

-6

Il doit y avoir des raisons pour ces avertissements. Ceux-ci seront soit causés par des erreurs dans votre code qui utilise la bibliothèque, soit par des erreurs dans le code de la bibliothèque lui-même. Dans le premier cas, corrigez votre code. Dans le second cas, arrêtez d'utiliser la bibliothèque ou s'il s'agit d'un code FOSS, corrigez-le.

+0

+1 pour un bon conseil: D mais il demande comment faire quelque chose de spécifique: D –

+3

Certains avertissements sont impossibles ou très difficiles à corriger, surtout dans le code tiers, * surtout * dans un code riche en métaprogrammes comme celui de Boost. – ulidtko

+3

Pire, celui qui m'embête est * "déclaration de 'c' ombres un membre de 'this' [-Werror = shadow]" * profond, profond dans un en-tête boost. Ce n'est certainement pas un problème, mais cela et d'autres problèmes similaires provoquent des sorties et rendent difficile la recherche d'instances dans notre base de code. – dmckee

23

J'ai trouvé l'astuce. Pour la bibliothèque inclut, au lieu de -Idir utilisez -isystem dir dans le fichier Make. GCC traite ensuite boost etc. comme système inclut et ignore tous les avertissements de leur part.

34

Vous pouvez utiliser des pragmas. Par exemple:

// save diagnostic state 
#pragma GCC diagnostic push 

// turn off the specific warning. Can also use "-Wall" 
#pragma GCC diagnostic ignored "-Wunused-but-set-variable" 

#include <boost/uuid/uuid.hpp> 
#include <boost/uuid/uuid_generators.hpp> 
#include <boost/uuid/uuid_io.hpp> 
#include <boost/lexical_cast.hpp> 

// turn the warnings back on 
#pragma GCC diagnostic pop 
+1

Disponible uniquement avec GCC> = 4.6 – Caduchon

66

Pour ceux qui utilisent CMake, vous pouvez modifier vos include_directories directives pour inclure le symbole SYSTEM qui supprime les avertissements contre ces en-têtes.

include_directories(SYSTEM "${LIB_DIR}/Include") 
        ^^^^^^ 
+0

Que faire si la bibliothèque fournit une variable '$ {LIBFOO_USE_FILE}' à utiliser avec [include()] de CMake (https://cmake.org/cmake/help/latest/command /include.html) commande? – waldyrious

+2

Cela semble être presque la solution à mon problème. J'ai 1.) une cible binaire, qui dépend de 2.) un seul en-tête cible écrite par moi-même, qui dépend de 3.) certaines bibliothèques externes. Je n'ai aucune idée de comment obtenir seulement des avertissements pour 1 et 2. Vous avez des idées? – knedlsepp

+0

Ne semble pas fonctionner. J'ai essayé ceci avec un projet qui emploie 'easylogging ++' et j'obtiens la même quantité énorme d'avertissements du 'easylogging ++. H' quoique le dossier où il réside ait été inclus avec l'option' SYSTEM'. – rbaleksandar

0

Si vous devez remplacer explicitement un en-tête système, vous êtes limité aux pragmas. Vous pouvez vérifier ce que vous utilisez via la sortie make depend.

Voir aussi diagnostic push-pop for gcc >= 4.6

Questions connexes