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