유니티 빌드

1 개요[ | ]

unity build, unified build, jumbo build
유니티 빌드, 통합 빌드, 점보 빌드
  • C와 C++ 개발에서 프로젝트 컴파일 속도를 높이기 위해 include 지시문을 사용하여 여러 번역 단위를 단일 단위로(여러 소스 파일을 하나의 더 큰 파일로) 결합하는 것
  • Visual Studio[1], Meson[2], CMake[3] 등의 빌드 시스템은 자동화 유니티 빌드 기능을 지원한다.

2 구현[ | ]

2개의 번역 단위 file_a.ccfile_b.cc가 있을 때,

file_a.cc
#include "header.h"

// 소스코드 파일 A 내용 ...
file_b.cc
#include "header.h"

// 소스코드 파일 B 내용 ...

동일 프로젝트 내에서 둘 다 header.h 헤더를 포함하는데, 각 헤더는 각 빌드 작업에서 한 번씩 처리되어 컴파일러 체인에서 총 두 번 처리된다. 두 번역 단위를 단일 소스파일 jumbo_file.cc로 병합하면,

jumbo_file.cc
#include "file_a.cc"
#include "file_b.cc"

jumbo_file.cc를 컴파일할 때 header.h가 한 번만 처리된다(include 가드 덕분에).

3 효과[ | ]

  • 유니티 빌드의 주요 이점은 둘 이상의 소스파일에 포함된 헤더 내용을 구문 분석하고 컴파일하는 데 필요한 중복 작업을 줄일 수 있다는 것이다.
    • 헤더의 내용은 일반적으로 전처리 후 소스파일 대부분의 코드를 차지한다.
    • 또한 유니티 빌드는 컴파일 체인에서 생성·처리되는 개체 파일의 수를 줄여 많은 수의 작은 소스파일로 인한 오버헤드를 완화하고, 유니티 빌드 작업을 형성하는 파일 전반에 걸쳐 절차 간 분석 및 최적화를 가능하게 한다(예: 링크 시간 최적화의 효과).
    • 동일한 유니티 빌드의 다른 소스 파일에서 기호(symbol)가 2번 정의되면 컴파일러가 재정의를 식별하고 경고 또는 오류를 생성할 수 있기 때문에 단일 정의 규칙 위반을 더 쉽게 감지할 수 있다.
  • 유니티 빌드의 단점 중 하나는 더 큰 번역 단위로 인해 더 큰 메모리 공간을 차지한다는 것이다.
    • 적은 수의 대규모 컴파일 작업은 일반적으로 사용 가능한 모든 병렬 컴퓨팅 리소스를 효과적으로 포화시키기 위해 일정을 잡기가 어렵거나 불가능하기 때문에 더 큰 번역 단위는 병렬 빌드에 부정적인 영향을 미칠 수도 있다.
    • 유니티 빌드는 가능한 한 적은 코드, 즉 마지막 빌드 이후 변경 사항의 영향을 받는 번역 단위만 다시 빌드하는 데 의존하는 증분 빌드의 이점 중 일부를 거부할 수도 있다.
  • 유니티 빌드는 프로그램의 의미 체계에 잠재적으로 위험한 영향을 미칠 수 있다.
    • 내부 연결에 의존하는 일부 유효한 C++ 구조는 유니티 빌드에서 실패할 수 있다.
    • 예를 들어 정적 기호와 다른 파일의 동일한 식별자를 사용하여 익명 네임스페이스에 정의된 기호의 충돌이 있다.
    • 다른 C++ 파일이 같은 이름으로 다른 함수를 정의하는 경우 컴파일러는, 다른 번역 단위로 파일을 사용하여 소프트웨어를 설계할 때는 불가능했던 방식으로, 예기치 않게 잘못된 함수를 선택하여 오버로드를 적용(resolve)할 수 있다.
    • 또 다른 역효과는 다른 소스 파일에서 매크로 정의가 누출될 수 있다는 것이다.

4 같이 보기[ | ]

5 참고[ | ]

문서 댓글 ({{ doc_comments.length }})
{{ comment.name }} {{ comment.created | snstime }}