규칙
- cc_binary
- cc_import
- cc_library
- cc_proto_library
- cc_shared_library
- fdo_prefetch_hints
- fdo_profile
- propeller_optimize
- cc_test
- cc_toolchain
- cc_toolchain_suite
cc_바이너리
규칙 소스 보기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(명시적으로 요청된 경우에만 빌드됨): Fission이 사용 설정된 경우: 원격으로 배포된 바이너리를 디버깅하는 데 적합한 디버그 정보 패키지 파일입니다. 그렇지 않은 경우: 빈 파일입니다.
인수
| 속성 | |
|---|---|
name |
이 대상의 고유한 이름입니다. |
deps
|
|
srcs
|
모든
모든 규칙의 이름이
허용되는
이러한 파일을 생성하는 모든 규칙을 정의합니다. 확장자가 다르면 gcc 규칙에 따라 다양한 프로그래밍 언어가 표시됩니다. |
additional_linker_inputs
|
예를 들어 컴파일된 Windows .res 파일을 바이너리 대상에 삽입하기 위해 여기에 제공할 수 있습니다. |
copts
|
이 속성의 각 문자열은 바이너리 타겟을 컴파일하기 전에 지정된 순서로
패키지가 기능
|
defines
|
-D으로 시작되며 이 대상의 컴파일 명령줄뿐만 아니라 이를 사용하는 모든 규칙에 추가됩니다. 광범위한 영향을 미칠 수 있으므로 매우 주의해야 합니다. 확실하지 않으면 대신 정의 값을 local_defines에 추가하세요.
|
includes
|
'변수 만들기' 대체가 적용됩니다.
각 문자열 앞에 헤더는 src 또는 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, deps, 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 an 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, )
cc_import은 include 속성을 지원합니다. 예를 들면 다음과 같습니다.
cc_import( name = "curl_lib", hdrs = glob(["vendor/curl/include/curl/*.h"]), includes = [ "vendor/curl/include" ], shared_library = "vendor/curl/lib/.libs/libcurl.dylib", )
인수
| 속성 | |
|---|---|
name |
이 대상의 고유한 이름입니다. |
deps
|
deps에 관한 일반적인 댓글을 확인하세요.
|
hdrs
|
|
alwayslink
|
Windows에서 항상 링크가 VS 2017에서 작동하지 않는 경우 알려진 문제로 인한 것입니다. VS 2017을 최신 버전으로 업그레이드하세요. |
interface_library
|
허용되는 파일 형식:
|
shared_library
|
허용되는 파일 형식:
|
static_library
|
허용되는 파일 형식:
|
system_provided
|
interface_library을 지정해야 하며 shared_library는 비워 두어야 합니다.
|
cc_라이브러리
규칙 소스 보기cc_library(name, deps, srcs, data, hdrs, 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 | 바 |
| foo.cc | 푸 바 |
| 바 | bar-impl.h baz.h |
| bar-impl.h | 바.바스. |
| 바.cc | bar.h bar-impl.h baz.h |
| 바즈. | baz-impl.h |
| baz-impl.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은 포함 확인 규칙을 적용하기 위해 도구 모음 지원을 사용합니다.
layering_check 기능은 도구 모음에서 지원하고, 예를 들어 --features=layering_check 명령줄 플래그 또는 package 함수의 features 매개변수를 통해 명시적으로 요청해야 합니다. Bazel에서 제공하는 도구 모음은 Unix 및 macOS에서 clang로만 이 기능을 지원합니다.
인수
| 속성 | |
|---|---|
name |
이 대상의 고유한 이름입니다. |
deps
|
|
srcs
|
모든
모든 규칙의 이름이
허용되는
이러한 파일을 생성하는 모든 규칙을 정의합니다. 확장자가 다르면 gcc 규칙에 따라 다양한 프로그래밍 언어가 표시됩니다. |
hdrs
|
라이브러리의 인터페이스를 설명하는 헤더 파일을 선언하는 데 권장되는 위치입니다. 이러한 헤더는 이 규칙 또는 종속 규칙의 소스에 포함될 수 있습니다.
이 라이브러리의 클라이언트에 포함되지 않아야 하는 헤더는 게시된 헤더에 포함되더라도 |
alwayslink
|
srcs에 나열된 파일의 모든 객체 파일에 연결됩니다. 이는 바이너리에 의해 참조되는 기호가 없는 파일도 마찬가지입니다.
이는 코드가 바이너리의 코드로 명시적으로 호출되지 않는 경우(예: 일부 서비스에서 제공하는 일부 콜백을 수신하도록 코드를 등록하는 경우)에 유용합니다.
Windows에서 항상 링크가 VS 2017에서 작동하지 않는 경우 알려진 문제로 인한 것입니다. VS 2017을 최신 버전으로 업그레이드하세요. |
copts
|
이 속성의 각 문자열은 바이너리 타겟을 컴파일하기 전에 지정된 순서로
패키지가 기능
|
defines
|
-D으로 시작되며 이 대상의 컴파일 명령줄뿐만 아니라 이를 사용하는 모든 규칙에 추가됩니다. 광범위한 영향을 미칠 수 있으므로 매우 주의해야 합니다. 확실하지 않으면 대신 정의 값을 local_defines에 추가하세요.
|
implementation_deps
|
deps와 달리 이러한 라이브러리의 헤더와 포함 경로 및 모든 전이적 종속 항목은 이 라이브러리의 컴파일에만 사용되며 종속된 라이브러리에는 사용되지 않습니다. implementation_deps으로 지정된 라이브러리는 이 라이브러리에 종속된 바이너리 타겟에 계속 연결됩니다.
현재 이 사용은 cc_library로 제한되고 |
include_prefix
|
설정되면 이 규칙의 이 접두어를 추가하기 전에 |
includes
|
'변수 만들기' 대체가 적용됩니다.
각 문자열 앞에 헤더는 src 또는 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 규칙의 목록입니다.
|
cc_shared_library
규칙 소스 보기cc_shared_library(name, deps, additional_linker_inputs, dynamic_deps, exports_filter, shared_lib_name, tags, user_link_flags, win_def_file)
공유 라이브러리를 생성합니다.
예
cc_shared_library(
name = "foo_shared",
deps = [
":foo",
],
dynamic_deps = [
":bar_shared",
],
additional_linker_inputs = [
":foo.lds",
],
user_link_flags = [
"-Wl,--version-script=$(location :foo.lds)",
],
)
cc_library(
name = "foo",
srcs = ["foo.cc"],
hdrs = ["foo.h"],
deps = [
":bar",
":baz",
],
)
cc_shared_library(
name = "bar_shared",
shared_lib_name = "bar.so",
deps = [":bar"],
)
cc_library(
name = "bar",
srcs = ["bar.cc"],
hdrs = ["bar.h"],
)
cc_library(
name = "baz",
srcs = ["baz.cc"],
hdrs = ["baz.h"],
)
예시 foo_shared는 foo와 baz를 정적으로 연결하며, 후자는 전이 종속 항목입니다. dynamic_dep bar_shared에 의해 이미 동적으로 제공되므로 bar를 연결하지 않습니다.
foo_shared는 링커 스크립트 *.lds 파일을 사용하여 내보낼 기호를 제어합니다. cc_shared_library 규칙 로직은 내보낼 기호를 제어하지 않으며, 두 공유 라이브러리가 동일한 타겟을 내보내는 경우 분석 단계 중에 내보낸 것으로 가정된 오류만 사용하여 오류를 발생시킵니다.
cc_shared_library의 모든 직접 종속 항목을 내보내는 것으로 가정합니다. 따라서 Bazel은 분석 중에 foo_shared에서 foo를 내보내는 것으로 가정합니다. baz는 foo_shared에서 내보낸다고 가정하지 않습니다. exports_filter와 일치하는 모든 대상도 내보낸 것으로 간주됩니다.
예시의 모든 단일 cc_library는 하나의 cc_shared_library에 표시되어야 합니다. baz도 bar_shared에 연결하려면 tags = ["LINKABLE_MORE_THAN_ONCE"]를 baz에 추가해야 합니다.
shared_lib_name 속성으로 인해 bar_shared에서 생성된 파일의 이름은 Linux에서 기본적으로 사용하는 이름 libbar.so과는 달리 bar.so입니다.
오류
Two shared libraries in dependencies export the same symbols.
이는 동일한 대상을 내보내는 cc_shared_library 종속 항목이 서로 다른 대상을 만들 때마다 발생합니다. 이 문제를 해결하려면 cc_shared_library 종속 항목 중 하나에서 라이브러리를 내보내지 않아야 합니다.
Two shared libraries in dependencies link the same library statically
이는 동일한 타겟을 정적으로 연결하는 서로 다른 두 cc_shared_library 종속 항목으로 새 cc_shared_library를 만들 때마다 발생합니다.
내보내기 오류와 비슷합니다.
이 문제를 해결하는 한 가지 방법은 라이브러리를 cc_shared_library 종속 항목 중 하나에 연결하는 것을 중지하는 것입니다. 동시에 아직 연결되지 않은 라이브러리는 기호에 대한 가시성을 유지할 수 있도록 라이브러리를 내보내야 합니다. 또 다른 방법은 대상을 내보내는 세 번째 라이브러리를 가져오는 것입니다.
세 번째 방법은 원인 cc_library에 LINKABLE_MORE_THAN_ONCE 태그를 지정하는 것입니다. 하지만 이 수정은 드물게 발생하므로 cc_library가 실제로 두 번 이상 연결하는 것이 안전한지 확인해야 합니다.
'//foo:foo' is already linked statically in '//bar:bar' but not exported`
즉, deps의 임시 클로저에 있는 라이브러리는 cc_shared_library 종속 항목 중 하나를 통과하지 않아도 도달할 수 있지만 이미 dynamic_deps의 다른 cc_shared_library에 연결되어 있으며 내보내지 않습니다.
해결책은 cc_shared_library 종속 항목에서 내보내거나 이를 내보내는 세 번째 cc_shared_library를 가져오는 것입니다.
Do not place libraries which only contain a precompiled dynamic library in deps.
사전 컴파일된 동적 라이브러리가 있는 경우 현재 생성 중인 현재 cc_shared_library 대상에 정적으로 연결할 필요가 없고 정적으로 연결할 수도 없습니다. 따라서 cc_shared_library의 deps에 속하지 않습니다. 이 사전 컴파일된 동적 라이브러리가 cc_libraries 중 하나의 종속 항목인 경우 cc_library는 이 라이브러리에 직접 종속되어야 합니다.
Trying to export a library already exported by a different shared library
현재 규칙에서 동적 종속 항목 중 하나로 이미 내보내진 타겟을 내보내려고 하는 경우 이 오류가 표시됩니다.
이 문제를 해결하려면 deps에서 타겟을 삭제하고 동적 종속 항목에서만 사용하거나 exports_filter이 이 대상을 포착하지 않는지 확인하세요.
인수
| 속성 | |
|---|---|
name |
이 대상의 고유한 이름입니다. |
deps
|
이러한 직접 종속 항목의 전이 라이브러리 종속 항목은
분석 중에 규칙 구현은 여러
또한 구현은 동일한 라이브러리가 둘 이상의 |
additional_linker_inputs
|
user_link_flags 속성을 통해 이 작업을 수행할 수 있습니다.
|
dynamic_deps
|
cc_shared_library 종속 항목입니다.
|
exports_filter
|
타겟
이 속성은 실제로 이러한 타겟에 종속 항목 에지를 추가하는 것이 아니라 다음 구문이 허용됩니다.
|
shared_lib_name
|
|
user_link_flags
|
cc_shared_library(
name = "foo_shared",
additional_linker_inputs = select({
"//src/conditions:linux": [
":foo.lds",
":additional_script.txt",
],
"//conditions:default": []}),
user_link_flags = select({
"//src/conditions:linux": [
"-Wl,-rpath,kittens",
"-Wl,--version-script=$(location :foo.lds)",
"-Wl,--script=$(location :additional_script.txt)",
],
"//conditions:default": []}),
...
)
|
win_def_file
|
이 속성은 Windows가 타겟 플랫폼인 경우에만 사용해야 합니다. 공유 라이브러리를 연결하는 동안 기호를 내보내는 데 사용할 수 있습니다. |
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_프로필
규칙 소스 보기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(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_테스트
규칙 소스 보기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
|
이 속성의 각 문자열은 바이너리 타겟을 컴파일하기 전에 지정된 순서로
패키지가 기능
|
defines
|
-D으로 시작되며 이 대상의 컴파일 명령줄뿐만 아니라 이를 사용하는 모든 규칙에 추가됩니다. 광범위한 영향을 미칠 수 있으므로 매우 주의해야 합니다. 확실하지 않으면 대신 정의 값을 local_defines에 추가하세요.
|
includes
|
'변수 만들기' 대체가 적용됩니다.
각 문자열 앞에 헤더는 src 또는 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 마이그레이션
이후 작동하지 않으며 #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옵션에 따라 도구 모음 1개 선택
정교한 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",
},
)
|