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