이 페이지에서는 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 파일이 이 하위 디렉터리에 추가되어야 한다는 신호입니다. 이 구조가 길수록 실수로 종속 항목이 생성될 가능성이 높아지고 대상의 범위가 조정되며 증가한 역방향 종속 항목 수를 업데이트해야 합니다.