이 페이지에서는 출력 디렉터리의 요구사항과 레이아웃을 설명합니다.
요구사항
출력 디렉터리 레이아웃 요구사항:
- 여러 사용자가 동일한 상자에서 빌드하는 경우 충돌하지 않습니다.
- 여러 작업공간에서 동시에 빌드를 지원합니다.
- 동일한 워크스페이스에서 여러 타겟 구성에 관한 빌드를 지원합니다.
- 다른 도구와 충돌하지 않습니다.
- 액세스가 쉽습니다.
- 선택적으로도 쉽게 청소할 수 있습니다.
- 사용자가 클라이언트 디렉터리로 변경할 때 기호 링크를 사용하더라도 모호하지 않습니다.
- 사용자별 모든 빌드 상태가 하나의 디렉터리 아래에 있어야 합니다. '모든 클라이언트에서 모든 .o 파일을 삭제하고 싶습니다.'
현재 레이아웃
현재 구현된 솔루션:
- Bazel은 저장소 경계 파일이 포함된 디렉터리 또는 그 하위 디렉터리에서 호출해야 합니다. 즉, Bazel은 저장소 내에서 호출해야 합니다. 그렇지 않으면 오류가 보고됩니다.
- outputRoot 디렉터리는 Linux에서는 기본적으로
${XDG_CACHE_HOME}/bazel(또는XDG_CACHE_HOME환경 변수가 설정되지 않은 경우~/.cache/bazel)이고, macOS에서는/private/var/tmp이며, Windows에서는 설정된 경우 기본적으로%HOME%이고, 설정되지 않은 경우%USERPROFILE%이며,FOLDERID_Profile플래그가 설정된 경우SHGetKnownFolderPath()를 호출한 결과입니다. Bazel 자체 테스트에서와 같이 환경 변수$TEST_TMPDIR가 설정된 경우 이 값이 기본값을 재정의합니다. - Bazel 사용자의 빌드 상태는
outputRoot/_bazel_$USER아래에 있습니다. 이를 outputUserRoot 디렉터리라고 합니다. outputUserRoot디렉터리 아래에는install디렉터리가 있고, 이 디렉터리에는 이름이 Bazel 설치 매니페스트의 MD5 해시인installBase디렉터리가 있습니다.outputUserRoot디렉터리 아래에는 워크스페이스 루트의 경로 이름의 MD5 해시인outputBase디렉터리도 생성됩니다. 예를 들어 Bazel이 워크스페이스 루트/home/user/src/my-project(또는 이와 연결된 심볼릭 링크 디렉터리)에서 실행 중인 경우/home/user/.cache/bazel/_bazel_user/7ffd56a6e4cb724ea575aba15733d113라는 출력 기본 디렉터리가 생성됩니다. 작업공간 루트에서echo -n $(pwd) | md5sum를 실행하여 MD5를 가져올 수도 있습니다.- Bazel의
--output_base시작 옵션을 사용하여 기본 출력 기본 디렉터리를 재정의할 수 있습니다. 예를 들면bazel --output_base=/tmp/bazel/output build x/y:z입니다. - Bazel의
--output_user_root시작 옵션을 사용하여 기본 설치 기반 및 출력 기반 디렉터리를 재정의할 수도 있습니다. 예를 들면bazel --output_user_root=/tmp/bazel build x/y:z입니다.
'bazel-<workspace-name>", 'bazel-out', 'bazel-testlogs', 'bazel-bin'의 심볼릭 링크가 작업공간 디렉터리에 배치됩니다. 이러한 심볼릭 링크는 출력 디렉터리 내의 타겟별 디렉터리 내의 일부 디렉터리를 가리킵니다. 이러한 심볼릭 링크는 Bazel 자체에서 사용하지 않으므로 사용자의 편의를 위한 것입니다. 또한 작업공간 루트에 쓸 수 있는 권한이 있는 경우에만 실행됩니다.
레이아웃 다이어그램
디렉터리는 다음과 같이 배치됩니다.
<workspace-name>/ <== The workspace root
bazel-my-project => <...my-project> <== Symlink to execRoot
bazel-out => <...bin> <== Convenience symlink to outputPath
bazel-bin => <...bin> <== Convenience symlink to most recent written bin dir $(BINDIR)
bazel-testlogs => <...testlogs> <== Convenience symlink to the test logs directory
/home/user/.cache/bazel/ <== Root for all Bazel output on a machine: outputRoot
_bazel_$USER/ <== Top level directory for a given user depends on the user name:
outputUserRoot
install/
fba9a2c87ee9589d72889caf082f1029/ <== Hash of the Bazel install manifest: installBase
_embedded_binaries/ <== Contains binaries and scripts unpacked from the data section of
the bazel executable on first run (such as helper scripts and the
main Java file BazelServer_deploy.jar)
7ffd56a6e4cb724ea575aba15733d113/ <== Hash of the client's workspace root (such as
/home/user/src/my-project): outputBase
action_cache/ <== Action cache directory hierarchy
This contains the persistent record of the file
metadata (timestamps, and perhaps eventually also MD5
sums) used by the FilesystemValueChecker.
action_outs/ <== Action output directory. This contains a file with the
stdout/stderr for every action from the most recent
bazel run that produced output.
command.log <== A copy of the stdout/stderr output from the most
recent bazel command.
external/ <== The directory that remote repositories are
downloaded/symlinked into.
server/ <== The Bazel server puts all server-related files (such
as socket file, logs, etc) here.
jvm.out <== The debugging output for the server.
execroot/ <== The working directory for all actions. For special
cases such as sandboxing and remote execution, the
actions run in a directory that mimics execroot.
Implementation details, such as where the directories
are created, are intentionally hidden from the action.
Every action can access its inputs and outputs relative
to the execroot directory.
_main/ <== Working tree for the Bazel build & root of symlink forest: execRoot
_bin/ <== Helper tools are linked from or copied to here.
bazel-out/ <== All actual output of the build is under here: outputPath
local_linux-fastbuild/ <== one subdirectory per unique target BuildConfiguration instance;
this is currently encoded
bin/ <== Bazel outputs binaries for target configuration here: $(BINDIR)
foo/bar/_objs/baz/ <== Object files for a cc_* rule named //foo/bar:baz
foo/bar/baz1.o <== Object files from source //foo/bar:baz1.cc
other_package/other.o <== Object files from source //other_package:other.cc
foo/bar/baz <== foo/bar/baz might be the artifact generated by a cc_binary named
//foo/bar:baz
foo/bar/baz.runfiles/ <== The runfiles symlink farm for the //foo/bar:baz executable.
MANIFEST
_main/
...
genfiles/ <== Bazel puts generated source for the target configuration here:
$(GENDIR)
foo/bar.h such as foo/bar.h might be a headerfile generated by //foo:bargen
testlogs/ <== Bazel internal test runner puts test log files here
foo/bartest.log such as foo/bar.log might be an output of the //foo:bartest test with
foo/bartest.status foo/bartest.status containing exit status of the test (such as
PASSED or FAILED (Exit 1), etc)
include/ <== a tree with include symlinks, generated as needed. The
bazel-include symlinks point to here. This is used for
linkstamp stuff, etc.
host/ <== BuildConfiguration for build host (user's workstation), for
building prerequisite tools, that will be used in later stages
of the build (ex: Protocol Compiler)
<packages>/ <== Packages referenced in the build appear as if under a regular workspace
*.runfiles 디렉터리의 레이아웃은 RunfilesSupport에서 가리키는 위치에 자세히 설명되어 있습니다.
bazel clean
bazel clean는 outputPath 및 action_cache 디렉터리에서 rm -rf을 실행합니다. 또한 작업공간 심볼릭 링크도 삭제됩니다. --expunge 옵션은 전체 outputBase를 정리합니다.