2009-05-11 2 views
4

Visual C++을 사용한 대부분의 개발 작업에서 부분 빌드를 사용하고 있습니다. F7을 누르고 변경된 C++ 파일과 종속성 만 다시 작성한 다음 증분 링크를 누릅니다. 테스트에 버전을 전달하기 전에 전체 프로젝트를 수행 할 때주의해야하며 현재 프로젝트에서 약 45 분이 소요됩니다. 나는이 활동을지지하는 많은 게시물과 기사를 보았다. 그러나 궁금하다면 이것이 필요한 이유는 무엇인가? 전달 된 EXE 또는 관련 PDB (테스트에서 사용하는)에 영향을 줍니까? 소프트웨어가 테스트 관점과 다른 기능을합니까?Visual C++의 부분 빌드 대 전체 빌드

릴리스 빌드의 경우 VS2005, 증분 컴파일 및 링크, 프리 컴파일 헤더를 사용합니다.

답변

2

모두가이 사용 패턴을 보지 못했습니까? 이상한 빌드 오류가 발생하고 조사하기 전에 전체 재 구축을 수행하면 문제가 사라집니다.

이 자체만으로는 릴리스 전에 완전히 다시 빌드 할 충분한 이유가있는 것 같습니다.

문제없이 완료된 점진적 빌드를 기꺼이 테스트하든간에 취향에 상관없이 말입니다.

+0

아마 위험도가 높을 지 모르지만 나는 당신에게 동의합니다. 제 경험상 부분적인 재건은 완전히 재구성되어서 치유 된 버그를 가질 수 있습니다. 따라서 테스트를 위해 넘겨주는 것이 타당하지 않습니다. 불쌍해. 일주일에 여러 시간을 절약 할 수있어. –

3

기본 문제는 컴파일이 환경 (명령 줄 플래그, 사용 가능한 라이브러리 및 아마도 일부 블랙 매직)에 따라 다르므로 동일한 조건에서 수행되는 경우 두 번의 컴파일이 동일한 결과를 얻을 수 있다는 것입니다. 테스트 및 배포의 경우 환경이 가능한 한 제어되고 이상한 코드로 인해 이상한 행동을하지 않도록해야합니다. 좋은 예는 시스템 라이브러리를 업데이트 한 다음 파일의 절반을 다시 컴파일하는 경우입니다. 절반은 여전히 ​​이전 코드를 사용하려고 시도하지만 절반은 그렇지 않습니다. 완벽한 세상에서 이것은 즉시 오류를 일으키거나 아무런 문제도 일으키지 않을 것이지만 슬프게도 때로는 그런 일이 일어나지 않을 것입니다. 결과적으로 완전한 재 컴파일을 수행하면 시공 된 빌드 프로세스와 관련된 많은 문제를 피할 수 있습니다.

6

부분 빌드 시스템은 소스 파일의 파일 날짜를 빌드 결과와 대조하여 작동합니다. 예를 들면. 소스 제어에서 이전 파일을 복원하십시오. 이전 파일은 빌드 제품보다 이전에 수정 된 날짜를 가지므로 제품을 다시 빌드 할 수 없습니다. 이러한 오류를 방지하려면 최종 빌드 인 경우 전체 빌드를 수행해야합니다. 개발하는 동안 증분 빌드는 물론 훨씬 더 효율적입니다.

편집 : 물론 전체 재 구축을 수행하면 증분 빌드 시스템의 가능한 버그로부터 보호받을 수 있습니다.

+0

나를 염두에 둔 증분 빌드 시스템의 가능한 버그가 있습니다. 여기 다른 사람들과 마찬가지로, 나는 부분적인 실패가 있었고, 완전한 재건을하고 모든 것은 늠름한 dory이다. 환경의 어떤 것도 변하지 않았습니다. 이것은 다른 것을 변경하지 않고 부분 빌드가 완료된 직후 완전히 다시 빌드됩니다. 나는 계속 이것을 할 것입니다. –

2

나는 확실히 그것을 권하고 싶습니다. 많은 Visual C++ 솔루션에서 종속성 검사기가 변경된 코드에 대한 종속성을 찾지 못하는 경우를 많이 보았습니다. 이 변경이 개체의 크기에 영향을 미치는 헤더 파일에있을 때 매우 이상한 일이 발생할 수 있습니다. 종속성 검사기가 VS 2008에서 더 좋아 졌다고 확신하지만 릴리스 빌드를 위해이를 신뢰하지 않습니다.

1

Visual Studio에는 부분 (증분) 빌드에 몇 가지 문제가 있습니다. (대부분 링크 오류가 발생했습니다.) 때때로 전체 빌드를하는 것이 매우 유용합니다.

  1. 병렬 편집 도구를 사용하여 (가정) 멀티 코어 하드웨어를 활용 : 긴 컴파일 시간의 경우

    는 두 가지 솔루션이 있습니다.
  2. 빌드 머신을 사용하십시오. 제가 가장 많이 사용하는 것은 CruiseControl을 설치 한 별도의 빌드 머신으로 수시로 전체 리빌드를 수행합니다.테스트 팀에, 그리고 결국 고객에게 제공하는 "공식"릴리즈는 항상 개발자 환경이 아니라 빌드 시스템에서 가져옵니다.
2

점진적으로 링크 된 바이너리를 제공하지 않는 가장 큰 이유는 일부 최적화가 비활성화되어 있기 때문입니다. 링커는 함수 사이에 패딩을 남깁니다 (다음 증분 링크에서 쉽게 바꿀 수 있도록). 이것은 바이너리에 약간의 부 풀림을 추가합니다. 메모리 액세스 패턴을 변경하고 여분의 페이징 및/또는 캐시 누락을 유발할 수있는 여분의 점프도있을 수 있습니다. 이전 버전의 함수는 호출되지 않아도 실행 파일에 계속 남아있을 수 있습니다. 또한 바이너리 팽창과 느린 성능으로 이어집니다. 또한 증분 링크를 사용하여 링크 타임 코드 생성을 사용할 수 없으므로 더 많은 최적화 작업을 놓치게됩니다.

테스터에게 디버그 빌드를 제공하는 경우 큰 문제는 아닙니다. 그러나 릴리스 후보는 릴리스 모드에서 처음부터 빌드해야합니다. 환경을 제어하는 ​​전용 빌드 머신이 바람직합니다.