날짜 비워 두기: BazelCon 2023이 10월 24~25일에 Google 뮌헨에서 열립니다. 등록이 시작되었습니다. 자세히 알아보기

작업공간, 패키지, 대상

문제 신고 소스 보기

Bazel은 작업공간이라는 디렉터리 트리로 구성된 소스 코드에서 소프트웨어를 빌드합니다. 작업공간의 소스 파일은 패키지의 중첩된 계층 구조로 구성됩니다. 여기서 각 패키지는 일련의 관련 소스 파일 및 하나의 BUILD 파일을 포함하는 디렉터리입니다. BUILD 파일은 소스에서 빌드할 수 있는 소프트웨어 출력을 지정합니다.

작업공간

작업공간은 빌드할 소프트웨어의 소스 파일이 포함된 파일 시스템의 디렉터리 트리입니다. 각 작업공간에는 이름이 WORKSPACE인 텍스트 파일이 있습니다. 이 파일은 비어 있거나 출력을 빌드하는 데 필요한 외부 종속 항목에 대한 참조를 포함할 수 있습니다.

WORKSPACE이라는 파일이 포함된 디렉터리는 작업공간의 루트로 간주됩니다. 따라서 Bazel은 다른 작업공간을 형성하므로 WORKSPACE 파일이 포함된 하위 디렉터리에 있는 작업공간의 모든 디렉터리 트리를 무시합니다.

Bazel은 WORKSPACE.bazel 파일을 WORKSPACE 파일의 별칭으로 지원합니다. 두 파일이 모두 있는 경우 WORKSPACE.bazel가 사용됩니다.

저장소

코드는 저장소로 구성됩니다. WORKSPACE 파일이 포함된 디렉터리는 기본 저장소의 루트이며 @라고도 합니다. 그 외(외부) 저장소는 작업공간 규칙을 사용하여 WORKSPACE 파일에 정의하거나 Bzlmod 시스템의 모듈과 확장 프로그램에서 생성됩니다. 자세한 내용은 외부 종속 항목 개요를 참고하세요.

Bazel과 함께 제공되는 작업공간 규칙은 백과사전 빌드작업공간 규칙 섹션과 삽입된 Starlark 저장소 규칙에 관한 문서를 참조하세요.

외부 저장소 자체가 저장소이므로 WORKSPACE 파일도 포함되는 경우가 많습니다. 하지만 이러한 추가 WORKSPACE 파일은 Bazel에서 무시합니다. 특히 전이에 종속된 저장소는 자동으로 추가되지 않습니다.

패키지

저장소에서 코드 구성의 기본 단위는 패키지입니다. 패키지는 관련 파일의 모음이자 출력 아티팩트를 생성하는 데 사용할 수 있는 방법을 지정합니다.

패키지는 BUILD 또는 BUILD.bazel라는 BUILD 파일이 포함된 디렉터리로 정의됩니다. 패키지에는 디렉터리에 있는 모든 파일과 그 아래에 모든 하위 디렉터리가 포함되지만 BUILD 파일이 포함된 파일은 제외됩니다. 이 정의에서 파일 또는 디렉터리는 서로 다른 두 패키지의 일부일 수 있습니다.

예를 들어 다음 디렉터리 트리에는 두 개의 패키지 my/app와 하위 패키지 my/app/tests가 있습니다. my/app/data는 패키지가 아니라 my/app 패키지에 속하는 디렉터리입니다.

src/my/app/BUILD
src/my/app/app.cc
src/my/app/data/input.txt
src/my/app/tests/BUILD
src/my/app/tests/test.cc

대상

패키지는 패키지의 BUILD 파일에 정의된 대상의 컨테이너입니다. 대부분의 대상은 파일규칙이라는 두 가지 주요 종류 중 하나입니다.

파일은 다음 두 가지로 구분됩니다. 소스 파일은 일반적으로 사용자의 노력에 의해 작성되며 저장소에 체크인됩니다. 파생된 파일 또는 출력 파일이라고도 하는 생성된 파일은 체크인되지 않지만 소스 파일에서 생성됩니다.

두 번째 대상은 규칙으로 선언됩니다. 각 규칙 인스턴스는 입력 집합과 출력 파일 집합 간의 관계를 지정합니다. 규칙의 입력은 소스 파일일 수 있지만 다른 규칙의 출력일 수도 있습니다.

규칙에 대한 입력이 소스 파일인지 생성된 파일인지는 대부분의 경우 중요하지 않습니다. 중요한 것은 해당 파일의 콘텐츠만입니다. 이렇게 하면 복잡한 소스 파일을 규칙으로 생성된 파일로 쉽게 대체할 수 있습니다. 예를 들어 고도로 구조화된 파일을 수동으로 유지해야 하는 부담이 너무 지쳐서 누군가 프로그램을 작성하여 파생할 수 있습니다. 해당 파일의 사용자는 변경할 필요가 없습니다. 반대로 생성된 파일은 로컬 변경사항만 있는 소스 파일로 쉽게 대체할 수 있습니다.

규칙의 입력에는 다른 규칙도 포함될 수 있습니다. 이러한 관계의 정확한 의미는 상당히 복잡하고 언어나 규칙에 따라 달라지는 경우가 많지만 직관적으로 간단합니다. C++ 라이브러리 규칙 A에는 입력을 위한 다른 C++ 라이브러리 규칙 B가 있을 수 있습니다. 이 종속 항목의 영향은 컴파일 중에 B의 헤더 파일을 A에서 사용할 수 있고 B의 기호는 연결하는 동안 A에서 사용할 수 있으며 B의 런타임 데이터는 실행 중에 A에서 사용할 수 있다는 점입니다.

모든 규칙에 변하지 않는 점은 규칙으로 생성된 파일이 항상 규칙 자체와 동일한 패키지에 속한다는 것입니다. 파일을 다른 패키지로 생성할 수는 없습니다. 하지만 규칙의 입력이 다른 패키지에서 들어오는 경우는 드뭅니다.

패키지 그룹은 특정 규칙의 접근성을 제한하기 위한 패키지 집합입니다. 패키지 그룹은 package_group 함수로 정의됩니다. 여기에는 포함된 패키지 목록, 이름, 포함된 기타 패키지 그룹이라는 세 가지 속성이 있습니다. 이를 참조하는 유일한 방법은 규칙의 visibility 속성 또는 package 함수의 default_visibility 속성에서만 생성됩니다. 이러한 속성은 파일을 생성하거나 사용하지 않습니다. 자세한 내용은 package_group 문서를 참고하세요.

라벨