이 페이지에서는 Bazel에 익숙하다고 가정하고 Bazel의 기능을 최대한 활용할 수 있도록 프로젝트를 구조화하는 방법에 관한 가이드라인과 조언을 제공합니다.
전체 목표는 다음과 같습니다.
- 세분화된 종속 항목을 사용하여 병렬 처리 및 증분성을 허용합니다.
- 종속 항목을 잘 캡슐화하기 위해
- 코드를 잘 구조화하고 테스트할 수 있도록 합니다.
- 이해하고 유지관리하기 쉬운 빌드 구성을 만듭니다.
이 가이드라인은 요구사항이 아닙니다. 모든 가이드라인을 준수할 수 있는 프로젝트는 거의 없습니다. lint의 man 페이지에 나와 있듯이 '엄격한 검사로 오류가 발생하지 않는 실제 프로그램을 만든 첫 번째 사람에게 특별한 보상이 주어집니다.' 하지만 이러한 원칙을 최대한 많이 통합하면 프로젝트의 가독성이 높아지고 오류가 발생할 가능성이 줄어들며 빌드 속도가 빨라집니다.
이 페이지에서는 이 RFC에 설명된 요구사항 수준을 사용합니다.
빌드 및 테스트 실행
프로젝트는 항상 안정적인 브랜치에서 bazel build //... 및 bazel test //...을 성공적으로 실행할 수 있어야 합니다. 필요하지만 특정 상황에서 빌드되지 않는 타겟 (예: 특정 빌드 플래그 필요, 특정 플랫폼에서 빌드되지 않음, 라이선스 계약 필요)은 최대한 구체적으로 태그해야 합니다 (예: 'requires-osx'). 이렇게 태그하면 'manual' 태그보다 더 세부적인 수준에서 타겟을 필터링할 수 있으며 BUILD 파일을 검사하는 사람이 타겟의 제한사항을 이해할 수 있습니다.
타사 종속 항목
다음과 같이 서드 파티 종속 항목을 선언할 수 있습니다.
MODULE.bazel파일에서 원격 저장소로 선언합니다.- 또는 작업공간 디렉터리 아래에
third_party/라는 디렉터리에 넣습니다.
바이너리에 따라 다름
가능한 경우 항상 소스에서 빌드해야 합니다. 일반적으로 이는 라이브러리 some-library.so에 의존하는 대신 BUILD 파일을 만들고 소스에서 some-library.so을 빌드한 다음 해당 타겟에 의존한다는 의미입니다.
항상 소스에서 빌드하면 호환되지 않는 플래그나 다른 아키텍처로 빌드된 라이브러리를 빌드에서 사용하지 않습니다. 소스에서만 작동하는 커버리지, 정적 분석, 동적 분석과 같은 기능도 있습니다.
버전 관리
가능하면 항상 head에서 모든 코드를 빌드하는 것이 좋습니다. 버전을 사용해야 하는 경우 타겟 이름에 버전을 포함하지 마세요 (예: //guava, //guava-20.0 아님). 이렇게 이름을 지정하면 라이브러리를 더 쉽게 업데이트할 수 있습니다 (하나의 타겟만 업데이트하면 됨). 다이아몬드 종속 항목 문제에도 더 탄력적입니다. 한 라이브러리가 guava-19.0에 종속되고 다른 라이브러리가 guava-20.0에 종속되는 경우 두 가지 다른 버전에 종속되려고 하는 라이브러리가 발생할 수 있습니다.
두 타겟이 하나의 guava 라이브러리를 가리키도록 잘못된 별칭을 만든 경우 BUILD 파일이 잘못됩니다.
.bazelrc 파일 사용
프로젝트별 옵션의 경우 workspace/.bazelrc의 구성 파일을 사용하세요 (bazelrc 형식 참고).
소스 제어에 체크인하지 않으려는 프로젝트의 사용자별 옵션을 지원하려면 다음 줄을 포함하세요.
try-import %workspace%/user.bazelrc
(또는 다른 파일 이름)을 workspace/.bazelrc에 추가하고 user.bazelrc을 .gitignore에 추가합니다.
오픈소스 bazelrc-preset.bzl{: .external}은 Bazel 버전과 일치하는 맞춤 bazelrc 파일을 생성하고 권장 플래그의 사전 설정을 제공합니다.
패키지
빌드 가능한 파일이 포함된 모든 디렉터리는 패키지여야 합니다. BUILD 파일이 하위 디렉터리 (예: srcs = ["a/b/C.java"])의 파일을 참조하는 경우 해당 하위 디렉터리에 BUILD 파일을 추가해야 합니다. 이 구조가 오래될수록 순환 종속 항목이 실수로 생성될 가능성이 높아지고 타겟의 범위가 확대되며 업데이트해야 하는 역방향 종속 항목의 수가 증가합니다.