이 페이지는 Bazel에 익숙하며 가이드라인과 Bazel의 기능을 최대한 활용하려면 프로젝트를 구성하는 방법에 대한 조언을 참조하세요.
전반적인 목표는 다음과 같습니다.
- 세분화된 종속 항목을 사용하여 동시 로드 및 성과 증분을 허용하기 위해
- 종속 항목을 잘 캡슐화하기 위해
- 코드를 잘 구조화하고 테스트 가능하게 만들기 위해
- 이해하고 유지관리하기 쉬운 빌드 구성을 만들기 위해
이 가이드라인은 필수가 아니며, 정책을 준수할 수 있는 프로젝트는 거의 없습니다. 있습니다. Lint의 man 페이지에 "특별한 리워드가 제공될 예정이며 오류가 발생하지 않는 실제 프로그램을 만드는 첫 번째 사람에게 엄격하게 검사하시기 바랍니다." 하지만 이러한 원칙을 최대한 많이 적용하면 프로젝트의 가독성과 오류 발생 가능성이 적으며 빌드 속도가 빨라야 합니다.
이 페이지에서는 이 RFC에서 읽을 수 있습니다.
빌드 및 테스트 실행
프로젝트는 항상 bazel build //...를 실행할 수 있어야 하며
안정화 브랜치에서 bazel test //...가 성공적으로 실행되었습니다. 필요한 타겟
빌드하지 않는 특정 상황 (예: 특정 빌드 필요)
특정 플랫폼에 구축하지 않거나 라이선스 계약을 필요로 하는 경우)여야 합니다.
(예: 'requires-osx') 이
태깅을 사용하면 대상을 더 세밀한 수준으로 필터링할 수 있습니다.
'manual' 태그를 추가하고 BUILD 파일을 검사하는 사람이
대상의 제한입니다
타사 종속 항목
서드 파티 종속 항목을 선언할 수 있습니다.
WORKSPACE파일에서 원격 저장소로 선언합니다.- 또는 작업공간 디렉터리 아래의
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 파일을 하위 디렉터리에 추가해야 한다는 기호 오래 걸릴수록
순환 종속 항목이 많아질수록
타겟의 범위가 급격히 늘어나기 때문에
업데이트해야 합니다