2009-12-08 9 views
93

나는 많은 (반복적 인) 경고를 생성하는 log4cxx, boost 등의 라이브러리를 사용하는 프로젝트를 가지고있다. 라이브러리 포함 (예 : #include < some-header.h >)에서 경고를 표시하지 않거나 특정 경로를 포함 할 수 있습니까? 나는 관련 정보가 모호해지지 않고 프로젝트 코드에서 -Wall 및/또는 -Wextra를 평소처럼 사용하고 싶습니다. 현재 grep을 사용하여 출력하고 있지만 더 나은 것을 원합니다.라이브러리 헤더에서 GCC 경고를 억제하는 방법은 무엇입니까?

답변

95

-I 대신 -isystem을 사용하여 라이브러리 헤더를 포함 할 수 있습니다. 이렇게하면 "시스템 헤더"가되며 GCC는 경고를 보냅니다.

+9

Xcode에서이 작업을 수행하려는 경우 대상 빌드 설정의 "사용자 정의 컴파일러 플래그"에서 "기타 C++ 플래그"로 시스템 경로를 지정하십시오. –

+2

잠재적 인 단점 중 하나는 일부 플랫폼에서 g ++가'extern "C"'에 시스템 헤더를 자동으로 래핑하여'-isystem' 경로에 C++ 헤더를'#include '할 경우 C 링키지에 대한 이상한 오류가 발생한다는 것입니다. –

+0

+1 성가신 부스트 경고와 관련된 문제를 해결하는 데 도움이되었습니다. http://stackoverflow.com/questions/35704753/warnings-from-boost – mrgloom

4

precompiled headers을 사용해보세요. 경고는 사라지지 않지만 최소한 편집본에는 나타나지 않습니다.

+1

이것은 실제로 좋은 생각 일 수 있습니다. 제 3 자 포함은 매일 바뀌지 않습니다. – AdSR

+0

정확히. Linux에서 많이 사용하지는 않았지만 Visual Studio에서 잘 작동합니다. –

8

#pragma은 컴파일러에 대한 지침입니다. 당신은 #include 전에 무언가를 설정할 수 있고 후에 비활성화 할 수 있습니다.

command line에서도 할 수 있습니다.

또 다른 GCC 페이지는 disabling warnings입니다.

나는 소스 코드 내에서 # 프라그의의를 사용하여, 다음이 경고를 비활성화하는 이유 (댓글 등) 소리 이유를 제공하는 옵션에 갈 것입니다. 이것은 헤더 파일에 대한 추론을 의미합니다.

GCC가 경고 유형 인 classifying에 접근합니다. 경고로 간주하거나 무시할 수 있습니다. 이전에 링크 된 기사는 사용할 수없는 경고를 표시합니다.

참고 : attributes을 사용하여 특정 경고가 표시되지 않도록 소스 코드를 완화 할 수도 있습니다. 그러나 이것은 GCC와 매우 밀접하게 연결됩니다.

참고 2 : GCC는 microsoft 컴파일러에서 사용되는 pop/push interface도 사용합니다. Microsoft는이 인터페이스를 통해 경고를 비활성화합니다. 나는 이것이 가능할 지 모르겠으므로 너는 이것을 더 깊이 조사 할 것을 제안한다.

+0

pragma를 고려했지만 헤더를 포함하기 전에 경고를 표시하지 않으면 #include 뒤에 * 이전 상태로 다시 설정하는 방법은 무엇입니까? 프로젝트 코드에 대한 모든 경고를보고 싶지만 (이미 몇 번 도와 줬음) 명령 행에서 제어 할 수 있습니다. – AdSR

+0

추가 정보. –

-6

이러한 경고의 이유가 있어야합니다. 이러한 오류는 라이브러리를 사용하는 코드의 오류 또는 라이브러리 코드 자체의 오류로 인해 발생합니다. 첫 번째 경우에는 코드를 수정하십시오. 두 번째 경우에는 라이브러리 사용을 중지하거나 FOSS 코드 인 경우이를 수정하십시오.

+0

좋은 조언을 원할 경우 : D하지만 그는 특정 작업을 수행하는 방법을 묻습니다. D –

+3

특히 제 3 자 코드에서 * 특히 * 부스트와 같은 메타 프로그래밍 풍부한 코드에서 일부 경고는 불가능하거나 매우 어렵습니다. – ulidtko

+3

나를 괴롭히는 것이 나쁘다. " 'c'선언은 'this- [Werror = shadow]'*의 멤버를 부스트 헤더 깊숙한 곳에 숨긴다. 물론 문제는 아니지만, 비슷한 문제로 인해 결과물이 쏟아져 나오고 코드 기반에서 실제 그림자가 발견되는 것을 어렵게 만듭니다. – dmckee

23

트릭을 발견했습니다. 라이브러리 포함의 경우, -Idir 대신 -isystem dir을 makefile에 사용하십시오. 그런 다음 GCC는 시스템이 포함 할 때 부스트 등을 처리하고 그로부터의 경고를 무시합니다.

34

pragma를 사용할 수 있습니다. 예를 들어 : CMake를 사용하는 사람들을 위해

// 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

GCC> = 4.6 만 사용 가능 – Caduchon

66

, 당신은 헤더에 대한 경고를 억제 기호 SYSTEM을 포함하도록 include_directories 지시를 수정할 수 있습니다.

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

라이브러리가 CMake의 [include()] (https://cmake.org/cmake/help/latest/command)와 함께 사용되는'$ {LIBFOO_USE_FILE} '변수를 제공하면 어떻게 될까요? /include.html) 명령? – waldyrious

+2

이것은 내 문제에 대한 거의 해결책으로 보인다. 나는) 1) 바이너리 타겟, 2)에 의존하는 헤더 전용 타겟, 3) 외부 라이브러리에 의존한다. 나는 1 & 2에 대해서만 경고를받는 방법을 모른다. 아이디어 있니? – knedlsepp

+0

작동하지 않는 것 같습니다. 나는'easylogging ++'을 사용하는 프로젝트에서이 파일을 시험해 보았고,'easylogging ++. h '파일에서'SYSTEM' 옵션에 포함되어있는 폴더와 같은 크기의 경고 파일을 얻었습니다. – rbaleksandar

0

시스템 헤더를 명시 적으로 무시해야하는 경우 pragma로 제한됩니다. make depend 출력을 통해 어떤 것이 포함되어 있는지 확인할 수 있습니다.

도 참조하십시오. diagnostic push-pop for gcc >= 4.6

관련 문제