C / C++ 규칙

<ph type="x-smartling-placeholder"></ph> 문제 신고 소스 보기 를 참조하세요. 1박 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5 에 대해 자세히 알아보세요.

규칙

cc_binary

규칙 소스 보기 
cc_binary(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, dynamic_deps, env, exec_compatible_with, exec_properties, features, hdrs_check, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local_defines, malloc, module_interfaces, nocopts, output_licenses, reexport_deps, restricted_to, stamp, tags, target_compatible_with, testonly, toolchains, visibility, win_def_file)

실행 바이너리를 생성합니다.


타겟의 name은 애플리케이션의 기본 진입점인 소스 파일 (확장자 제외)입니다. 예를 들어 진입점이 main.cc에 있다면 이름이 main이어야 합니다.

암시적 출력 타겟

  • name.stripped (명시적으로 요청된 경우에만 빌드됨): A 제거됨 바이너리의 버전입니다 strip -g는 바이너리에서 실행되어 디버그를 삭제합니다. 기호로 구분되지 않습니다. 명령줄에서 --stripopt=-foo
  • name.dwp (명시적으로 요청된 경우에만 빌드됨): 분열이 사용 설정됨: 디버그 원격으로 배포된 바이너리를 디버깅하는 데 적합한 정보 패키지 파일입니다. 그 외: 빈 파일입니다.

인수

속성
name

이름 필수

이 대상의 고유한 이름입니다.
deps

라벨 목록 기본값은 []입니다.

바이너리 타겟에 연결할 다른 라이브러리의 목록입니다.

cc_library 또는 objc_library일 수 있습니다. 있습니다

또한 링커 스크립트 (.lds)를 deps에 넣고 linkopts를 입력합니다.
srcs

라벨 목록 기본값은 []입니다.

라이브러리 타겟을 생성하기 위해 처리되는 C 및 C++ 파일 목록입니다. 이 파일은 C/C++ 소스 및 헤더 파일로, 생성되지 않은 (일반 소스) 생성됩니다.

모든 .cc, .c, .cpp 파일이 실행됩니다. 컴파일해야 합니다 다음과 같은 파일이 생성될 수 있습니다. 이름이 지정된 파일이 다른 규칙의 outs, 이 cc_library 자동으로 다른 규칙에 종속됩니다.

순수 어셈블러 파일 (.s, .asm)은 전처리되지 않으며 일반적으로 어셈블러에 지시하는 것입니다. 전처리된 어셈블리 파일 (.S)은 전처리되고 일반적으로 C/C++ 컴파일러를 사용합니다.

.h 파일은 컴파일되지 않지만 다음에서 사용할 수 있습니다. 포함할 수 없습니다. .cc 및 .h 파일은 다음에 나열된 헤더를 직접 포함할 수 있습니다. 이 srcs 또는 이 규칙의 hdrs 또는 deps 인수에 나열된 규칙을 사용합니다.

모든 #included 파일은 이 항목 또는 참조된 cc_library의 hdrs 속성 비공개인 경우 srcs에 나열되어야 합니다. 이 라이브러리에 추가합니다. '헤더 포함 확인'에서 다음을 참고하세요. 더 자세한 설명이 있습니다.

.so, .lo, .a 파일은 다음과 같습니다. 사전 컴파일된 파일을 다운로드합니다. 라이브러리에는 다음과 같은 질문이 있을 수 있습니다. Google에서 제공하지 않는 서드 파티 코드를 사용하는 경우 srcs 소스 코드가 있어야 합니다

srcs 속성에 다른 규칙의 라벨이 포함된 경우 cc_library는 이 규칙의 출력 파일을 소스 파일로 사용하여 다음을 실행합니다. 합니다. 이는 소스 코드의 일회성 생성 (가끔 Starlark 규칙 클래스를 구현하고 cc_common API)

허용되는 srcs 파일 형식은 다음과 같습니다.

  • C 및 C++ 소스 파일: .c, .cc, .cpp .cxx님, .c++님, .C님
  • C 및 C++ 헤더 파일: .h, .hh, .hpp .hxx님, .inc님, .inl님, .H님
  • C 전처리기가 있는 어셈블러: .S
  • 보관처리: .a, .pic.a
  • '항상 링크' 라이브러리: .lo, .pic.lo
  • 버전이 지정되거나 버전이 지정되지 않은 공유 라이브러리: .so, .so.version
  • 객체 파일: .o, .pic.o

... 그리고 이러한 파일을 생성하는 모든 규칙 (예: cc_embed_data) 각 확장 프로그램은 사용할 수 있습니다.

data

라벨 목록 기본값은 []입니다.

런타임 시 이 라이브러리에서 필요로 하는 파일 목록입니다. data에 대한 일반적인 댓글 보기 at 대부분의 빌드 규칙에 대해 자세히 알아보세요.

data이 생성된 파일의 이름인 경우 cc_library 규칙은 생성 시에 있습니다.

data이 규칙 이름인 경우 cc_library 규칙은 이 규칙에 따라 자동으로 종속됩니다. 그리고 해당 규칙의 outs가 자동으로 이 cc_library의 데이터 파일입니다.

C++ 코드는 다음과 같이 이러한 데이터 파일에 액세스할 수 있습니다.


  const std::string path = devtools_build::GetDataDependencyFilepath(
      "my/test/data/file");
additional_linker_inputs

라벨 목록 기본값은 []입니다.

이러한 파일을 C++ 링커 명령어에 전달합니다.

예를 들어 컴파일된 Windows .res 파일을 여기에 제공하여 바이너리 타겟입니다.

copts

문자열 목록 기본값은 []입니다.

이러한 옵션을 C++ 컴파일 명령어에 추가합니다. 'Make 변수' 대체 적용 Bourne 셸 토큰화.

이 속성의 각 문자열은 주어진 순서로 COPTS에 추가됩니다. 바이너리 타겟을 컴파일하는 것입니다 플래그는 이 타겟을 컴파일하는 경우에만 적용되며 종속 항목이므로 다른 곳에 포함된 헤더 파일에 주의하세요. 모든 경로는 현재 패키지가 아닌 작업공간을 기준으로 해야 합니다. 이 속성은 third_party 외부에서는 필요하지 않습니다.

패키지가 feature를 선언하는 경우 no_copts_tokenization, Bourne 셸 토큰화는 문자열에만 적용됨 단일 'Make'로 구성된 변수의 값을 반환합니다.

defines

문자열 목록 기본값은 []입니다.

컴파일 줄에 추가할 정의 목록입니다. 'Make' 적용 변수 대체 및 Bourne 셸 토큰화. 각 문자열은 단일 Bourne 셸 토큰으로 구성되어야 합니다. 앞에 -D가 추가되고 이 타겟의 컴파일 명령줄에 추가됩니다. 여기에 종속된 모든 규칙에 적용됩니다. 이로 인해 광범위하고 강력한 효과를 낼 수 있습니다. 확실하지 않은 경우 정의 값을 대신 local_defines를 사용하세요.
dynamic_deps

라벨 목록 기본값은 []입니다.

다음은 현재 타겟이 사용하는 다른 cc_shared_library 종속 항목입니다.

cc_shared_library 구현은 dynamic_deps (전이적, 즉 dynamic_deps 현재 타겟의 dynamic_deps)를 사용하여 다음 타겟의 cc_libraries를 결정합니다. 임시 deps은(는) 이미 제공되었으므로 연결해서는 안 됩니다. 다른 cc_shared_library에서 제공한 결과입니다.

hdrs_check

String; 기본값은 ""입니다.

지원 중단됨, 노옵스(no-ops)
includes

문자열 목록 기본값은 []입니다.

컴파일 줄에 추가할 include dir의 목록입니다. 'Make 변수' 대체 적용 각 문자열은 패키지 경로가 앞에 추가되고 'include_paths'를 통한 확장 CROSSTOOL 기능입니다. POSIX 시스템에서 실행되는 도구 모음 일반적인 특성 정의를 사용하면 -isystem path_to_package/include_entry 이 방법은 코드가 포함된 서드 파티 라이브러리에만 Google의 #include 구문 작성 스타일을 따르지 않습니다. COPTS와 달리 이러한 플래그는 이 규칙에 추가됩니다. 그것에 의존하는 모든 규칙이 있습니다. (참고: 적용 대상 규칙이 아님) CANNOT TRANSLATE 매우 신중해야 합니다. 왜냐하면 광범위한 영향을 미칠 수 있기 때문입니다. 확실하지 않은 경우 다음을 추가하세요. '-I' 대신 플래그를 COPTS로 변경합니다.

추가된 include 경로에는 생성된 파일뿐 아니라 소스 트리에 있습니다.

라벨 기본값은 "@bazel_tools//tools/cpp:link_extra_lib"입니다.

추가 라이브러리의 연결을 제어합니다.

기본적으로 C++ 바이너리는 //tools/cpp:link_extra_lib에 링크됩니다. 이는 기본적으로 //tools/cpp:link_extra_libs 라벨 플래그에 종속됩니다. 플래그를 설정하지 않으면 이 라이브러리는 기본적으로 비어 있습니다. 라벨 플래그 설정 약한 기호, 인터셉터 재정의 등 선택적 종속 항목의 연결을 허용함 공유 라이브러리 함수 또는 특수 런타임 라이브러리 (malloc 대체의 경우 malloc 또는 --custom_malloc 선호). 이 속성을 None는 이 동작을 사용 중지합니다.

linkopts

문자열 목록 기본값은 []입니다.

다음 플래그를 C++ 링커 명령어에 추가합니다. 'Make' 적용 변수 대체를 사용하면 <ph type="x-smartling-placeholder"></ph> Bourne 셸 토큰화 및 라벨 확장입니다. 이 속성의 각 문자열은 LINKOPTS에 추가됩니다. 바이너리 타겟을 연결하는 것입니다.

이 목록에서 $ 또는 -로 시작하지 않는 각 요소는 deps에 있는 대상의 라벨로 가정됩니다. 이 해당 타겟에 의해 생성된 파일 목록이 링커에 추가됨 있습니다. 라벨이 잘못되었거나 deps에 선언되지 않음

linkshared

부울; 기본값은 False입니다.

공유 라이브러리를 만듭니다. 이 속성을 사용 설정하려면 규칙에 linkshared=True를 포함하세요. 기본적으로 이 옵션은 사용 중지되어 있습니다.

이 플래그가 있으면 -shared 플래그와 함께 연결됩니다. gcc에 로드되고, 그 결과로 생성되는 공유 라이브러리는 Java 프로그램을 예로 들 수 있습니다 하지만 빌드 목적으로는 특정 바이너리를 사용하여 빌드된 공유 라이브러리가 cc_binary 규칙은 다른 프로그램에 의해서만 수동으로 로드되므로, cc_library를 대체할 수 없음 있습니다. 확장성을 위해서는 이 접근 방식을 완전히 피하는 것이 좋습니다. java_library가 cc_library 규칙에 의지하도록 함 하세요.

linkopts=['-static']와 linkshared=True를 모두 지정하는 경우 완전히 독립된 단일 유닛을 갖게 됩니다. 두 속성을 모두 지정하면 linkstatic=True 및 linkshared=True의 경우 대부분 단일 독립 실행형 유닛입니다.

linkstatic

부울; 기본값은 True입니다.

cc_binary 및 cc_test: 정적으로 바이너리를 연결합니다. 있습니다. cc_library.link_static의 경우 아래를 참고하세요.

기본적으로 이 옵션은 cc_binary에는 사용 설정되어 있고 나머지 기기에는 사용 중지되어 있습니다.

이 옵션을 사용 설정하고 바이너리 또는 테스트인 경우 이 옵션을 사용하면 빌드 도구에 .so 대신 .a를 사용합니다. libc와 같은 시스템 라이브러리 (C/C++ 런타임 라이브러리는 아님), 아래 참조)를 위한 라이브러리처럼 여전히 동적으로 연결됩니다. 정적 라이브러리가 없습니다. 따라서 결과 실행 파일은 여전히 동적으로 대부분 정적인 것입니다.

실행 파일을 연결하는 방법에는 세 가지가 있습니다.

  • 전체 정적 링크 기능이 있는 STATIC(모든 항목이 정적으로 링크됨) 예: 'gcc -static foo.o libbar.a libbaz.a -lm'.
    이 모드는 다음에서 fully_static_link를 지정하여 사용 설정됩니다. features 속성으로 이동합니다.
  • STATIC: 모든 사용자 라이브러리가 정적으로 링크됩니다 (정적 버전 사용 가능), 시스템 라이브러리 (C/C++ 런타임 라이브러리 제외) 동적으로 연결됩니다. 예: 'gcc foo.o libfoo.a libbaz.a -lm'.
    이 모드는 linkstatic=True를 지정하면 사용 설정됩니다.
  • DYNAMIC(모든 라이브러리가 동적으로 링크됨)(동적 버전이 사용 가능). 예: 'gcc foo.o libfoo.so libbaz.so -lm'.
    이 모드는 linkstatic=False를 지정하면 사용 설정됩니다.

linkstatic 속성 또는 fully_static_link features는 //third_party 외부에서 사용됩니다. 규칙 근처에 이유를 설명하는 문구를 넣어 주세요.

linkstatic 속성은 cc_library() 규칙 C++ 라이브러리의 경우 linkstatic=True은 정적 연결이 허용되므로 .so가 생성되지 않습니다. linkstatic=False가 수행하는 작업 정적 라이브러리 생성을 막지 않습니다. 이 속성은 동적 라이브러리를 생성할 수 있습니다.

프로덕션에서는 linkstatic=False로 빌드된 코드가 거의 없습니다. linkstatic=False이면 빌드 도구가 *.runfiles 영역에서 종속된 공유 라이브러리에 종속된 라이브러리를 표시합니다.

local_defines

문자열 목록 기본값은 []입니다.

컴파일 줄에 추가할 정의 목록입니다. 'Make' 적용 변수 대체 및 Bourne 셸 토큰화. 각 문자열은 단일 Bourne 셸 토큰으로 구성되어야 합니다. 앞에 -D이 추가되고 이 타겟의 컴파일 명령줄에 추가됩니다. 종속 항목은 받지 않습니다.
malloc

라벨 기본값은 "@bazel_tools//tools/cpp:malloc"입니다.

malloc의 기본 종속 항목을 재정의합니다.

기본적으로 C++ 바이너리는 //tools/cpp:malloc에 링크됩니다. 이는 빈 라이브러리이므로 바이너리는 libc malloc을 사용하게 됩니다. 이 라벨은 cc_library을 참조해야 합니다. 컴파일이 C++ 이외의 용도인 경우 이 옵션은 아무런 영향을 미치지 않습니다. 이 속성의 값은 linkshared=True를 지정한 경우

module_interfaces

라벨 목록 기본값은 []입니다.

파일 목록은 C++20 모듈 인터페이스로 간주됩니다.

C++ 표준에는 모듈 인터페이스 파일 확장자에 관한 제한이 없습니다.

  • Clang에서 cppm 사용
  • GCC는 모든 소스 파일 확장자를 사용할 수 있음
  • MSVC 사용 ixx

플래그에 의해 사용이 보호됩니다. --experimental_cpp_modules
nocopts

String; 기본값은 ""입니다.

C++ 컴파일 명령어에서 일치 옵션을 삭제합니다. 'Make' 적용 변수 대체를 지원합니다. 이 속성의 값은 정규 표현식으로 해석됩니다. 이 정규 표현식과 일치하는 기존 COPTS (규칙의 copts 속성에 명시적으로 지정된 값 포함) 이 규칙을 컴파일하기 위해 COPTS에서 삭제됩니다. 이 속성은 필요하지 않거나 사용할 수 없습니다. third_party 외부 값이 전처리되지 않음 어떤 방식으로든 'Make'(만들기) 변수 대체를 참조하세요.
reexport_deps

라벨 목록 기본값은 []입니다.
stamp

정수; 기본값은 -1입니다.

빌드 정보를 바이너리로 인코딩할지 여부입니다. 가능한 값은 다음과 같습니다.
  • stamp = 1: --nostamp 빌드 이 사용하지 않는 것이 좋습니다. 그러면 원격 캐싱이 중단될 가능성이 있기 때문입니다. 바이너리 및 여기에 종속된 모든 다운스트림 작업을 처리합니다.
  • stamp = 0: 빌드 정보를 항상 상수 값으로 바꿉니다. 이 빌드 결과 캐싱이 잘 되고
  • stamp = -1: 빌드 정보의 삽입은 --[no]stamp 플래그

스탬프 처리된 바이너리는 종속 항목이 변경되지 않는 한 다시 빌드되지 않습니다.
win_def_file

라벨 기본값은 None입니다.

링커에 전달할 Windows DEF 파일입니다.

이 속성은 Windows가 대상 플랫폼인 경우에만 사용해야 합니다. 내보내기 기호를 사용할 수 있습니다.

cc_import

규칙 소스 보기 
cc_import(name, deps, data, hdrs, alwayslink, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, includes, interface_library, linkopts, objects, pic_objects, pic_static_library, restricted_to, shared_library, static_library, system_provided, tags, target_compatible_with, testonly, toolchains, 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. 공유 라이브러리를 인터페이스 라이브러리와 연결

Unix의 경우: 


cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  # libmylib.ifso is an interface library for libmylib.so which will be passed to linker
  interface_library = "libmylib.ifso",
  # libmylib.so will be available for runtime
  shared_library = "libmylib.so",
)

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에 연결

Unix의 경우: 


cc_import(
  name = "mylib",
  hdrs = ["mylib.h"],
  interface_library = "libmylib.ifso", # Or we can also use libmylib.so as its own interface library
  # libmylib.so is provided by system environment, for example it can be found in LD_LIBRARY_PATH.
  # This indicates that Bazel is not responsible for making libmylib.so available.
  system_provided = 1,
)

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",
)

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",
)

나머지는 Unix와 Windows에서 동일합니다. 


# first will link to libmylib.a (or libmylib.lib)
cc_binary(
  name = "first",
  srcs = ["first.cc"],
  deps = [":mylib"],
  linkstatic = 1, # default value
)

# second will link to libmylib.so (or libmylib.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에 대한 일반적인 댓글 보기 at 대부분의 빌드 규칙에 대해 자세히 알아보세요.
hdrs

라벨 목록 기본값은 []입니다.

에 의해 게시된 헤더 파일의 목록 종속 규칙의 소스에 의해 직접 포함됩니다.

부울; 기본값은 False입니다.

1이면 이 C++에 (직접 또는 간접적으로) 종속되는 모든 바이너리 사전 컴파일된 라이브러리는 정적 라이브러리에 보관된 모든 객체 파일에서 링크됩니다. 바이너리에서 참조하는 기호가 일부 포함되어 있지 않더라도 말이죠. 이는 코드가 바이너리(예: 코드가 콜백을 수신하도록 등록되는 경우) 제공할 수 있습니다

항상 링크가 Windows의 VS 2017에서 작동하지 않는다면 알려진 문제, VS 2017을 최신 버전으로 업그레이드하세요.
includes

문자열 목록 기본값은 []입니다.

컴파일 줄에 추가할 include dir의 목록입니다. 'Make 변수' 대체 적용 각 문자열은 패키지 경로가 앞에 추가되고 'include_paths'를 통한 확장 CROSSTOOL 기능입니다. POSIX 시스템에서 실행되는 도구 모음 일반적인 특성 정의를 사용하면 -isystem path_to_package/include_entry 이 방법은 코드가 포함된 서드 파티 라이브러리에만 Google의 #include 구문 작성 스타일을 따르지 않습니다. COPTS와 달리 이러한 플래그는 이 규칙에 추가됩니다. 그것에 의존하는 모든 규칙이 있습니다. (참고: 적용 대상 규칙이 아님) CANNOT TRANSLATE 매우 신중해야 합니다. 왜냐하면 광범위한 영향을 미칠 수 있기 때문입니다. 확실하지 않은 경우 다음을 추가하세요. '-I' 대신 플래그를 COPTS로 변경합니다.

기본 include 경로에는 생성된 할 수 있습니다. 생성된 헤더를 #include해야 하는 경우 파일의 경우 srcs에 나열합니다.

interface_library

라벨 기본값은 None입니다.

공유 라이브러리 연결을 위한 단일 인터페이스 라이브러리.

허용되는 파일 형식은 다음과 같습니다. .ifso, .tbd, .lib, .so 또는 .dylib

linkopts

문자열 목록 기본값은 []입니다.

다음 플래그를 C++ 링커 명령어에 추가합니다. 'Make' 적용 변수 대체를 사용하면 <ph type="x-smartling-placeholder"></ph> Bourne 셸 토큰화 및 라벨 확장입니다. 이 속성의 각 문자열은 LINKOPTS에 추가됩니다. 바이너리 타겟을 연결하는 것입니다.

이 목록에서 $ 또는 -로 시작하지 않는 각 요소는 deps에 있는 대상의 라벨로 가정됩니다. 이 해당 타겟에 의해 생성된 파일 목록이 링커에 추가됨 있습니다. 라벨이 잘못되었거나 deps에 선언되지 않음

objects

라벨 목록 기본값은 []입니다.
pic_objects

라벨 목록 기본값은 []입니다.
pic_static_library

라벨 기본값은 None입니다.
shared_library

라벨 기본값은 None입니다.

사전 컴파일된 단일 공유 라이브러리 Bazel은 종속되는 바이너리를 생성합니다.

허용되는 파일 형식은 다음과 같습니다. .so, .dll 또는 .dylib

static_library

라벨 기본값은 None입니다.

사전 컴파일된 단일 정적 라이브러리

허용되는 파일 형식은 다음과 같습니다. .a, .pic.a 또는 .lib

system_provided

부울; 기본값은 False입니다.

1이면 런타임에 필요한 공유 라이브러리가 시스템에서 제공되었음을 나타냅니다. 포함 이 경우 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, hdrs_check, implementation_deps, include_prefix, includes, licenses, linkopts, linkstamp, linkstatic, local_defines, module_interfaces, restricted_to, strip_include_prefix, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, win_def_file)

C++로 컴파일된 라이브러리에는 cc_library()를 사용합니다. 결과는 .so, .lo, 또는 .a로 설정합니다.

개발자가 종속된 라이브러리 규칙의 출력인 cc_library 는 .a 파일입니다. 만약 alwayslink=True이면 .lo 파일이 나타납니다.

다음의 실제 출력 파일 이름은 libfoo.so입니다. 공유 라이브러리로 이동합니다. 여기서 foo는 규칙의 이름입니다. 이 다른 종류의 라이브러리는 .lo 및 .a로 끝납니다. 각각 1개의 값으로 사용합니다. 특정 공유 라이브러리 이름이 필요한 경우 예를 들어 Python 모듈을 정의하려면 genrule을 사용하여 라이브러리를 복사합니다. 원하는 이름으로 변경합니다.

헤더 포함 확인

빌드에 사용되는 모든 헤더 파일은 cc_* 규칙의 hdrs 또는 srcs입니다. 이는 시행되는 조치입니다.

cc_library 규칙의 경우 hdrs의 헤더는 공개 인터페이스이며 라이브러리의 hdrs 및 srcs에 있는 파일에서 자체뿐만 아니라 hdrs 및 srcs에 있는 파일에서도 추출됩니다. deps에 라이브러리를 나열하는 cc_* 규칙 중 하나입니다. 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.hbar.h
foo.ccfoo.h bar.h
bar.hbar-impl.h baz.h
bar-impl.hbar.h baz.h
bar.ccbar.h bar-impl.h baz.h
baz.hbaz-impl.h
baz-impl.hbaz.h
baz.ccbaz.h baz-impl.h

포함 확인 규칙은 직접 포함되지 않습니다. 위의 예에서 foo.cc는 bar.h를 포함하며, 여기에는 baz.h도 포함될 수 있고, baz-impl.h를 포함할 수 있습니다. 기술적으로 .cc 파일의 컴파일에는 모든 헤더가 전이적으로 포함될 수 있음 파일(hdrs 또는 srcs)에 전이적 deps 클로저의 모든 cc_library 포함 이 경우 컴파일러는 baz.h 및 baz-impl.h를 읽을 수 있습니다. foo.cc를 컴파일할 때. foo.cc는 컴파일되어서는 안 됨 #include "baz.h"를 포함해야 합니다. 이를 위해서는 허용되는 경우 baz를 deps에 추가해야 합니다. /foo

Bazel은 포함 검사 규칙을 적용하기 위해 도구 모음 지원에 의존합니다. layering_check 기능은 도구 모음에서 지원되어야 함 명시적으로 요청할 수 있으며, 예를 들어 --features=layering_check 명령줄 플래그 또는 features 매개변수 package 함수. 도구 모음 는 Unix 및 macOS에서 clang을 통해서만 이 기능을 지원합니다.

예


cc_library(
    name = "ast_inspector_lib",
    srcs = ["ast_inspector_lib.cc"],
    hdrs = ["ast_inspector_lib.h"],
    visibility = ["//visibility:public"],
    deps = ["//third_party/llvm/llvm/tools/clang:frontend"],
    # alwayslink as we want to be able to call things in this library at
    # debug time, even if they aren't used anywhere in the code.
    alwayslink = 1,
)

다음 예는 third_party/python2_4_3/BUILD 일부 코드는 dl 라이브러리를 사용하여 다른 동적 라이브러리)에 따라 규칙은 -ldl 링크 옵션을 지정하여 dl 라이브러리를 사용합니다. 


cc_library(
    name = "python2_4_3",
    linkopts = [
        "-ldl",
        "-lutil",
    ],
    deps = ["//third_party/expat"],
)

다음 예는 third_party/kde/BUILD에서 가져온 것입니다. 사전 빌드된 .so 파일은 저장소에 보관됩니다. 헤더 파일은 include라는 하위 디렉터리에 있습니다. 


cc_library(
    name = "kde",
    srcs = [
        "lib/libDCOP.so",
        "lib/libkdesu.so",
        "lib/libkhtml.so",
        "lib/libkparts.so",
        ...more .so files...,
    ],
    includes = ["include"],
    deps = ["//third_party/X11"],
)

다음 예는 third_party/gles/BUILD에서 가져온 것입니다. 서드 파티 코드에는 defines와 linkopts입니다. 


cc_library(
    name = "gles",
    srcs = [
        "GLES/egl.h",
        "GLES/gl.h",
        "ddx.c",
        "egl.c",
    ],
    defines = [
        "USE_FLOAT",
        "__GL_FLOAT",
        "__GL_COMMON",
    ],
    linkopts = ["-ldl"],  # uses dlopen(), dl library
    deps = [
        "es",
        "//third_party/X11",
    ],
)

인수

속성
name

이름 필수

이 대상의 고유한 이름입니다.
deps

라벨 목록 기본값은 []입니다.

라이브러리 타겟이 의존하는 다른 라이브러리의 목록입니다.

cc_library 또는 objc_library 타겟일 수 있습니다.

deps에 대한 일반적인 댓글 보기 at 대부분의 빌드 규칙에 대해 자세히 알아보세요.

C++ 라이브러리 규칙의 이름이어야 합니다. 이 규칙의 라이브러리를 연결하는 바이너리를 빌드할 때 deps에서도 라이브러리를 연결합니다.

'deps' 이름, 이 라이브러리의 일부 클라이언트가 아님 여기 있습니다. 런타임 데이터 종속 항목은 data에 속합니다. 다른 규칙에 의해 생성된 소스 파일은 srcs에 속합니다.

사전 컴파일된 서드 파티 라이브러리에 연결하려면 해당 이름을 srcs를 대신 사용하세요.

이 라이브러리에 연결하지 않고 무언가에 의존하려면 이름을 data로 대체하세요.

srcs

라벨 목록 기본값은 []입니다.

라이브러리 타겟을 생성하기 위해 처리되는 C 및 C++ 파일 목록입니다. 이 파일은 C/C++ 소스 및 헤더 파일로, 생성되지 않은 (일반 소스) 생성됩니다.

모든 .cc, .c, .cpp 파일이 실행됩니다. 컴파일해야 합니다 다음과 같은 파일이 생성될 수 있습니다. 이름이 지정된 파일이 다른 규칙의 outs, 이 cc_library 자동으로 다른 규칙에 종속됩니다.

순수 어셈블러 파일 (.s, .asm)은 전처리되지 않으며 일반적으로 어셈블러에 지시하는 것입니다. 전처리된 어셈블리 파일 (.S)은 전처리되고 일반적으로 C/C++ 컴파일러를 사용합니다.

.h 파일은 컴파일되지 않지만 다음에서 사용할 수 있습니다. 포함할 수 없습니다. .cc 및 .h 파일은 다음에 나열된 헤더를 직접 포함할 수 있습니다. 이 srcs 또는 이 규칙의 hdrs 또는 deps 인수에 나열된 규칙을 사용합니다.

모든 #included 파일은 이 항목 또는 참조된 cc_library의 hdrs 속성 비공개인 경우 srcs에 나열되어야 합니다. 이 라이브러리에 추가합니다. '헤더 포함 확인'에서 다음을 참고하세요. 더 자세한 설명이 있습니다.

.so, .lo, .a 파일은 다음과 같습니다. 사전 컴파일된 파일을 다운로드합니다. 라이브러리에는 다음과 같은 질문이 있을 수 있습니다. Google에서 제공하지 않는 서드 파티 코드를 사용하는 경우 srcs 소스 코드가 있어야 합니다

srcs 속성에 다른 규칙의 라벨이 포함된 경우 cc_library는 이 규칙의 출력 파일을 소스 파일로 사용하여 다음을 실행합니다. 합니다. 이는 소스 코드의 일회성 생성 (가끔 Starlark 규칙 클래스를 구현하고 cc_common API)

허용되는 srcs 파일 형식은 다음과 같습니다.

  • C 및 C++ 소스 파일: .c, .cc, .cpp .cxx님, .c++님, .C님
  • C 및 C++ 헤더 파일: .h, .hh, .hpp .hxx님, .inc님, .inl님, .H님
  • C 전처리기가 있는 어셈블러: .S
  • 보관처리: .a, .pic.a
  • '항상 링크' 라이브러리: .lo, .pic.lo
  • 버전이 지정되거나 버전이 지정되지 않은 공유 라이브러리: .so, .so.version
  • 객체 파일: .o, .pic.o

... 그리고 이러한 파일을 생성하는 모든 규칙 (예: cc_embed_data) 각 확장 프로그램은 사용할 수 있습니다.

data

라벨 목록 기본값은 []입니다.

런타임 시 이 라이브러리에서 필요로 하는 파일 목록입니다. data에 대한 일반적인 댓글 보기 at 대부분의 빌드 규칙에 대해 자세히 알아보세요.

data이 생성된 파일의 이름인 경우 cc_library 규칙은 생성 시에 있습니다.

data이 규칙 이름인 경우 cc_library 규칙은 이 규칙에 따라 자동으로 종속됩니다. 그리고 해당 규칙의 outs가 자동으로 이 cc_library의 데이터 파일입니다.

C++ 코드는 다음과 같이 이러한 데이터 파일에 액세스할 수 있습니다.


  const std::string path = devtools_build::GetDataDependencyFilepath(
      "my/test/data/file");
hdrs

라벨 목록 기본값은 []입니다.

에 의해 게시된 헤더 파일의 목록 종속 규칙의 소스에서 직접 포함할 수 있습니다.

이 위치는 헤더 파일을 선언하는 데 적극 권장되는 위치입니다. 라이브러리에 대한 인터페이스를 설명합니다. 이 헤더는 이 규칙 또는 종속 규칙에 소스별로 포함할 수 있습니다. 이 라이브러리의 클라이언트에 의해 포함되지 않아야 하는 헤더는 srcs 속성에 나열됩니다. 포함된다는 사실을 기억하세요 '헤더 포함 확인에서 자세한 설명을 확인하세요.

허용되는 headers 파일 형식은 다음과 같습니다. .h, .hh, .hpp, .hxx입니다.

additional_compiler_inputs

라벨 목록 기본값은 []입니다.

컴파일러 명령줄에 전달하려는 추가 파일(예: 새니타이저) 무시 목록을 예로 들 수 있습니다 그런 다음 여기에 지정된 파일은 $(location) 함수를 사용하세요.
additional_linker_inputs

라벨 목록 기본값은 []입니다.

이러한 파일을 C++ 링커 명령어에 전달합니다.

예를 들어 컴파일된 Windows .res 파일을 여기에 제공하여 바이너리 타겟입니다.

부울; 기본값은 False입니다.

1이면 이 C++에 (직접 또는 간접적으로) 종속되는 모든 바이너리 라이브러리는 목록에 있는 파일에 대한 모든 객체 파일에서 srcs: 바이너리에서 참조하는 기호가 일부 포함되어 있지 않은 경우에도 마찬가지입니다. 이는 코드가 바이너리(예: 코드가 콜백을 수신하도록 등록되는 경우) 제공할 수 있습니다

항상 링크가 Windows의 VS 2017에서 작동하지 않는다면 알려진 문제, VS 2017을 최신 버전으로 업그레이드하세요.
copts

문자열 목록 기본값은 []입니다.

이러한 옵션을 C++ 컴파일 명령어에 추가합니다. 'Make 변수' 대체 적용 Bourne 셸 토큰화.

이 속성의 각 문자열은 주어진 순서로 COPTS에 추가됩니다. 바이너리 타겟을 컴파일하는 것입니다 플래그는 이 타겟을 컴파일하는 경우에만 적용되며 종속 항목이므로 다른 곳에 포함된 헤더 파일에 주의하세요. 모든 경로는 현재 패키지가 아닌 작업공간을 기준으로 해야 합니다. 이 속성은 third_party 외부에서는 필요하지 않습니다.

패키지가 feature를 선언하는 경우 no_copts_tokenization, Bourne 셸 토큰화는 문자열에만 적용됨 단일 'Make'로 구성된 변수의 값을 반환합니다.

defines

문자열 목록 기본값은 []입니다.

컴파일 줄에 추가할 정의 목록입니다. 'Make' 적용 변수 대체 및 Bourne 셸 토큰화. 각 문자열은 단일 Bourne 셸 토큰으로 구성되어야 합니다. 앞에 -D가 추가되고 이 타겟의 컴파일 명령줄에 추가됩니다. 여기에 종속된 모든 규칙에 적용됩니다. 이로 인해 광범위하고 강력한 효과를 낼 수 있습니다. 확실하지 않은 경우 정의 값을 대신 local_defines를 사용하세요.
hdrs_check

String; 기본값은 ""입니다.

지원 중단됨, 노옵스(no-ops)
implementation_deps

라벨 목록 기본값은 []입니다.

라이브러리 타겟이 의존하는 다른 라이브러리의 목록입니다. 좋아요 취소 deps - 이러한 라이브러리 (및 모든 라이브러리)의 헤더와 포함 경로 전이 deps)는 이 라이브러리의 컴파일에만 사용되며, 있습니다. implementation_deps로 지정된 라이브러리가 아직 연결되어 있음 바이너리 타겟을 생성합니다.

현재 사용은 cc_library로 제한되며 플래그로 보호됩니다. --experimental_cc_implementation_deps
include_prefix

String; 기본값은 ""입니다.

이 규칙의 헤더 경로에 추가할 프리픽스입니다.

설정하면 이 규칙의 hdrs 속성에 있는 헤더에 액세스할 수 있습니다. at은 저장소 기준 경로 앞에 추가된 이 속성의 값입니다.

strip_include_prefix 속성의 접두사는 이 속성을 사용하기 전에 삭제됩니다. 가 추가됩니다.

이 속성은 third_party 경우에만 유효합니다.

includes

문자열 목록 기본값은 []입니다.

컴파일 줄에 추가할 include dir의 목록입니다. 'Make 변수' 대체 적용 각 문자열은 패키지 경로가 앞에 추가되고 'include_paths'를 통한 확장 CROSSTOOL 기능입니다. POSIX 시스템에서 실행되는 도구 모음 일반적인 특성 정의를 사용하면 -isystem path_to_package/include_entry 이 방법은 코드가 포함된 서드 파티 라이브러리에만 Google의 #include 구문 작성 스타일을 따르지 않습니다. COPTS와 달리 이러한 플래그는 이 규칙에 추가됩니다. 그것에 의존하는 모든 규칙이 있습니다. (참고: 적용 대상 규칙이 아님) CANNOT TRANSLATE 매우 신중해야 합니다. 왜냐하면 광범위한 영향을 미칠 수 있기 때문입니다. 확실하지 않은 경우 다음을 추가하세요. '-I' 대신 플래그를 COPTS로 변경합니다.

추가된 include 경로에는 생성된 파일뿐 아니라 소스 트리에 있습니다.

linkopts

문자열 목록 기본값은 []입니다.

cc_binary.linkopts을 참고하세요. linkopts 속성은 deps를 통해 이 라이브러리에 직간접적으로 종속됨 속성 (또는 유사하게 취급되는 다른 속성을 통해) malloc 속성(cc_binary)으로 변경합니다. 종속 항목 linkopt는 종속 linkopt보다 우선합니다 (예: 종속 linkopts). 명령줄 후반부에 표시됨). Linkopt가 지정된 위치 --linkopt 규칙 linkopt보다 우선 적용됩니다

linkopts 속성은 .so 파일 또는 실행 파일을 만들 때 .a 또는 .lo 파일을 만들 때 따라서 linkstatic=True 속성이 설정되어 있으면 linkopts 속성은 이 라이브러리에 종속된 다른 타겟에만 적용됩니다.

또한 '-Wl,-soname'은 또는 '-Xlinker -soname' 옵션은 지원되지 않으며 이 속성에 지정해서는 안 됩니다.

cc_library에서 생성한 .so 파일 규칙이 종속된 라이브러리와 연결되지 않음 을 탭합니다. 사용할 공유 라이브러리를 만들려는 경우 기본 저장소 외부에 있습니다(예: 수동 사용 dlopen() 또는 LD_PRELOAD 사용 cc_binary 규칙을 사용하는 것이 더 나을 수 있습니다. linkshared=True 속성이 포함되어 있습니다. cc_binary.linkshared를 참조하세요.

linkstamp

라벨 기본값은 None입니다.

지정된 C++ 소스 파일을 동시에 컴파일하고 바이너리입니다. 이 속임수는 타임스탬프를 도입하기 위해 필요합니다 바이너리로 변환합니다 소스 파일을 객체 파일을 평소처럼 사용하면 타임스탬프가 올바르지 않게 됩니다. 링크 스탬프 컴파일에는 특정 스크립트 세트를 포함할 수 없습니다. 따라서 특정 플래그에 종속되어서는 안 되므로 또는 기타 빌드 변수를 설정할 수 있습니다. 이 옵션은 base 패키지.
linkstatic

부울; 기본값은 False입니다.

cc_binary 및 cc_test: 정적으로 바이너리를 연결합니다. 있습니다. cc_library.link_static의 경우 아래를 참고하세요.

기본적으로 이 옵션은 cc_binary에는 사용 설정되어 있고 나머지 기기에는 사용 중지되어 있습니다.

이 옵션을 사용 설정하고 바이너리 또는 테스트인 경우 이 옵션을 사용하면 빌드 도구에 .so 대신 .a를 사용합니다. libc와 같은 시스템 라이브러리 (C/C++ 런타임 라이브러리는 아님), 아래 참조)를 위한 라이브러리처럼 여전히 동적으로 연결됩니다. 정적 라이브러리가 없습니다. 따라서 결과 실행 파일은 여전히 동적으로 대부분 정적인 것입니다.

실행 파일을 연결하는 방법에는 세 가지가 있습니다.

  • 전체 정적 링크 기능이 있는 STATIC(모든 항목이 정적으로 링크됨) 예: 'gcc -static foo.o libbar.a libbaz.a -lm'.
    이 모드는 다음에서 fully_static_link를 지정하여 사용 설정됩니다. features 속성으로 이동합니다.
  • STATIC: 모든 사용자 라이브러리가 정적으로 링크됩니다 (정적 버전 사용 가능), 시스템 라이브러리 (C/C++ 런타임 라이브러리 제외) 동적으로 연결됩니다. 예: 'gcc foo.o libfoo.a libbaz.a -lm'.
    이 모드는 linkstatic=True를 지정하면 사용 설정됩니다.
  • DYNAMIC(모든 라이브러리가 동적으로 링크됨)(동적 버전이 사용 가능). 예: 'gcc foo.o libfoo.so libbaz.so -lm'.
    이 모드는 linkstatic=False를 지정하면 사용 설정됩니다.

linkstatic 속성 또는 fully_static_link features는 //third_party 외부에서 사용됩니다. 규칙 근처에 이유를 설명하는 문구를 넣어 주세요.

linkstatic 속성은 cc_library() 규칙 C++ 라이브러리의 경우 linkstatic=True은 정적 연결이 허용되므로 .so가 생성되지 않습니다. linkstatic=False가 수행하는 작업 정적 라이브러리 생성을 막지 않습니다. 이 속성은 동적 라이브러리를 생성할 수 있습니다.

프로덕션에서는 linkstatic=False로 빌드된 코드가 거의 없습니다. linkstatic=False이면 빌드 도구가 *.runfiles 영역에서 종속된 공유 라이브러리에 종속된 라이브러리를 표시합니다.

local_defines

문자열 목록 기본값은 []입니다.

컴파일 줄에 추가할 정의 목록입니다. 'Make' 적용 변수 대체 및 Bourne 셸 토큰화. 각 문자열은 단일 Bourne 셸 토큰으로 구성되어야 합니다. 앞에 -D이 추가되고 이 타겟의 컴파일 명령줄에 추가됩니다. 종속 항목은 받지 않습니다.
module_interfaces

라벨 목록 기본값은 []입니다.

파일 목록은 C++20 모듈 인터페이스로 간주됩니다.

C++ 표준에는 모듈 인터페이스 파일 확장자에 관한 제한이 없습니다.

  • Clang에서 cppm 사용
  • GCC는 모든 소스 파일 확장자를 사용할 수 있음
  • MSVC 사용 ixx

플래그에 의해 사용이 보호됩니다. --experimental_cpp_modules
strip_include_prefix

String; 기본값은 ""입니다.

이 규칙의 헤더 경로에서 제거할 프리픽스입니다.

설정하면 이 규칙의 hdrs 속성에 있는 헤더에 액세스할 수 있습니다. 해당 경로에서 이 접두사를 잘라냅니다.

상대 경로인 경우 패키지에 상대적인 경로로 간주됩니다. 절댓값인 경우 저장소 기준 경로로 이해됩니다.

include_prefix 속성의 접두사는 이 접두사가 합니다.

이 속성은 third_party 경우에만 유효합니다.

textual_hdrs

라벨 목록 기본값은 []입니다.

에 의해 게시된 헤더 파일의 목록 이 라이브러리를 종속 규칙의 소스에서 텍스트 형식으로 포함합니다.

자체적으로 컴파일할 수 없는 헤더 파일을 선언하는 위치입니다. 즉, 유효한 HTML 파일을 빌드하려면 항상 다른 소스 파일에 의해 있습니다.
win_def_file

라벨 기본값은 None입니다.

링커에 전달할 Windows DEF 파일입니다.

이 속성은 Windows가 대상 플랫폼인 경우에만 사용해야 합니다. 내보내기 기호를 사용할 수 있습니다.

cc_proto_library

규칙 소스 보기 
cc_proto_library(name, deps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, restricted_to, tags, target_compatible_with, testonly, toolchains, 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 목록 C++ 코드를 생성할 수 있습니다.

cc_shared_library

규칙 소스 보기 
cc_shared_library(name, deps, additional_linker_inputs, compatible_with, deprecation, distribs, dynamic_deps, exec_compatible_with, exec_properties, experimental_disable_topo_sort_do_not_use_remove_before_7_0, exports_filter, features, restricted_to, roots, shared_lib_name, static_deps, tags, target_compatible_with, testonly, toolchains, user_link_flags, visibility, 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는 전이 종속 항목입니다. 그렇지 않습니다. 링크 bar을(를) 이미 동적으로 제공했기 때문입니다. dynamic_dep bar_shared.

foo_shared는 링커 스크립트 *.lds 파일을 사용하여 기호를 내보내야 합니다. cc_shared_library 규칙 로직은 내보낼 기호를 제어하지 않으며 두 개의 공유 라이브러리가 사용할 수 있습니다

cc_shared_library의 모든 직접 종속 항목은 내보냄. 따라서 Bazel은 분석 중에 foo가 foo_shared님이 내보냈습니다. baz 파일을 내보내는 것으로 가정되지 않음 작성자: foo_shared exports_filter과(와) 일치하는 모든 타겟 내보내는 것으로 간주됩니다.

예시의 모든 단일 cc_library는 cc_shared_library입니다. baz를 bar_shared 추가 필요 tags = ["LINKABLE_MORE_THAN_ONCE"]에서 baz(으)로

shared_lib_name 속성으로 인해 bar_shared의 이름은 bar.so가 됩니다. 를 Linux에서 기본적으로 갖는 이름 libbar.so로 변경합니다.

오류

Two shared libraries in dependencies export the same symbols.

두 개의 서로 다른 타겟으로 타겟을 만들 때마다 동일한 타겟을 내보내는 cc_shared_library 종속 항목 이 문제를 해결하려면 다음 단계를 따르세요. 이 경우 라이브러리 중 하나에서 라이브러리를 cc_shared_library 종속 항목

이 작업은 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 대상에 정적으로 연결됨 생성 중입니다. 따라서 deps cc_shared_library입니다. 사전 컴파일된 동적 라이브러리가 cc_libraries의 경우 cc_library가 그것에 의존해야 합니다. 바로 그것입니다.

Trying to export a library already exported by a different shared library

현재 규칙에서 타겟이 있어야 합니다.

이 문제를 해결하려면 deps에서 타겟을 삭제하고 동적 exports_filter가 이 타겟을 포착하지 않도록 해야 합니다.

인수

속성
name

이름 필수

이 대상의 고유한 이름입니다.
deps

라벨 목록 기본값은 []입니다.

공유 라이브러리에 무조건 정적으로 연결되는 최상위 라이브러리 .

이러한 직접 deps의 전이 라이브러리 종속 항목은 이 공유에 연결됩니다. 아직 cc_shared_library에 의해 연결되지 않은 경우 (dynamic_deps)

분석 중에 규칙 구현에서는 deps를 공유 라이브러리에서 내보낸 것으로 간주하여 다음 경우에 오류를 발생시킵니다. 여러 cc_shared_libraries가 동일한 대상을 내보냅니다. 규칙 구현 는 공유할 수 있습니다. 사용자는 링커 스크립트 또는 가시성을 통해 이를 처리해야 합니다. 선언에 사용됩니다.

또한 구현은 동일한 라이브러리가 정적으로 연결될 때마다 오류를 트리거합니다. 둘 이상의 cc_shared_library로 전달할 수 있습니다. 이러한 문제는 cc_library.tags 또는 등록정보별로 "LINKABLE_MORE_THAN_ONCE" `cc_library` 를 공유 라이브러리 중 하나의 내보내기로 지정하여 나머지는 dynamic_dep입니다.

additional_linker_inputs

라벨 목록 기본값은 []입니다.

링커에 전달할 수 있는 추가 파일(예: 링커 스크립트) 링커가 인식하기 위해 필요한 모든 링커 플래그를 별도로 전달해야 합니다. 하겠습니다. user_link_flags 속성을 사용하면 됩니다.
dynamic_deps

라벨 목록 기본값은 []입니다.

다음은 현재 타겟이 사용하는 다른 cc_shared_library 종속 항목입니다.

cc_shared_library 구현은 dynamic_deps (전이적, 즉 dynamic_deps 현재 타겟의 dynamic_deps)를 사용하여 다음 타겟의 cc_libraries를 결정합니다. 임시 deps은(는) 이미 제공되었으므로 연결해서는 안 됩니다. 다른 cc_shared_library에서 제공한 결과입니다.

experimental_disable_topo_sort_do_not_use_remove_before_7_0

부울; 기본값은 False입니다.
exports_filter

문자열 목록 기본값은 []입니다.

이 속성에는 현재 공유할 수 있습니다.

모든 타겟 deps는 이미 공유 라이브러리에서 내보내는 것으로 이해됩니다. 이 속성은 공유 라이브러리에서 내보낸 대상을 나열하는 데 사용해야 합니다. deps의 전이 종속 항목입니다.

이 특성은 실제로 이러한 타겟에 종속 항목 에지를 추가하지 않으며, 대신 deps에서 종속 항목 에지를 만들어야 합니다.이 항목의 항목은 단지 문자열입니다. 이 속성에 타겟을 배치할 때는 이는 공유 라이브러리가 해당 타겟에서 기호를 내보내기한다는 주장으로 간주됩니다. cc_shared_library 로직은 실제로 링커에 어떤 작업을 처리할지 기호를 내보내야 합니다.

다음 구문이 허용됩니다.

//foo:__package__: foo/BUILD의 대상을 고려합니다.

foo/BUILD 또는 기타의 대상을 설명하는 //foo:__subpackages__ foo/bar/BUILD와 같은 foo 아래 패키지
roots

라벨 목록 기본값은 []입니다.
shared_lib_name

String; 기본값은 ""입니다.

기본적으로 cc_shared_library는 플랫폼을 정의합니다 여기에는 확장자와 때로는 접두사가 포함됩니다. 기본 이름을 사용하고 싶지 않은 경우도 있습니다(예: C++ 공유 라이브러리를 로드할 때). Python의 경우 기본 lib* 접두사를 사용하지 않는 경우가 많으므로 속성을 사용하여 맞춤 이름을 선택합니다.
static_deps

문자열 목록 기본값은 []입니다.

문자열 목록 기본값은 []입니다.

링커에 전달할 수 있는 추가 플래그. 예를 들어 additional_linker_inputs를 통해 전달된 링커 스크립트를 인식하는 링커가 있다면 있습니다. 

 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

라벨 기본값은 None입니다.

링커에 전달할 Windows DEF 파일입니다.

이 속성은 Windows가 대상 플랫폼인 경우에만 사용해야 합니다. 내보내기 기호를 사용할 수 있습니다.

cc_static_library

규칙 소스 보기 
cc_static_library(name, deps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
타겟 및 전이 종속 항목의 목록에서 정적 라이브러리를 생성합니다.

결과 정적 라이브러리에는 deps 및 전이 종속 항목(다음에 선호됨) PIC 객체.

출력 그룹

linkdeps

아래 나열된 대상의 전이 종속성 라벨이 포함된 텍스트 파일 deps: 정적 라이브러리에 어떠한 객체 파일도 제공하지 않았지만 정적, 동적 또는 인터페이스 라이브러리를 하나 이상 제공해야 합니다. 결과 정적 라이브러리 연결 시 이러한 라이브러리를 사용해야 할 수 있습니다.

linkopts

사용자가 제공한 모든 전이적 linkopts가 포함된 텍스트 파일 deps에 나열된 대상의 종속 항목을 반환합니다.

중복된 기호

기본적으로 cc_static_library 규칙은 결과 static 라이브러리에 중복 기호가 포함되어 있지 않습니다. 충돌하면 오류와 함께 빌드가 실패합니다. 메시지를 반환합니다.

이 검사는 다음 설정으로 대상 또는 패키지별로 사용 중지할 수 있습니다. features = ["-symbol_check"] 또는 다음을 통해 전역 --features=-symbol_check입니다.

symbol_check의 도구 모음 지원

Bazel과 함께 제공되는 자동 구성 C++ 도구 모음은 symbol_check 기능을 지원합니다. 커스텀 도구 모음은 다음 두 가지 방법 중 하나를 통해 사용할 수 있습니다.

  • ACTION_NAMES.validate_static_library 작업 구현 및 symbol_check 기능으로 사용 설정합니다. 작업의 도구 세트는 두 개의 인수, 즉 중복 기호를 확인하는 정적 라이브러리 및 검사를 통과한 경우 생성되어야 하는 파일의 경로입니다.
  • symbol_check 기능을 사용하면 정적 라이브러리를 생성하는 작업이 중복 기호에서 실패하도록 합니다.

인수

속성
name

이름 필수

이 대상의 고유한 이름입니다.
deps

라벨 목록 기본값은 []입니다.

정적 라이브러리로 결합할 타겟의 목록(모든 전이적 포함 포함) 종속 항목이 포함됩니다

객체 파일을 제공하지 않는 종속 항목은 정적 라벨이 지정되지만 해당 라벨은 linkdeps 출력 그룹

cc_test

규칙 소스 보기 
cc_test(name, deps, srcs, data, additional_linker_inputs, args, compatible_with, copts, defines, deprecation, distribs, dynamic_deps, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, hdrs_check, includes, licenses, link_extra_lib, linkopts, linkshared, linkstatic, local, local_defines, malloc, module_interfaces, nocopts, reexport_deps, restricted_to, shard_count, size, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility, win_def_file)

cc_test() 규칙은 테스트를 컴파일합니다. 여기에서는 일부 테스트 코드의 바이너리 래퍼입니다.

기본적으로 C++ 테스트는 동적으로 링크됩니다.
단위 테스트를 정적으로 연결하려면 다음을 지정합니다. linkstatic=True 테스트가 필요한 이유를 설명하는 것이 좋습니다. linkstatic 분명하지 않을 것입니다.

암시적 출력 타겟

  • name.stripped (명시적으로 요청된 경우에만 빌드됨): A 제거됨 바이너리의 버전입니다 strip -g는 바이너리에서 실행되어 디버그를 삭제합니다. 기호로 구분되지 않습니다. 명령줄에서 --stripopt=-foo
  • name.dwp (명시적으로 요청된 경우에만 빌드됨): 분열이 사용 설정됨: 디버그 원격으로 배포된 바이너리를 디버깅하는 데 적합한 정보 패키지 파일입니다. 그 외: 빈 파일입니다.

다음을 제외하고 cc_binary() 인수를 참조하세요. 테스트의 경우 stamp 인수는 기본적으로 0으로 설정됩니다. cc_test의 추가 속성 (*_test)을 지정합니다.

인수

속성
name

이름 필수

이 대상의 고유한 이름입니다.
deps

라벨 목록 기본값은 []입니다.

바이너리 타겟에 연결할 다른 라이브러리의 목록입니다.

cc_library 또는 objc_library일 수 있습니다. 있습니다

또한 링커 스크립트 (.lds)를 deps에 넣고 linkopts를 입력합니다.
srcs

라벨 목록 기본값은 []입니다.

라이브러리 타겟을 생성하기 위해 처리되는 C 및 C++ 파일 목록입니다. 이 파일은 C/C++ 소스 및 헤더 파일로, 생성되지 않은 (일반 소스) 생성됩니다.

모든 .cc, .c, .cpp 파일이 실행됩니다. 컴파일해야 합니다 다음과 같은 파일이 생성될 수 있습니다. 이름이 지정된 파일이 다른 규칙의 outs, 이 cc_library 자동으로 다른 규칙에 종속됩니다.

순수 어셈블러 파일 (.s, .asm)은 전처리되지 않으며 일반적으로 어셈블러에 지시하는 것입니다. 전처리된 어셈블리 파일 (.S)은 전처리되고 일반적으로 C/C++ 컴파일러를 사용합니다.

.h 파일은 컴파일되지 않지만 다음에서 사용할 수 있습니다. 포함할 수 없습니다. .cc 및 .h 파일은 다음에 나열된 헤더를 직접 포함할 수 있습니다. 이 srcs 또는 이 규칙의 hdrs 또는 deps 인수에 나열된 규칙을 사용합니다.

모든 #included 파일은 이 항목 또는 참조된 cc_library의 hdrs 속성 비공개인 경우 srcs에 나열되어야 합니다. 이 라이브러리에 추가합니다. '헤더 포함 확인'에서 다음을 참고하세요. 더 자세한 설명이 있습니다.

.so, .lo, .a 파일은 다음과 같습니다. 사전 컴파일된 파일을 다운로드합니다. 라이브러리에는 다음과 같은 질문이 있을 수 있습니다. Google에서 제공하지 않는 서드 파티 코드를 사용하는 경우 srcs 소스 코드가 있어야 합니다

srcs 속성에 다른 규칙의 라벨이 포함된 경우 cc_library는 이 규칙의 출력 파일을 소스 파일로 사용하여 다음을 실행합니다. 합니다. 이는 소스 코드의 일회성 생성 (가끔 Starlark 규칙 클래스를 구현하고 cc_common API)

허용되는 srcs 파일 형식은 다음과 같습니다.

  • C 및 C++ 소스 파일: .c, .cc, .cpp .cxx님, .c++님, .C님
  • C 및 C++ 헤더 파일: .h, .hh, .hpp .hxx님, .inc님, .inl님, .H님
  • C 전처리기가 있는 어셈블러: .S
  • 보관처리: .a, .pic.a
  • '항상 링크' 라이브러리: .lo, .pic.lo
  • 버전이 지정되거나 버전이 지정되지 않은 공유 라이브러리: .so, .so.version
  • 객체 파일: .o, .pic.o

... 그리고 이러한 파일을 생성하는 모든 규칙 (예: cc_embed_data) 각 확장 프로그램은 사용할 수 있습니다.

data

라벨 목록 기본값은 []입니다.

런타임 시 이 라이브러리에서 필요로 하는 파일 목록입니다. data에 대한 일반적인 댓글 보기 at 대부분의 빌드 규칙에 대해 자세히 알아보세요.

data이 생성된 파일의 이름인 경우 cc_library 규칙은 생성 시에 있습니다.

data이 규칙 이름인 경우 cc_library 규칙은 이 규칙에 따라 자동으로 종속됩니다. 그리고 해당 규칙의 outs가 자동으로 이 cc_library의 데이터 파일입니다.

C++ 코드는 다음과 같이 이러한 데이터 파일에 액세스할 수 있습니다.


  const std::string path = devtools_build::GetDataDependencyFilepath(
      "my/test/data/file");
additional_linker_inputs

라벨 목록 기본값은 []입니다.

이러한 파일을 C++ 링커 명령어에 전달합니다.

예를 들어 컴파일된 Windows .res 파일을 여기에 제공하여 바이너리 타겟입니다.

copts

문자열 목록 기본값은 []입니다.

이러한 옵션을 C++ 컴파일 명령어에 추가합니다. 'Make 변수' 대체 적용 Bourne 셸 토큰화.

이 속성의 각 문자열은 주어진 순서로 COPTS에 추가됩니다. 바이너리 타겟을 컴파일하는 것입니다 플래그는 이 타겟을 컴파일하는 경우에만 적용되며 종속 항목이므로 다른 곳에 포함된 헤더 파일에 주의하세요. 모든 경로는 현재 패키지가 아닌 작업공간을 기준으로 해야 합니다. 이 속성은 third_party 외부에서는 필요하지 않습니다.

패키지가 feature를 선언하는 경우 no_copts_tokenization, Bourne 셸 토큰화는 문자열에만 적용됨 단일 'Make'로 구성된 변수의 값을 반환합니다.

defines

문자열 목록 기본값은 []입니다.

컴파일 줄에 추가할 정의 목록입니다. 'Make' 적용 변수 대체 및 Bourne 셸 토큰화. 각 문자열은 단일 Bourne 셸 토큰으로 구성되어야 합니다. 앞에 -D가 추가되고 이 타겟의 컴파일 명령줄에 추가됩니다. 여기에 종속된 모든 규칙에 적용됩니다. 이로 인해 광범위하고 강력한 효과를 낼 수 있습니다. 확실하지 않은 경우 정의 값을 대신 local_defines를 사용하세요.
dynamic_deps

라벨 목록 기본값은 []입니다.

다음은 현재 타겟이 사용하는 다른 cc_shared_library 종속 항목입니다.

cc_shared_library 구현은 dynamic_deps (전이적, 즉 dynamic_deps 현재 타겟의 dynamic_deps)를 사용하여 다음 타겟의 cc_libraries를 결정합니다. 임시 deps은(는) 이미 제공되었으므로 연결해서는 안 됩니다. 다른 cc_shared_library에서 제공한 결과입니다.

hdrs_check

String; 기본값은 ""입니다.

지원 중단됨, 노옵스(no-ops)
includes

문자열 목록 기본값은 []입니다.

컴파일 줄에 추가할 include dir의 목록입니다. 'Make 변수' 대체 적용 각 문자열은 패키지 경로가 앞에 추가되고 'include_paths'를 통한 확장 CROSSTOOL 기능입니다. POSIX 시스템에서 실행되는 도구 모음 일반적인 특성 정의를 사용하면 -isystem path_to_package/include_entry 이 방법은 코드가 포함된 서드 파티 라이브러리에만 Google의 #include 구문 작성 스타일을 따르지 않습니다. COPTS와 달리 이러한 플래그는 이 규칙에 추가됩니다. 그것에 의존하는 모든 규칙이 있습니다. (참고: 적용 대상 규칙이 아님) CANNOT TRANSLATE 매우 신중해야 합니다. 왜냐하면 광범위한 영향을 미칠 수 있기 때문입니다. 확실하지 않은 경우 다음을 추가하세요. '-I' 대신 플래그를 COPTS로 변경합니다.

추가된 include 경로에는 생성된 파일뿐 아니라 소스 트리에 있습니다.

라벨 기본값은 "@bazel_tools//tools/cpp:link_extra_lib"입니다.

추가 라이브러리의 연결을 제어합니다.

기본적으로 C++ 바이너리는 //tools/cpp:link_extra_lib에 링크됩니다. 이는 기본적으로 //tools/cpp:link_extra_libs 라벨 플래그에 종속됩니다. 플래그를 설정하지 않으면 이 라이브러리는 기본적으로 비어 있습니다. 라벨 플래그 설정 약한 기호, 인터셉터 재정의 등 선택적 종속 항목의 연결을 허용함 공유 라이브러리 함수 또는 특수 런타임 라이브러리 (malloc 대체의 경우 malloc 또는 --custom_malloc 선호). 이 속성을 None는 이 동작을 사용 중지합니다.

linkopts

문자열 목록 기본값은 []입니다.

다음 플래그를 C++ 링커 명령어에 추가합니다. 'Make' 적용 변수 대체를 사용하면 <ph type="x-smartling-placeholder"></ph> Bourne 셸 토큰화 및 라벨 확장입니다. 이 속성의 각 문자열은 LINKOPTS에 추가됩니다. 바이너리 타겟을 연결하는 것입니다.

이 목록에서 $ 또는 -로 시작하지 않는 각 요소는 deps에 있는 대상의 라벨로 가정됩니다. 이 해당 타겟에 의해 생성된 파일 목록이 링커에 추가됨 있습니다. 라벨이 잘못되었거나 deps에 선언되지 않음

linkshared

부울; 기본값은 False입니다.

공유 라이브러리를 만듭니다. 이 속성을 사용 설정하려면 규칙에 linkshared=True를 포함하세요. 기본적으로 이 옵션은 사용 중지되어 있습니다.

이 플래그가 있으면 -shared 플래그와 함께 연결됩니다. gcc에 로드되고, 그 결과로 생성되는 공유 라이브러리는 Java 프로그램을 예로 들 수 있습니다 하지만 빌드 목적으로는 특정 바이너리를 사용하여 빌드된 공유 라이브러리가 cc_binary 규칙은 다른 프로그램에 의해서만 수동으로 로드되므로, cc_library를 대체할 수 없음 있습니다. 확장성을 위해서는 이 접근 방식을 완전히 피하는 것이 좋습니다. java_library가 cc_library 규칙에 의지하도록 함 하세요.

linkopts=['-static']와 linkshared=True를 모두 지정하는 경우 완전히 독립된 단일 유닛을 갖게 됩니다. 두 속성을 모두 지정하면 linkstatic=True 및 linkshared=True의 경우 대부분 단일 독립 실행형 유닛입니다.

linkstatic

부울; 기본값은 False입니다.

cc_binary 및 cc_test: 정적으로 바이너리를 연결합니다. 있습니다. cc_library.link_static의 경우 아래를 참고하세요.

기본적으로 이 옵션은 cc_binary에는 사용 설정되어 있고 나머지 기기에는 사용 중지되어 있습니다.

이 옵션을 사용 설정하고 바이너리 또는 테스트인 경우 이 옵션을 사용하면 빌드 도구에 .so 대신 .a를 사용합니다. libc와 같은 시스템 라이브러리 (C/C++ 런타임 라이브러리는 아님), 아래 참조)를 위한 라이브러리처럼 여전히 동적으로 연결됩니다. 정적 라이브러리가 없습니다. 따라서 결과 실행 파일은 여전히 동적으로 대부분 정적인 것입니다.

실행 파일을 연결하는 방법에는 세 가지가 있습니다.

  • 전체 정적 링크 기능이 있는 STATIC(모든 항목이 정적으로 링크됨) 예: 'gcc -static foo.o libbar.a libbaz.a -lm'.
    이 모드는 다음에서 fully_static_link를 지정하여 사용 설정됩니다. features 속성으로 이동합니다.
  • STATIC: 모든 사용자 라이브러리가 정적으로 링크됩니다 (정적 버전 사용 가능), 시스템 라이브러리 (C/C++ 런타임 라이브러리 제외) 동적으로 연결됩니다. 예: 'gcc foo.o libfoo.a libbaz.a -lm'.
    이 모드는 linkstatic=True를 지정하면 사용 설정됩니다.
  • DYNAMIC(모든 라이브러리가 동적으로 링크됨)(동적 버전이 사용 가능). 예: 'gcc foo.o libfoo.so libbaz.so -lm'.
    이 모드는 linkstatic=False를 지정하면 사용 설정됩니다.

linkstatic 속성 또는 fully_static_link features는 //third_party 외부에서 사용됩니다. 규칙 근처에 이유를 설명하는 문구를 넣어 주세요.

linkstatic 속성은 cc_library() 규칙 C++ 라이브러리의 경우 linkstatic=True은 정적 연결이 허용되므로 .so가 생성되지 않습니다. linkstatic=False가 수행하는 작업 정적 라이브러리 생성을 막지 않습니다. 이 속성은 동적 라이브러리를 생성할 수 있습니다.

프로덕션에서는 linkstatic=False로 빌드된 코드가 거의 없습니다. linkstatic=False이면 빌드 도구가 *.runfiles 영역에서 종속된 공유 라이브러리에 종속된 라이브러리를 표시합니다.

local_defines

문자열 목록 기본값은 []입니다.

컴파일 줄에 추가할 정의 목록입니다. 'Make' 적용 변수 대체 및 Bourne 셸 토큰화. 각 문자열은 단일 Bourne 셸 토큰으로 구성되어야 합니다. 앞에 -D이 추가되고 이 타겟의 컴파일 명령줄에 추가됩니다. 종속 항목은 받지 않습니다.
malloc

라벨 기본값은 "@bazel_tools//tools/cpp:malloc"입니다.

malloc의 기본 종속 항목을 재정의합니다.

기본적으로 C++ 바이너리는 //tools/cpp:malloc에 링크됩니다. 이는 빈 라이브러리이므로 바이너리는 libc malloc을 사용하게 됩니다. 이 라벨은 cc_library을 참조해야 합니다. 컴파일이 C++ 이외의 용도인 경우 이 옵션은 아무런 영향을 미치지 않습니다. 이 속성의 값은 linkshared=True를 지정한 경우

module_interfaces

라벨 목록 기본값은 []입니다.

파일 목록은 C++20 모듈 인터페이스로 간주됩니다.

C++ 표준에는 모듈 인터페이스 파일 확장자에 관한 제한이 없습니다.

  • Clang에서 cppm 사용
  • GCC는 모든 소스 파일 확장자를 사용할 수 있음
  • MSVC 사용 ixx

플래그에 의해 사용이 보호됩니다. --experimental_cpp_modules
nocopts

String; 기본값은 ""입니다.

C++ 컴파일 명령어에서 일치 옵션을 삭제합니다. 'Make' 적용 변수 대체를 지원합니다. 이 속성의 값은 정규 표현식으로 해석됩니다. 이 정규 표현식과 일치하는 기존 COPTS (규칙의 copts 속성에 명시적으로 지정된 값 포함) 이 규칙을 컴파일하기 위해 COPTS에서 삭제됩니다. 이 속성은 필요하지 않거나 사용할 수 없습니다. third_party 외부 값이 전처리되지 않음 어떤 방식으로든 'Make'(만들기) 변수 대체를 참조하세요.
reexport_deps

라벨 목록 기본값은 []입니다.
stamp

정수; 기본값은 0입니다.

빌드 정보를 바이너리로 인코딩할지 여부입니다. 가능한 값은 다음과 같습니다.
  • stamp = 1: --nostamp 빌드 이 사용하지 않는 것이 좋습니다. 그러면 원격 캐싱이 중단될 가능성이 있기 때문입니다. 바이너리 및 여기에 종속된 모든 다운스트림 작업을 처리합니다.
  • stamp = 0: 빌드 정보를 항상 상수 값으로 바꿉니다. 이 빌드 결과 캐싱이 잘 되고
  • stamp = -1: 빌드 정보의 삽입은 --[no]stamp 플래그

스탬프 처리된 바이너리는 종속 항목이 변경되지 않는 한 다시 빌드되지 않습니다.
win_def_file

라벨 기본값은 None입니다.

링커에 전달할 Windows DEF 파일입니다.

이 속성은 Windows가 대상 플랫폼인 경우에만 사용해야 합니다. 내보내기 기호를 사용할 수 있습니다.

cc_toolchain

규칙 소스 보기 
cc_toolchain(name, all_files, ar_files, as_files, compatible_with, compiler_files, compiler_files_without_includes, coverage_files, deprecation, distribs, dwp_files, dynamic_runtime_lib, exec_compatible_with, exec_properties, exec_transition_for_inputs, features, libc_top, licenses, linker_files, module_map, objcopy_files, output_licenses, restricted_to, static_runtime_lib, strip_files, supports_header_parsing, supports_param_files, tags, target_compatible_with, testonly, toolchain_config, toolchain_identifier, toolchains, visibility)

C++ 도구 모음을 나타냅니다.

이 규칙의 역할:

  • C++ 작업을 실행하는 데 필요한 모든 아티팩트 수집 이는 속성(예: all_files, compiler_files, linker_files 또는 _files로 끝나는 기타 속성) 이 두 가지는 모든 필수 파일을 글로빙하는 가장 일반적인 파일 그룹입니다.
  • C++ 작업을 위한 올바른 명령줄 생성 이 작업은 CcToolchainConfigInfo 제공업체 (아래 세부정보 참고)

toolchain_config 속성을 사용하여 C++ 도구 모음을 구성합니다. 참고 항목 페이지 를 참조하세요.

도구 모음이 빌드 및 구성되지 않도록 하려면 tags = ["manual"] 사용 bazel build //... 호출 시 불필요하게

인수

속성
name

이름 필수

이 대상의 고유한 이름입니다.
all_files

라벨 필수

모든 cc_툴체인 아티팩트 컬렉션입니다. 이러한 아티팩트는 모든 rules_cc 관련 작업( 아티팩트가 있음). Bazel은 all_files를 상위 집합이라고 가정합니다. 아티팩트를 제공하는 다른 모든 속성입니다 (예: linkstamp 컴파일에는 두 가지 모두 컴파일이 필요함). 링크 파일도 포함되므로 all_files가 필요합니다.

cc_toolchain.files에 포함된 내용이며 모든 Starlark에서 사용합니다. C++ 도구 모음을 사용하여 규칙을 구현하는 방법을 보여줍니다.
ar_files

라벨 기본값은 None입니다.

보관처리 작업에 필요한 모든 cc_Tools 아티팩트 컬렉션입니다.
as_files

라벨 기본값은 None입니다.

어셈블리 작업에 필요한 모든 cc_Tools 아티팩트 컬렉션입니다.
compiler_files

라벨 필수

컴파일 작업에 필요한 모든 cc_툴체인 아티팩트의 컬렉션입니다.
compiler_files_without_includes

라벨 기본값은 None입니다.

다음의 경우 컴파일 작업에 필요한 모든 cc_툴체인 아티팩트의 컬렉션입니다. 입력 검색이 지원됩니다 (현재 Google에서만 지원).
coverage_files

라벨 기본값은 None입니다.

적용 범위 작업에 필요한 모든 cc_툴체인 아티팩트의 컬렉션입니다. 지정하지 않으면 all_files가 사용됩니다.
dwp_files

라벨 필수

dwp 작업에 필요한 모든 cc_Tools 아티팩트의 컬렉션입니다.
dynamic_runtime_lib

라벨 기본값은 None입니다.

C++ 런타임 라이브러리의 동적 라이브러리 아티팩트 (예: libstdc++.so)입니다.

'static_link_cpp_runtimes' 기능이 사용 설정되었으며 동적으로 종속됩니다.
exec_transition_for_inputs

부울; 기본값은 False입니다.

지원 중단되었습니다. 작동하지 않습니다.
libc_top

라벨 기본값은 None입니다.

작업을 컴파일/연결하기 위해 입력으로 전달된 libc의 아티팩트 모음입니다.
linker_files

라벨 필수

연결 작업에 필요한 모든 cc_툴체인 아티팩트의 컬렉션입니다.
module_map

라벨 기본값은 None입니다.

모듈식 빌드에 사용할 모듈 맵 아티팩트입니다.
objcopy_files

라벨 필수

objcopy 작업에 필요한 모든 cc_툴체인 아티팩트의 컬렉션입니다.
output_licenses

문자열 목록 기본값은 []입니다.
static_runtime_lib

라벨 기본값은 None입니다.

C++ 런타임 라이브러리의 정적 라이브러리 아티팩트 (예: libstdc++.a)입니다.

'static_link_cpp_runtimes' 기능이 사용 설정되었으며 종속 항목을 정적으로 정의합니다
strip_files

라벨 필수

스트립 작업에 필요한 모든 cc_Tools 아티팩트의 컬렉션입니다.
supports_header_parsing

부울; 기본값은 False입니다.

cc_툴체인이 헤더 파싱 작업을 지원하면 True로 설정됩니다.
supports_param_files

부울; 기본값은 True입니다.

cc_툴체인이 연결 작업에 매개변수 파일 사용을 지원하는 경우 True로 설정합니다.
toolchain_config

라벨 필수

cc_toolchain_config_info를 제공하는 규칙의 라벨입니다.
toolchain_identifier

String; 기본값은 ""입니다.

이 cc_툴체인과 해당 툴체인을 일치시키는 데 사용되는 식별자 crosstool_config.toolchain.

#5380 문제가 해결될 때까지 cc_toolchain과(와) CROSSTOOL.toolchain입니다. toolchain_config로 대체됩니다. 속성 (#5380)

cc_toolchain_suite

규칙 소스 보기 
cc_toolchain_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

지원 중단됨: 규칙이 노옵스(no-ops)이며 삭제됩니다.

인수

속성
name

이름 필수

이 대상의 고유한 이름입니다.

fdo_prefetch_hints

규칙 소스 보기 
fdo_prefetch_hints(name, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

작업공간에 있는 FDO 미리 가져오기 힌트 프로필을 나타냅니다. 예:


fdo_prefetch_hints(
    name = "hints",
    profile = "//path/to/hints:profile.afdo",
)

인수

속성
name

이름 필수

이 대상의 고유한 이름입니다.
profile

라벨 필수

힌트 프로필의 라벨입니다. 힌트 파일의 확장자는 .afdo입니다. 라벨은 fdo_ 절대_경로_프로필 규칙을 가리킬 수도 있습니다.

fdo_profile

규칙 소스 보기 
fdo_profile(name, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, memprof_profile, profile, proto_profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

작업공간에 있는 FDO 프로필을 나타냅니다. 예:


fdo_profile(
    name = "fdo",
    profile = "//path/to/fdo:profile.zip",
)

인수

속성
name

이름 필수

이 대상의 고유한 이름입니다.
memprof_profile

라벨 기본값은 None입니다.

MemProf 프로필의 라벨 프로필에는 .profdata 확장자 (색인이 생성된/기호화된 memprof의 경우) 프로필) 또는 memprof.profdata가 포함된 zip 파일의 .zip 확장자를 사용하세요. 파일에서 참조됩니다.
profile

라벨 필수

FDO 프로필 또는 이 프로필을 생성하는 규칙의 라벨입니다. FDO 파일에는 확장 프로그램: 색인이 생성되지 않은 LLVM 프로필의 경우 .profraw, 색인이 생성된 LLVM의 경우 .profdata LLVM profraw 프로필을 포함하는 .zip, AutoFDO 프로필을 포함하는 .afdo, XBinary 프로필. 라벨은 fdo_ 절대_경로_프로필 규칙을 가리킬 수도 있습니다.
proto_profile

라벨 기본값은 None입니다.

protobuf 프로필의 라벨

memprof_profile

규칙 소스 보기 
memprof_profile(name, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

작업공간에 있는 MEMPROF 프로필을 나타냅니다. 예:


memprof_profile(
    name = "memprof",
    profile = "//path/to/memprof:profile.afdo",
)

인수

속성
name

이름 필수

이 대상의 고유한 이름입니다.
profile

라벨 필수

MEMPROF 프로필의 라벨입니다. 프로필에는 .profdata 확장자 (색인이 생성된/기호화된 memprof의 경우) 프로필) 또는 memprof.profdata가 포함된 zip 파일의 .zip 확장자를 사용하세요. 파일에서 참조됩니다. 라벨은 fdo_ 절대_경로_프로필 규칙을 가리킬 수도 있습니다.

propeller_optimize

규칙 소스 보기 
propeller_optimize(name, cc_profile, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, ld_profile, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)

작업공간의 프로펠러 최적화 프로필을 나타냅니다. 예:


propeller_optimize(
    name = "layout",
    cc_profile = "//path:cc_profile.txt",
    ld_profile = "//path:ld_profile.txt"
)

인수

속성
name

이름 필수

이 대상의 고유한 이름입니다.
cc_profile

라벨 필수

다양한 컴파일 작업에 전달된 프로필의 라벨입니다. 이 파일에는 .txt 확장자로 저장되어야 합니다.
ld_profile

라벨 필수

연결 작업에 전달된 프로필의 라벨입니다. 이 파일에는 .txt 확장자로 저장되어야 합니다.