규칙
- cc_binary
- cc_import
- cc_library
- cc_proto_library
- fdo_prefetch_hints
- fdo_profile
- propeller_optimize
- cc_test
- cc_toolchain
- cc_toolchain_suite
cc_binary
cc_binary(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, exec_compatible_with, exec_properties, features, includes, licenses, linkopts, linkshared, linkstatic, local_defines, malloc, nocopts, output_licenses, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)
암시적 출력 대상
name.stripped
(명시적으로 요청된 경우에만 빌드됨): 바이너리의 제거된 버전입니다.strip -g
는 바이너리에서 실행되어 디버그 기호를 삭제합니다.--stripopt=-foo
를 사용하여 명령줄에서 추가 스트립 옵션을 제공할 수 있습니다. 이 출력은 명시적으로 요청된 경우에만 빌드됩니다.name.dwp
(명시적으로 요청된 경우에만 빌드됨): 분열이 사용 설정된 경우 원격으로 배포된 바이너리를 디버깅하는 데 적합한 디버그 정보 패키지 파일입니다. 그 외의 경우에는 빈 파일입니다.
인수
특성 | |
---|---|
name |
이 대상의 고유한 이름입니다. |
deps
|
|
srcs
|
모든
모든 규칙의 이름이
허용되는
이러한 파일을 생성하는 모든 규칙이 포함됩니다. 확장 프로그램마다 gcc 규칙에 따라 다른 프로그래밍 언어를 표시합니다. |
additional_linker_inputs
|
예를 들어 컴파일된 Windows .res 파일을 여기에 제공하여 바이너리 대상에 삽입할 수 있습니다. |
copts
|
이 속성의 각 문자열은 바이너리 타겟을 컴파일하기 전에
패키지가 feature
|
defines
|
-D 가 앞에 추가되며 이 대상의 컴파일 명령줄과 이에 종속된 모든 규칙에 추가됩니다. 큰 영향을 미칠 수 있으므로 매우 주의해야 합니다. 확실하지 않은 경우 정의 값을 대신 local_defines 에 추가하세요.
|
includes
|
"Makevariable" 대체가 적용됩니다.
각 문자열은 헤더를 srcs 또는 hdrs에 추가해야 합니다. 그렇지 않으면 컴파일이 샌드박스 (기본값) 상태일 때 종속 규칙에서 헤더를 사용할 수 없습니다. |
linkopts
|
LINKOPTS 에 추가됩니다.
이 목록에서 |
linkshared
|
linkshared=True 을(를) 포함하세요. 기본적으로 이 옵션은 사용 중지되어 있습니다.
이 플래그가 있으면
|
linkstatic
|
cc_binary 및 cc_test : 바이너리를 정적 모드에서 연결합니다. cc_library.linkstatic 의 경우 아래를 참고하세요.
기본적으로 이 옵션은
바이너리 또는 테스트인 경우 이 옵션은 가능한 경우 항상 사용자 라이브러리에 대해 실행 파일을 연결하는 방법에는 크게 세 가지가 있습니다.
|
local_defines
|
-D 가 추가되어 이 타겟의 컴파일 명령줄에 추가되지만 종속 항목에는 추가되지 않습니다.
|
malloc
|
기본적으로 C++ 바이너리는 빈 라이브러리인 |
nocopts
|
COPTS (규칙의 copts 속성에 명시적으로 지정된 값 포함)은 이 규칙을 컴파일하기 위해 COPTS 에서 삭제됩니다.
이 속성은 거의 필요하지 않습니다.
|
stamp
|
스탬핑된 바이너리는 종속 항목이 변경되지 않는 한 다시 빌드되지 않습니다. |
win_def_file
|
이 속성은 Windows가 타겟 플랫폼인 경우에만 사용해야 합니다. 공유 라이브러리를 연결하는 동안 기호를 내보내는 데 사용할 수 있습니다. |
cc_import
cc_import(name, data, hdrs, alwayslink, compatible_with, deprecation, distribs, features, interface_library, licenses, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, visibility)
cc_import
규칙을 사용하면 사용자가 사전 컴파일된 C/C++ 라이브러리를 가져올 수 있습니다.
일반적인 사용 사례는 다음과 같습니다.
1. 정적 라이브러리 연결
cc_import( name = "mylib", hdrs = ["mylib.h"], static_library = "libmylib.a", # If alwayslink is turned on, # libmylib.a will be forcely linked into any binary that depends on it. # alwayslink = 1, )2. 공유 라이브러리 연결 (Unix)
cc_import( name = "mylib", hdrs = ["mylib.h"], shared_library = "libmylib.so", )3. 공유 라이브러리를 인터페이스 라이브러리와 연결 (Windows)
cc_import( name = "mylib", hdrs = ["mylib.h"], # mylib.lib is a import library for mylib.dll which will be passed to linker interface_library = "mylib.lib", # mylib.dll will be available for runtime shared_library = "mylib.dll", )4. 공유 라이브러리를
system_provided=True
에 연결 (Windows)
cc_import( name = "mylib", hdrs = ["mylib.h"], # mylib.lib is an import library for mylib.dll which will be passed to linker interface_library = "mylib.lib", # mylib.dll is provided by system environment, for example it can be found in PATH. # This indicates that Bazel is not responsible for making mylib.dll available. system_provided = 1, )5. 정적 라이브러리 또는 공유 라이브러리
에 연결 Unix:
cc_import( name = "mylib", hdrs = ["mylib.h"], static_library = "libmylib.a", shared_library = "libmylib.so", ) # first will link to libmylib.a cc_binary( name = "first", srcs = ["first.cc"], deps = [":mylib"], linkstatic = 1, # default value ) # second will link to libmylib.so cc_binary( name = "second", srcs = ["second.cc"], deps = [":mylib"], linkstatic = 0, )Windows:
cc_import( name = "mylib", hdrs = ["mylib.h"], static_library = "libmylib.lib", # A normal static library interface_library = "mylib.lib", # An import library for mylib.dll shared_library = "mylib.dll", ) # first will link to libmylib.lib cc_binary( name = "first", srcs = ["first.cc"], deps = [":mylib"], linkstatic = 1, # default value ) # second will link to mylib.dll through mylib.lib cc_binary( name = "second", srcs = ["second.cc"], deps = [":mylib"], linkstatic = 0, )
인수
특성 | |
---|---|
name |
이 대상의 고유한 이름입니다. |
hdrs
|
|
alwayslink
|
Windows의 VS 2017에서 항상 링크가 작동하지 않는다면 알려진 문제로 인한 것입니다. VS 2017을 최신 버전으로 업그레이드하세요. |
interface_library
|
허용되는 파일 형식: |
shared_library
|
허용되는 파일 형식: |
static_library
|
허용되는 파일 형식: |
system_provided
|
interface_library 를 지정해야 하고 shared_library 는 비어 있어야 합니다.
|
cc_library
cc_library(name, deps, srcs, data, hdrs, additional_compiler_inputs, additional_linker_inputs, alwayslink, compatible_with, copts, defines, deprecation, distribs, exec_compatible_with, exec_properties, features, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, nocopts, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)
헤더 포함 확인
빌드에 사용되는 모든 헤더 파일은 cc_*
규칙의 hdrs
또는 srcs
에서 선언해야 합니다. 이는 시행되는 것입니다.
cc_library
규칙의 경우 hdrs
의 헤더는 라이브러리의 공개 인터페이스를 구성하며 라이브러리 자체의 hdrs
및 srcs
에 있는 파일과 deps
에 라이브러리를 나열하는 cc_*
규칙의 hdrs
및 srcs
에 있는 파일 모두에서 직접 포함될 수 있습니다.
srcs
의 헤더는 라이브러리 자체의 hdrs
및 srcs
에 있는 파일에서만 직접 포함되어야 합니다. 헤더를 hdrs
에 넣을지 srcs
에 넣을지 결정할 때는 이 라이브러리의 소비자가 헤더를 직접 포함할 수 있도록 할지 물어봐야 합니다. 이는 프로그래밍 언어의 public
공개 상태와 private
공개 상태 사이의 결정과 거의 동일합니다.
cc_binary
및 cc_test
규칙에는 내보낸 인터페이스가 없으므로 hdrs
속성도 없습니다. 바이너리 또는 테스트에 직접 속하는 모든 헤더는 srcs
에 나열되어야 합니다.
이러한 규칙을 자세히 알아보려면 다음 예를 살펴보세요.
cc_binary( name = "foo", srcs = [ "foo.cc", "foo.h", ], deps = [":bar"], ) cc_library( name = "bar", srcs = [ "bar.cc", "bar-impl.h", ], hdrs = ["bar.h"], deps = [":baz"], ) cc_library( name = "baz", srcs = [ "baz.cc", "baz-impl.h", ], hdrs = ["baz.h"], )
이 예에서 허용되는 직접 포함은 아래 표에 나와 있습니다. 예를 들어 foo.cc
는 foo.h
및 bar.h
를 직접 포함할 수 있지만 baz.h
는 포함할 수 없습니다.
파일 포함 중 | 허용된 포함 |
---|---|
foo.h | bar.h |
foo.cc | foo.h bar.h |
bar.h | bar-impl.h baz.h |
bar-impl.h | bar.h baz.h |
bar.cc | bar.h bar-impl.h baz.h |
baz.h | baz-impl.h |
baz-impl.h | baz.h |
baz.cc | baz.h baz-impl.h |
포함 확인 규칙은 직접 포함에만 적용됩니다. 위 예에서 foo.cc
는 bar.h
를 포함할 수 있습니다. 여기에는 baz.h
가 포함될 수 있으며, 결과적으로 baz-impl.h
도 포함될 수 있습니다. 기술적으로 .cc
파일의 컴파일은 전이 deps
클로저의 모든 cc_library
에 있는 hdrs
또는 srcs
에 있는 헤더 파일을 전이적으로 포함할 수 있습니다. 이 경우 컴파일러는 foo.cc
를 컴파일할 때 baz.h
및 baz-impl.h
를 읽을 수 있지만 foo.cc
에는 #include "baz.h"
가 포함되어서는 안 됩니다. 그렇게 하려면 baz
를 foo
의 deps
에 추가해야 합니다.
안타깝게도 현재 Bazel은 직접 포함과 전이 포함을 구분할 수 없으므로 전이적으로만 포함될 수 있는 헤더를 직접 파일이 불법적으로 포함하는 오류 사례를 감지할 수 없습니다. 예를 들어 위 예에서 foo.cc
가 baz.h
을 직접 포함한다면 Bazel이 불만을 제기하지 않을 것입니다. 이는 불법입니다. foo
가 baz
에 직접 종속되지 않기 때문입니다. 현재는 이 경우에 오류가 발생하지 않지만 향후 오류 검사가 추가될 수 있습니다.
인수
특성 | |
---|---|
name |
이 대상의 고유한 이름입니다. |
deps
|
|
srcs
|
모든
모든 규칙의 이름이
허용되는
이러한 파일을 생성하는 모든 규칙이 포함됩니다. 확장 프로그램마다 gcc 규칙에 따라 다른 프로그래밍 언어를 표시합니다. |
hdrs
|
이 위치는 라이브러리의 인터페이스를 설명하는 헤더 파일을 선언할 때 가장 선호되는 위치입니다. 이러한 헤더는
이 규칙 또는 종속 규칙의 소스에 포함할 수 있습니다.
이 라이브러리의 클라이언트에 의해 포함되지 않아야 하는 헤더는 게시된 헤더에 포함되어 있더라도 |
additional_compiler_inputs
|
|
additional_linker_inputs
|
예를 들어 컴파일된 Windows .res 파일을 여기에 제공하여 바이너리 대상에 삽입할 수 있습니다. |
alwayslink
|
srcs 에 나열된 파일의 모든 객체 파일에서 링크됩니다. 일부 바이너리에는 바이너리에서 참조되는 기호가 포함되어 있지 않더라도 마찬가지입니다.
이는 코드가 바이너리의 코드에 의해 명시적으로 호출되지 않는 경우(예: 코드가 일부 서비스에서 제공하는 콜백을 수신하도록 등록되는 경우) 유용합니다.
Windows의 VS 2017에서 항상 링크가 작동하지 않는다면 알려진 문제로 인한 것입니다. VS 2017을 최신 버전으로 업그레이드하세요. |
copts
|
이 속성의 각 문자열은 바이너리 타겟을 컴파일하기 전에
패키지가 feature
|
defines
|
-D 가 앞에 추가되며 이 대상의 컴파일 명령줄과 이에 종속된 모든 규칙에 추가됩니다. 큰 영향을 미칠 수 있으므로 매우 주의해야 합니다. 확실하지 않은 경우 정의 값을 대신 local_defines 에 추가하세요.
|
implementation_deps
|
deps 와 달리, 이러한 라이브러리의 헤더와 포함 경로 (및 모든 전이적 deps)는 이 라이브러리의 컴파일에만 사용되며 이 라이브러리에 종속된 라이브러리는 사용되지 않습니다. implementation_deps 로 지정된 라이브러리는 여전히 이 라이브러리에 종속된 바이너리 타겟에 링크됩니다.
현재 사용은 cc_Library로 제한되며 |
include_prefix
|
이 속성을 설정하면 저장소 상대 경로 앞에 추가된 이 속성의 값에서 이 규칙의
|
includes
|
"Makevariable" 대체가 적용됩니다.
각 문자열은 헤더를 srcs 또는 hdrs에 추가해야 합니다. 그렇지 않으면 컴파일이 샌드박스 (기본값) 상태일 때 종속 규칙에서 헤더를 사용할 수 없습니다. |
linkopts
|
LINKOPTS 에 추가됩니다.
이 목록에서 |
linkstamp
|
base 패키지에만 필요합니다.
|
linkstatic
|
cc_binary 및 cc_test : 바이너리를 정적 모드에서 연결합니다. cc_library.linkstatic 의 경우 아래를 참고하세요.
기본적으로 이 옵션은
바이너리 또는 테스트인 경우 이 옵션은 가능한 경우 항상 사용자 라이브러리에 대해 실행 파일을 연결하는 방법에는 크게 세 가지가 있습니다.
|
local_defines
|
-D 가 추가되어 이 타겟의 컴파일 명령줄에 추가되지만 종속 항목에는 추가되지 않습니다.
|
nocopts
|
COPTS (규칙의 copts 속성에 명시적으로 지정된 값 포함)은 이 규칙을 컴파일하기 위해 COPTS 에서 삭제됩니다.
이 속성은 거의 필요하지 않습니다.
|
strip_include_prefix
|
설정하면 이 프리픽스가 잘린 상태로 경로에서 이 규칙의 상대 경로인 경우 패키지 기준 경로로 사용됩니다. 절대 경로인 경우에는 저장소 기준 경로로 간주됩니다.
|
textual_hdrs
|
스스로 컴파일할 수 없는 헤더 파일을 선언하는 위치입니다. 즉, 유효한 코드를 빌드하려면 다른 소스 파일에 항상 텍스트 형식으로 포함해야 합니다. |
win_def_file
|
이 속성은 Windows가 타겟 플랫폼인 경우에만 사용해야 합니다. 공유 라이브러리를 연결하는 동안 기호를 내보내는 데 사용할 수 있습니다. |
cc_proto_library
cc_proto_library(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
cc_proto_library
는 .proto
파일에서 C++ 코드를 생성합니다.
deps
는 proto_library
규칙을 가리켜야 합니다.
예:
cc_library( name = "lib", deps = [":foo_cc_proto"], ) cc_proto_library( name = "foo_cc_proto", deps = [":foo_proto"], ) proto_library( name = "foo_proto", )
인수
특성 | |
---|---|
name |
이 대상의 고유한 이름입니다. |
deps
|
proto_library 규칙의 목록입니다.
|
fdo_prefetch_hints
fdo_prefetch_hints(name, compatible_with, deprecation, distribs, features, licenses, profile, restricted_to, tags, target_compatible_with, testonly, visibility)
작업공간 또는 지정된 절대 경로에 있는 FDO 미리 가져오기 힌트 프로필을 나타냅니다. 예:
fdo_prefetch_hints( name = "hints", profile = "//path/to/hints:profile.afdo", ) fdo_profile( name = "hints_abs", absolute_path_profile = "/absolute/path/profile.afdo", )
인수
특성 | |
---|---|
name |
이 대상의 고유한 이름입니다. |
profile
|
|
fdo_profile
fdo_profile(name, absolute_path_profile, compatible_with, deprecation, distribs, features, licenses, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, visibility)
작업공간이나 지정된 절대 경로에 있는 FDO 프로필을 나타냅니다. 예:
fdo_profile( name = "fdo", profile = "//path/to/fdo:profile.zip", ) fdo_profile( name = "fdo_abs", absolute_path_profile = "/absolute/path/profile.zip", )
인수
특성 | |
---|---|
name |
이 대상의 고유한 이름입니다. |
absolute_path_profile
|
|
profile
|
|
proto_profile
|
|
propeller_optimize
propeller_optimize(name, compatible_with, deprecation, distribs, features, ld_profile, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
작업공간의 프로펠러 최적화 프로필을 나타냅니다. 예:
propeller_optimize( name = "layout", cc_profile = "//path:cc_profile.txt", ld_profile = "//path:ld_profile.txt" ) propeller_optimize( name = "layout_absolute", absolute_cc_profile = "/absolute/cc_profile.txt", absolute_ld_profile = "/absolute/ld_profile.txt" )
인수
특성 | |
---|---|
name |
이 대상의 고유한 이름입니다. |
ld_profile
|
|
cc_test
cc_test(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, includes, licenses, linkopts, linkstatic, local, local_defines, malloc, nocopts, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)
인수
특성 | |
---|---|
name |
이 대상의 고유한 이름입니다. |
deps
|
|
srcs
|
모든
모든 규칙의 이름이
허용되는
이러한 파일을 생성하는 모든 규칙이 포함됩니다. 확장 프로그램마다 gcc 규칙에 따라 다른 프로그래밍 언어를 표시합니다. |
additional_linker_inputs
|
예를 들어 컴파일된 Windows .res 파일을 여기에 제공하여 바이너리 대상에 삽입할 수 있습니다. |
copts
|
이 속성의 각 문자열은 바이너리 타겟을 컴파일하기 전에
패키지가 feature
|
defines
|
-D 가 앞에 추가되며 이 대상의 컴파일 명령줄과 이에 종속된 모든 규칙에 추가됩니다. 큰 영향을 미칠 수 있으므로 매우 주의해야 합니다. 확실하지 않은 경우 정의 값을 대신 local_defines 에 추가하세요.
|
includes
|
"Makevariable" 대체가 적용됩니다.
각 문자열은 헤더를 srcs 또는 hdrs에 추가해야 합니다. 그렇지 않으면 컴파일이 샌드박스 (기본값) 상태일 때 종속 규칙에서 헤더를 사용할 수 없습니다. |
linkopts
|
LINKOPTS 에 추가됩니다.
이 목록에서 |
linkstatic
|
cc_binary 및 cc_test : 바이너리를 정적 모드에서 연결합니다. cc_library.linkstatic 의 경우 아래를 참고하세요.
기본적으로 이 옵션은
바이너리 또는 테스트인 경우 이 옵션은 가능한 경우 항상 사용자 라이브러리에 대해 실행 파일을 연결하는 방법에는 크게 세 가지가 있습니다.
|
local_defines
|
-D 가 추가되어 이 타겟의 컴파일 명령줄에 추가되지만 종속 항목에는 추가되지 않습니다.
|
malloc
|
기본적으로 C++ 바이너리는 빈 라이브러리인 |
nocopts
|
COPTS (규칙의 copts 속성에 명시적으로 지정된 값 포함)은 이 규칙을 컴파일하기 위해 COPTS 에서 삭제됩니다.
이 속성은 거의 필요하지 않습니다.
|
stamp
|
스탬핑된 바이너리는 종속 항목이 변경되지 않는 한 다시 빌드되지 않습니다. |
win_def_file
|
이 속성은 Windows가 타겟 플랫폼인 경우에만 사용해야 합니다. 공유 라이브러리를 연결하는 동안 기호를 내보내는 데 사용할 수 있습니다. |
cc_toolchain
cc_toolchain(name, all_files, ar_files, as_files, compatible_with, compiler, compiler_files, compiler_files_without_includes, coverage_files, cpu, deprecation, distribs, dwp_files, dynamic_runtime_lib, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, visibility)
C++ 도구 모음을 나타냅니다.
이 규칙의 역할은 다음과 같습니다.
-
C++ 작업을 실행하는 데 필요한 모든 아티팩트 수집 이 작업은
all_files
,compiler_files
,linker_files
또는_files
로 끝나는 기타 속성에 의해 실행됩니다. 가장 일반적으로는 모든 필수 파일을 글로빙하는 파일 그룹입니다. -
C++ 작업을 위한 올바른 명령줄 생성
CcToolchainConfigInfo
제공자를 사용하면 됩니다 (아래 세부정보 참고).
toolchain_config
속성을 사용하여 C++ 도구 모음을 구성합니다.
자세한 C++ 도구 모음 구성 및 도구 모음 선택 문서는 이
페이지
를 참조하세요.
bazel build //...
를 호출할 때 도구 모음이 불필요하게 빌드 및 구성되는 것을 방지하려면 tags = ["manual"]
를 사용하세요.
인수
특성 | |
---|---|
name |
이 대상의 고유한 이름입니다. |
all_files
|
all_files 가 다른 모든 아티팩트를 제공하는 속성의 상위 집합이라고 가정합니다 (예: linktamp 컴파일에는 컴파일 파일과 링크 파일이 모두 필요하므로 all_files 사용).
이는 |
ar_files
|
보관처리 작업에 필요한 모든 cc_toolchain 아티팩트의 컬렉션입니다. |
as_files
|
어셈블리 작업에 필요한 모든 cc_toolchain 아티팩트의 컬렉션입니다. |
compiler
|
toolchain_identifier 속성을 사용하세요.
Starlark로 CROSSTOOL 이전
한 후에는
noop가 되며 #7075를 통해 삭제됩니다.
설정되면 Crosstool_config.toolchain 선택을 수행하는 데 사용됩니다. --cpu Bazel 옵션보다 우선 적용됩니다. |
compiler_files
|
|
compiler_files_without_includes
|
|
coverage_files
|
|
cpu
|
설정되면 Crosstool_config.toolchain 선택을 수행하는 데 사용됩니다. --cpu Bazel 옵션보다 우선 적용됩니다. |
dwp_files
|
|
dynamic_runtime_lib
|
이는 'static_link_cpp_runtimes' 기능이 사용 설정되고 종속 항목을 동적으로 연결할 때 사용됩니다. |
exec_transition_for_inputs
|
|
libc_top
|
|
linker_files
|
|
module_map
|
|
objcopy_files
|
|
static_runtime_lib
|
이는 'static_link_cpp_runtimes' 기능이 사용 설정되고 종속 항목을 정적으로 연결할 때 사용됩니다. |
strip_files
|
|
supports_header_parsing
|
|
supports_param_files
|
|
toolchain_config
|
cc_toolchain_config_info 를 제공하는 규칙의 라벨입니다.
|
toolchain_identifier
|
#5380 문제가 해결될 때까지 이 방법은 |
cc_toolchain_suite
cc_toolchain_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
C++ 도구 모음 모음을 나타냅니다.
이 규칙의 역할은 다음과 같습니다.
- 모든 관련 C++ 도구 모음 수집
-
Bazel에 전달된
--cpu
및--compiler
옵션에 따라 하나의 도구 모음을 선택합니다.
자세한 C++ 도구 모음 구성 및 도구 모음 선택 문서는 이 페이지 를 참조하세요.
인수
특성 | |
---|---|
name |
이 대상의 고유한 이름입니다. |
toolchains
|
cc_toolchain 라벨로 매핑됩니다. --cpu 만 Bazel에 전달될 때 '<cpu>'가 사용되며 --cpu 과 --compiler 가 모두 Bazel에 전달될 때 '<cpu>|<compiler>'이 사용됩니다. 예:
cc_toolchain_suite( name = "toolchain", toolchains = { "piii|gcc": ":my_cc_toolchain_for_piii_using_gcc", "piii": ":my_cc_toolchain_for_piii_using_default_compiler", }, ) |