문제

나는 모두 PCH를 사용하는 많은 Visual C++ 프로젝트에 대한 솔루션을 가지고 있지만 일부는 프로젝트별 요구 사항에 맞게 특정 컴파일러 스위치가 켜져 있습니다.

이러한 프로젝트의 대부분은 해당 stdafx.h(STL, 부스트 등)에서 동일한 헤더 세트를 공유합니다.프로젝트 간에 PCH를 공유하여 프로젝트별로 모든 PCH를 컴파일하는 대신 솔루션의 대부분의 프로젝트에서 사용할 수 있는 하나의 공통 PCH를 가질 수 있는지 궁금합니다.

프로젝트 설정에서 PCH의 위치를 ​​공유 위치로 지정하는 것이 가능할 것 같아서 이것이 효과가 있을 것 같습니다.또한 공유 PCH를 사용하는 모든 프로젝트의 모든 소스 파일은 동일한 컴파일러 설정을 가져야 한다고 가정합니다. 그렇지 않으면 컴파일러가 PCH와 컴파일 중인 소스 파일 간의 불일치에 대해 불평할 것입니다.

누구든지 이것을 시도한 적이 있습니까?작동합니까?

관련 질문:이러한 샤드 PCH가 지나치게 포괄적이어야 할까요, 아니면 전체 빌드 시간이 저하될까요?예를 들어, 공유 PCH에는 널리 사용되는 많은 STL 헤더가 포함될 수 있지만 일부 프로젝트에서는 STL 헤더만 필요할 수도 있습니다. <string> 그리고 <vector>.공유 PCH를 사용하여 절약한 시간은 최적화 프로그램이 PCH에 의해 프로젝트로 끌어온 사용되지 않은 모든 항목을 삭제해야 하는 빌드 프로세스의 후반 시점에 상환되어야 합니까?

도움이 되었습니까?

해결책

예, 가능하며 시간이 상당히 절약된다는 점을 확신할 수 있습니다.PCH를 컴파일할 때 다음을 복사해야 합니다. .pdb 그리고 .idb PCH 파일을 생성하는 프로젝트의 파일.제 경우에는 PCH 파일을 생성하는 간단한 두 개의 파일 프로젝트가 있습니다.헤더는 PCH 헤더가 되며 소스에는 프로젝트 설정에서 PCH를 생성하라는 메시지가 표시됩니다. 이는 모든 프로젝트에서 일반적으로 수행하는 작업과 유사합니다.언급한 대로 각 구성에 대해 동일한 컴파일 설정을 가져야 합니다. 그렇지 않으면 불일치가 발생하고 컴파일러에서 불만이 발생할 것입니다.

위에서 언급한 파일을 다시 빌드할 때마다 또는 PCH를 다시 ​​컴파일할 때마다 복사하는 것은 번거로운 작업이므로 자동화하겠습니다.복사를 자동화하려면 위에서 언급한 파일이 적절한 디렉터리에 복사되는 빌드 전 이벤트를 수행합니다.예를 들어 컴파일을 한다면 Debug 그리고 Release PCH 빌드, 다음에서 파일을 복사하세요. Debug PCH 프로젝트를 종속 프로젝트로 Debug.복사 명령은 다음과 같습니다.

PchPath\Debug*.pdb 디버그\ /-Y 복사

참고하세요 /-Y 마지막에.첫 번째 빌드 후 각 후속 빌드는 증분적으로 컴파일되므로 파일을 다시 바꾸면 Visual Studio에서 손상된 기호에 대해 불평합니다.파일이 손상된 경우 언제든지 재구축을 수행하여 파일을 다시 복사할 수 있습니다(이번에는 파일이 더 이상 존재하지 않으므로 건너뛰지 않고 정리하면 파일이 삭제됩니다).

이게 도움이 되길 바란다.이 작업을 수행하는 데 꽤 시간이 걸렸지만 그만한 가치가 있었습니다.하나의 큰 프레임워크에 의존하는 여러 프로젝트가 있는데 PCH는 한 번만 컴파일하면 됩니다.이제 모든 종속 프로젝트가 매우 빠르게 컴파일됩니다.

편집하다:다른 여러 사람들과 함께 VS2010과 VS2012에 따라 이것을 테스트했으며 제대로 작동하는 것으로 보입니다.

다른 팁

이것은 오래된 질문이지만 Visual Studio 2017에서 작동하고 복사가 필요하지 않은 새로운 답변을 제공하고 싶습니다.유일한 단점:편집 및 계속이 더 이상 작동하지 않습니다.

기본적으로 미리 컴파일된 헤더에 대한 새 프로젝트를 생성하고 다른 모든 프로젝트가 이에 종속되도록 해야 합니다.내가 한 일은 다음과 같습니다.

단계별:

  1. 헤더(여기서는 pch.h라고 함)와 pch.h를 포함하는 한 줄 cpp 파일을 포함하는 솔루션 내에서 새 프로젝트를 만듭니다.프로젝트는 정적 lib를 생성해야 합니다.미리 컴파일된 헤더를 생성하려면 새 프로젝트를 설정하세요.출력 파일은 모든 프로젝트에서 액세스할 수 있어야 합니다.나에게는 이것이 IntDir에 상대적이지만 기본 설정의 경우 $(SolutionDir)에 상대적일 수 있습니다.pch 프로젝트에는 다른 모든 프로젝트에도 정의된 정의만 있어야 합니다.

    pch project settings

  2. 다른 모든 프로젝트가 이 새 프로젝트에 종속되게 하세요.그렇지 않으면 빌드 순서가 잘못될 수 있습니다.

    project references

  3. pch.h를 사용하도록 다른 모든 프로젝트를 설정합니다.출력 파일 매개변수가 pch 프로젝트와 어떻게 동일한지 확인하세요.추가 포함 디렉터리도 pch.h 디렉터리를 가리켜야 합니다.선택적으로 모든 cpp에 pch 파일을 강제로 포함할 수 있습니다(또는 모든 cpp 파일의 첫 번째 줄에 수동으로 포함할 수 있습니다).

    pch include include

    1. 동일한 컴파일러 기호 파일을 사용하도록 모든 프로젝트(pch 프로젝트 포함)를 설정합니다(링커 기호 파일은 영향을 받지 않음).다시 말하지만, 제 예에서는 OutDir이지만 솔루션에서는 다를 수 있습니다.디스크에 있는 동일한 파일을 가리켜야 합니다.디버그 정보 형식은 C7로 설정해야 합니다(위 스크린샷 참조). 그렇지 않으면 Visual Studio가 프로젝트를 병렬로 컴파일할 수 없습니다.pdb

내가 아무것도 잊지 않았기를 바랍니다.내 솔루션(130k loc, 160개 프로젝트)의 경우 이로 인해 ~3:30분이 아닌 ~2:30분의 컴파일 시간이 발생합니다.

각 소스 파일은 PCH가 컴파일된 동일한 PDB에 대해 컴파일되어야 하기 때문에 불가능한 것 같습니다.젠장.

Samaursa의 답변이 저에게 효과적이었습니다.

나도 이거 봤어 링크 작동합니다 (하단 근처에서 Reginald의 답변을 찾으십시오).

이것은 사용합니다 copy Reginald가 사용하는 동안 xcopy (나는 선호한다 xcopy).어느 쪽이든 감사합니다. 덕분에 빌드 속도가 상당히 빨라졌습니다.

이것은 나에게 "수익률 감소" 사례처럼 들립니다.공통 헤더를 직접 포함하면 .cpp 파일당 1초가 낭비되고 각 대상(DLL/EXE)에 10개의 .cpp 파일이 있다고 가정해 보겠습니다.대상당 .pch를 사용하면 대상당 10초를 절약할 수 있습니다.전체 프로젝트에 10개의 대상이 있는 경우 전체 빌드에서 1.5분을 절약할 수 있습니다. 이는 좋은 일입니다.

그러나 전체 프로젝트에 대해 이를 하나의 .pch로 줄이면 9초만 추가로 절약할 수 있습니다.그만한 가치가 있나요?추가 노력(VS 마법사에서 지원하지 않는 비표준 구성이므로 설정하기가 훨씬 까다로울 수 있음)으로 인한 비용 절감 효과는 10분의 1에 불과합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top