C++ 도구 모음 구성

문제 신고하기 소스 보기

개요

올바른 옵션으로 컴파일러를 호출하려면 Bazel이 include 디렉터리, 중요 플래그와 같은 컴파일러 내부 요소에 관한 지식이 필요합니다. 즉, Bazel이 동작을 이해하기 위해서는 단순화된 컴파일러 모델이 필요합니다.

Bazel은 다음을 알아야 합니다.

  • 컴파일러가 thinLTO, 모듈, 동적 링크 또는 PIC(위치 독립적 코드)를 지원하는지 여부입니다.
  • gcc, ld, ar, objcopy 등과 같은 필수 도구의 경로입니다.
  • 내장 시스템에는 디렉터리가 포함됩니다. Bazel은 소스 파일에 포함된 모든 헤더가 BUILD 파일에서 올바르게 선언되었는지 검증하기 위해 이 속성이 필요합니다.
  • 기본 sysroot입니다.
  • 컴파일, 연결, 보관처리에 사용할 플래그
  • 지원되는 컴파일 모드에 사용할 플래그 (opt, dbg, fastbuild)
  • 컴파일러에서 구체적으로 요구하는 변수를 만듭니다.

컴파일러가 여러 아키텍처를 지원하는 경우 Bazel은 아키텍처를 개별적으로 구성해야 합니다.

CcToolchainConfigInfo는 Bazel의 C++ 규칙의 동작을 구성하는 데 필요한 수준의 세부사항을 제공하는 제공자입니다. 기본적으로 Bazel은 빌드의 CcToolchainConfigInfo를 자동으로 구성하지만 수동으로 구성할 수도 있습니다. 이를 위해서는 CcToolchainConfigInfo를 제공하는 Starlark 규칙이 필요하며 cc_toolchaintoolchain_config 속성이 규칙을 가리키도록 해야 합니다. cc_common.create_cc_toolchain_config_info()를 호출하여 CcToolchainConfigInfo를 만들 수 있습니다. @rules_cc//cc:cc_toolchain_config_lib.bzl에서 프로세스에 필요한 모든 구조체의 Starlark 생성자를 찾을 수 있습니다.

C++ 대상이 분석 단계에 들어가면 Bazel은 BUILD 파일을 기반으로 적절한 cc_toolchain 대상을 선택하고 cc_toolchain.toolchain_config 속성에 지정된 대상에서 CcToolchainConfigInfo 제공자를 가져옵니다. cc_toolchain 타겟은 CcToolchainProvider를 통해 이 정보를 C++ 타겟에 전달합니다.

예를 들어 cc_binary 또는 cc_library과 같은 규칙으로 인스턴스화된 컴파일 또는 링크 작업에는 다음 정보가 필요합니다.

  • 사용할 컴파일러 또는 링커
  • 컴파일러/링커의 명령줄 플래그
  • --copt/--linkopt 옵션을 통해 전달된 구성 플래그
  • 환경 변수
  • 작업이 실행되는 샌드박스에 필요한 아티팩트

샌드박스에 필요한 아티팩트를 제외한 위의 모든 정보는 cc_toolchain가 가리키는 Starlark 타겟에 지정됩니다.

샌드박스로 제공할 아티팩트는 cc_toolchain 타겟에서 선언됩니다. 예를 들어 cc_toolchain.linker_files 속성을 사용하면 샌드박스로 제공할 링커 바이너리와 도구 모음 라이브러리를 지정할 수 있습니다.

도구 모음 선택

도구 모음 선택 로직은 다음과 같이 작동합니다.

  1. 사용자가 BUILD 파일에서 cc_toolchain_suite 대상을 지정하고 --crosstool_top 옵션을 사용하여 Bazel을 대상을 가리킵니다.

  2. cc_toolchain_suite 대상은 여러 도구 모음을 참조합니다. --cpu--compiler 플래그 값은 --cpu 플래그 값 또는 공동 --cpu | --compiler 값을 기준으로 이러한 도구 모음 중 선택되는 도구를 결정합니다. 선정 프로세스는 다음과 같습니다.

    • --compiler 옵션이 지정된 경우 Bazel은 --cpu | --compiler가 있는 cc_toolchain_suite.toolchains 속성에서 해당 항목을 선택합니다. Bazel이 해당 항목을 찾지 못하면 오류가 발생합니다.

    • --compiler 옵션을 지정하지 않으면 Bazel은 cc_toolchain_suite.toolchains 속성에서 --cpu만 사용하여 해당 항목을 선택합니다.

    • 플래그가 지정되지 않으면 Bazel이 호스트 시스템을 검사하고 발견 항목을 기반으로 --cpu 값을 선택합니다. 검사 메커니즘 코드를 참고하세요.

도구 모음을 선택하면 Starlark 규칙의 상응하는 featureaction_config 객체가 빌드 구성을 관리합니다 (즉, 나중에 설명하는 항목). 이러한 메시지를 사용하면 Bazel 바이너리를 수정하지 않고도 Bazel에서 완전한 C++ 기능을 구현할 수 있습니다. C++ 규칙은 Bazel 소스 코드에 자세히 설명되어 있는 여러 고유 작업을 지원합니다.

기능

기능은 실행 환경에 대한 명령줄 플래그, 작업, 제약조건 또는 종속 항목 변경이 필요한 항목입니다. 기능은 BUILD 파일이 플래그 구성(예: treat_warnings_as_errors)을 선택하거나 C++ 규칙과 상호작용하고 새로운 컴파일 작업과 컴파일에 대한 입력(예: header_modules 또는 thin_lto)을 포함하도록 허용하는 등의 간단한 작업이 될 수 있습니다.

이상적으로 CcToolchainConfigInfo에는 기능 목록이 포함됩니다. 여기서 각 기능은 하나 이상의 플래그 그룹으로 구성되며, 각 기능은 특정 Bazel 작업에 적용되는 플래그 목록을 정의합니다.

기능은 이름으로 지정되므로 Bazel 출시 버전에서 Starlark 규칙 구성을 완전히 분리할 수 있습니다. 즉, Bazel 출시 버전은 CcToolchainConfigInfo 구성에 새 기능을 사용할 필요가 없는 한 이 구성의 동작에 영향을 미치지 않습니다.

기능은 다음 중 한 가지 방법으로 사용 설정할 수 있습니다.

  • 이 기능의 enabled 필드는 true으로 설정됩니다.
  • Bazel 또는 규칙 소유자가 명시적으로 사용 설정합니다.
  • 사용자는 --feature Bazel 옵션 또는 features 규칙 속성을 통해 이를 사용 설정합니다.

기능은 상호 종속 항목을 가질 수 있으며 명령줄 플래그, BUILD 파일 설정, 기타 변수에 종속될 수 있습니다.

특성 관계

종속 항목은 일반적으로 Bazel을 통해 직접 관리됩니다. Bazel은 단순히 요구사항을 적용하고 빌드에 정의된 기능의 특성상 고유한 충돌을 관리합니다. 도구 모음 사양은 기능 지원 및 확장을 제어하는 Starlark 규칙 내에서 직접 사용할 수 있는 더 세분화된 제약조건을 허용합니다. 이는 다음과 같습니다.

제약조건 설명
requires = [
   feature_set (features = [
       'feature-name-1',
       'feature-name-2'
   ]),
]
지형지물 수준입니다. 이 기능은 지정된 필수 기능이 사용 설정된 경우에만 지원됩니다. 예를 들어 기능이 특정 빌드 모드 (opt, dbg 또는 fastbuild)에서만 지원되는 경우입니다. 'requirements'에 여러 'feature_set'이 포함된 경우 'feature_set' 중 하나라도 충족되면 기능이 지원됩니다(지정된 모든 기능이 사용 설정된 경우).
implies = ['feature']

지형지물 수준입니다. 이 지형지물은 지정된 지형지물을 의미합니다. 또한 기능을 사용 설정하면 포함된 모든 기능이 암시적으로 사용 설정됩니다(즉, 기능이 재귀적으로 기능함).

또한 새니타이저의 일반적인 부분과 같이 일련의 기능에서 일반적인 기능의 하위 집합을 인수분해할 수 있는 기능도 제공합니다. 암시적 기능은 사용 중지할 수 없습니다.

provides = ['feature']

지형지물 수준입니다. 이 기능이 상호 배타적인 여러 대체 기능 중 하나임을 나타냅니다. 예를 들어 모든 새니타이저가 provides = ["sanitizer"]를 지정할 수 있습니다.

이렇게 하면 사용자가 동시에 상호 배타적인 두 개 이상의 기능을 요청하는 경우 대안을 나열하여 오류 처리가 개선됩니다.

with_features = [
  with_feature_set(
    features = ['feature-1'],
    not_features = ['feature-2'],
  ),
]
플래그 세트 수준입니다. 특성은 여러 플래그 집합을 지정할 수 있습니다. with_features가 지정되면 플래그 세트는 지정된 features 세트의 모든 기능이 사용 설정되고 not_features 세트에 지정된 모든 기능이 사용 중지된 with_feature_set가 하나 이상 있는 경우에만 빌드 명령어로 확장됩니다. with_features를 지정하지 않으면 지정된 모든 작업에 플래그 세트가 무조건 적용됩니다.

작업

작업을 사용하면 작업 실행 방법을 가정하지 않고 작업이 실행되는 상황을 유연하게 수정할 수 있습니다. action_config는 작업이 호출하는 도구 바이너리를 지정하고 feature는 작업이 호출될 때 도구가 동작하는 방식을 결정하는 구성 (플래그)을 지정합니다.

기능 참조 작업은 어떤 Bazel 작업에 영향을 미치는지 신호를 보냅니다. 작업은 Bazel 작업 그래프를 수정할 수 있기 때문입니다. CcToolchainConfigInfo 제공자에는 c++-compile와 같이 연결된 플래그와 도구가 있는 작업이 포함되어 있습니다. 플래그는 기능과 연결하여 각 작업에 할당됩니다.

각 작업 이름은 컴파일 또는 연결과 같이 Bazel이 수행하는 단일 유형의 작업을 나타냅니다. 하지만 작업과 Bazel 작업 유형 사이에는 다대일 관계가 있습니다. 여기서 Bazel 작업 유형은 작업을 구현하는 Java 클래스 (예: CppCompileAction)를 의미합니다. 특히 아래 표의 '어셈블러 작업'과 '컴파일러 작업'은 CppCompileAction이고 링크 작업은 CppLinkAction입니다.

어셈블러 작업

조치 설명
preprocess-assemble 전처리로 조립합니다. 일반적으로 .S 파일의 경우
assemble 전처리 없이 조립합니다. 일반적으로 .s 파일의 경우

컴파일러 작업

조치 설명
cc-flags-make-variable genrule에 CC_FLAGS를 전파합니다.
c-compile C로 컴파일합니다.
c++-compile C++로 컴파일합니다.
c++-header-parsing 헤더 파일에서 컴파일러의 파서를 실행하여 헤더가 자체적으로 포함되었는지 확인합니다. 그러지 않으면 컴파일 오류가 발생합니다. 모듈을 지원하는 도구 모음에만 적용됩니다.
조치 설명
c++-link-dynamic-library 모든 종속 항목이 포함된 공유 라이브러리를 연결합니다.
c++-link-nodeps-dynamic-library cc_library 소스만 포함된 공유 라이브러리를 연결하세요.
c++-link-executable 바로 실행할 수 있는 최종 라이브러리를 연결합니다.

AR 작업

AR 작업은 ar를 통해 객체 파일을 보관 라이브러리 (.a 파일)로 조합하고 일부 의미 체계를 이름으로 인코딩합니다.

조치 설명
c++-link-static-library 정적 라이브러리 (보관 파일)를 만듭니다.

LTO 작업

조치 설명
lto-backend 비트코드를 네이티브 객체로 컴파일하는 ThinLTO 작업
lto-index 전역 색인을 생성하는 ThinLTO 작업입니다.

action_config 사용

action_config는 작업 중에 호출할 도구 (바이너리)와 기능으로 정의된 플래그 집합을 지정하여 Bazel 작업을 설명하는 Starlark 구조입니다. 이러한 플래그는 작업 실행에 제약조건을 적용합니다.

action_config() 생성자에는 다음과 같은 매개변수가 있습니다.

속성 설명
action_name 이 작업에 해당하는 Bazel 작업입니다. Bazel은 이 속성을 사용하여 작업당 도구 및 실행 요구사항을 찾습니다.
tools 호출할 실행 파일입니다. 작업에 적용되는 도구는 특성 구성과 일치하는 특성 세트를 가진 목록의 첫 번째 도구가 됩니다. 기본값을 입력해야 합니다.
flag_sets 작업 그룹에 적용되는 플래그 목록입니다. 특성과 동일합니다.
env_sets 작업 그룹에 적용되는 환경 제약조건의 목록입니다. 특성과 동일합니다.

action_config는 앞에서 설명한 기능 관계에 명시된 다른 기능과 action_config를 요구하고 암시할 수 있습니다. 이 동작은 기능의 동작과 유사합니다.

마지막 두 속성은 기능의 상응하는 속성과 중복되며 일부 Bazel 작업에 특정 플래그 또는 환경 변수가 필요하고 불필요한 action_config+feature 쌍을 피하는 것이 목표이기 때문에 포함됩니다. 일반적으로 여러 action_config에서 단일 특성을 공유하는 것이 좋습니다.

동일한 도구 모음 내에서 동일한 action_nameaction_config를 2개 이상 정의할 수 없습니다. 이렇게 하면 도구 경로의 모호성을 방지하고 작업 속성이 도구 모음의 단일 위치에 명확하게 설명되도록 action_config를 뒷받침하는 의도를 갖게 됩니다.

도구 생성자 사용

action_configtools 매개변수를 통해 도구 집합을 지정할 수 있습니다. tool() 생성자는 다음 매개변수를 사용합니다.

필드 설명
path 문제가 되는 도구의 경로입니다 (현재 위치 기준).
with_features 이 도구를 적용하려면 1개 이상을 충족해야 하는 지형지물 집합의 목록입니다.

지정된 action_config의 경우 단일 tool만 도구 경로와 실행 요구사항을 Bazel 작업에 적용합니다. 도구는 지형지물 구성과 일치하는 with_feature 세트가 있는 도구를 찾을 때까지 action_configtools 속성을 반복하여 선택됩니다(자세한 내용은 이 페이지 앞부분의 특성 관계 참고). 빈 기능 구성에 해당하는 기본 도구로 도구 목록을 종료해야 합니다.

사용 예시

기능과 작업을 함께 사용하여 다양한 크로스 플랫폼 시맨틱스로 Bazel 작업을 구현할 수 있습니다. 예를 들어 macOS에서 디버그 기호를 생성하려면 컴파일 작업에서 기호를 생성한 다음 링크 작업 중에 특수 도구를 호출하여 압축된 dsym 보관 파일을 만든 다음 보관 파일을 압축 해제하여 Xcode에서 사용할 수 있는 애플리케이션 번들과 .plist 파일을 생성해야 합니다.

Bazel을 사용하면 이 프로세스를 다음과 같이 구현할 수 있습니다. unbundle-debuginfo는 Bazel 작업입니다.

load("@rules_cc//cc:defs.bzl", "ACTION_NAMES")

action_configs = [
    action_config (
        action_name = ACTION_NAMES.cpp_link_executable,
        tools = [
            tool(
                with_features = [
                    with_feature(features=["generate-debug-symbols"]),
                ],
                path = "toolchain/mac/ld-with-dsym-packaging",
            ),
            tool (path = "toolchain/mac/ld"),
        ],
    ),
]

features = [
    feature(
        name = "generate-debug-symbols",
        flag_sets = [
            flag_set (
                actions = [
                    ACTION_NAMES.c_compile,
                    ACTION_NAMES.cpp_compile
                ],
                flag_groups = [
                    flag_group(
                        flags = ["-g"],
                    ),
                ],
            )
        ],
        implies = ["unbundle-debuginfo"],
   ),
]

fission를 사용하는 Linux나 .pdb 파일을 생성하는 Windows의 경우 동일한 기능을 완전히 다르게 구현할 수 있습니다. 예를 들어 fission 기반 디버그 기호 생성을 위한 구현은 다음과 같습니다.

load("@rules_cc//cc:defs.bzl", "ACTION_NAMES")

action_configs = [
    action_config (
        name = ACTION_NAMES.cpp_compile,
        tools = [
            tool(
                path = "toolchain/bin/gcc",
            ),
        ],
    ),
]

features = [
    feature (
        name = "generate-debug-symbols",
        requires = [with_feature_set(features = ["dbg"])],
        flag_sets = [
            flag_set(
                actions = [ACTION_NAMES.cpp_compile],
                flag_groups = [
                    flag_group(
                        flags = ["-gsplit-dwarf"],
                    ),
                ],
            ),
            flag_set(
                actions = [ACTION_NAMES.cpp_link_executable],
                flag_groups = [
                    flag_group(
                        flags = ["-Wl", "--gdb-index"],
                    ),
                ],
            ),
      ],
    ),
]

플래그 그룹

CcToolchainConfigInfo를 사용하면 플래그를 특정 용도로 사용되는 그룹으로 묶을 수 있습니다. 플래그 값 내에 사전 정의된 변수를 사용하여 플래그를 지정할 수 있습니다. 이 변수는 플래그를 빌드 명령어에 추가할 때 컴파일러가 확장합니다. 예를 들면 다음과 같습니다.

flag_group (
    flags = ["%{output_execpath}"],
)

이 경우 플래그 내용이 작업의 출력 파일 경로로 바뀝니다.

플래그 그룹은 목록에서 위에서 아래로, 왼쪽에서 오른쪽으로 표시되는 순서대로 빌드 명령어로 확장됩니다.

빌드 명령어에 추가할 때 다른 값으로 반복해야 하는 플래그의 경우 플래그 그룹은 list 유형의 변수를 반복할 수 있습니다. 예를 들어 list 유형의 include_path 변수는 다음과 같습니다.

flag_group (
    iterate_over = "include_paths",
    flags = ["-I%{include_paths}"],
)

include_paths 목록의 각 경로 요소에 관해 -I<path>로 확장됩니다. 플래그 그룹 선언의 본문에 있는 모든 플래그 (또는 flag_group)는 단위로 확장됩니다. 예를 들면 다음과 같습니다.

flag_group (
    iterate_over = "include_paths",
    flags = ["-I", "%{include_paths}"],
)

include_paths 목록의 각 경로 요소에 관해 -I <path>로 확장됩니다.

변수는 여러 번 반복될 수 있습니다. 예를 들면 다음과 같습니다.

flag_group (
    iterate_over = "include_paths",
    flags = ["-iprefix=%{include_paths}", "-isystem=%{include_paths}"],
)

다음으로 확장됩니다.

-iprefix=<inc0> -isystem=<inc0> -iprefix=<inc1> -isystem=<inc1>

변수는 점 표기법을 사용하여 액세스 가능한 구조체에 대응될 수 있습니다. 예를 들면 다음과 같습니다.

flag_group (
    flags = ["-l%{libraries_to_link.name}"],
)

구조는 중첩될 수 있으며 시퀀스를 포함할 수도 있습니다. 이름 충돌을 방지하고 명시하려면 필드를 통해 전체 경로를 지정해야 합니다. 예를 들면 다음과 같습니다.

flag_group (
    iterate_over = "libraries_to_link",
    flag_groups = [
        flag_group (
            iterate_over = "libraries_to_link.shared_libraries",
            flags = ["-l%{libraries_to_link.shared_libraries.name}"],
        ),
    ],
)

조건부 확장

플래그 그룹은 expand_if_available, expand_if_not_available, expand_if_true, expand_if_false 또는 expand_if_equal 속성을 사용하여 특정 변수 또는 해당 필드의 존재 여부에 따른 조건부 확장을 지원합니다. 예를 들면 다음과 같습니다.

flag_group (
    iterate_over = "libraries_to_link",
    flag_groups = [
        flag_group (
            iterate_over = "libraries_to_link.shared_libraries",
            flag_groups = [
                flag_group (
                    expand_if_available = "libraries_to_link.shared_libraries.is_whole_archive",
                    flags = ["--whole_archive"],
                ),
                flag_group (
                    flags = ["-l%{libraries_to_link.shared_libraries.name}"],
                ),
                flag_group (
                    expand_if_available = "libraries_to_link.shared_libraries.is_whole_archive",
                    flags = ["--no_whole_archive"],
                ),
            ],
        ),
    ],
)

CcToolchainConfigInfo 참조

이 섹션에서는 C++ 규칙을 성공적으로 구성하는 데 필요한 빌드 변수, 기능, 기타 정보에 관한 참조를 제공합니다.

CcToolchainConfigInfo 빌드 변수

다음은 CcToolchainConfigInfo 빌드 변수의 참조입니다.

변수 조치 설명
source_file compile 컴파일할 소스 파일입니다.
input_file strip 제거할 아티팩트
output_file compile 컴파일 출력
output_assembly_file compile 내보낸 어셈블리 파일 일반적으로 --save_temps 플래그를 사용할 때 compile 작업이 어셈블리 텍스트를 내보낼 때만 적용됩니다. 콘텐츠는 output_file와 동일합니다.
output_preprocess_file compile 사전 처리된 출력 일반적으로 --save_temps 플래그를 사용하는 경우 소스 파일을 사전 처리하는 컴파일 작업에만 적용됩니다. 콘텐츠는 output_file와 동일합니다.
includes compile 컴파일러가 컴파일된 소스에 무조건 포함해야 하는 파일 시퀀스
include_paths compile 컴파일러가 #include<foo.h>#include "foo.h"를 사용하여 포함된 헤더를 검색하는 시퀀스 디렉터리
quote_include_paths compile -iquote 시퀀스에는 컴파일러가 #include "foo.h"를 사용하여 포함된 헤더를 검색하는 디렉터리가 포함됩니다.
system_include_paths compile -isystem 시퀀스에는 컴파일러가 #include <foo.h>를 사용하여 포함된 헤더를 검색하는 디렉터리가 포함됩니다.
dependency_file compile 컴파일러에서 생성한 .d 종속 항목 파일
preprocessor_defines compile defines의 시퀀스입니다(예: --DDEBUG).
pic compile 출력을 위치 독립적 코드로 컴파일합니다.
gcov_gcno_file compile gcov 적용 범위 파일
per_object_debug_info_file compile 객체별 디버그 정보 (.dwp) 파일
stripotps strip stripopts의 시퀀스입니다.
legacy_compile_flags compile 기존 CROSSTOOL 필드의 플래그 시퀀스(예: compiler_flag, optional_compiler_flag, cxx_flag, optional_cxx_flag)
user_compile_flags compile copt 규칙 속성이나 --copt, --cxxopt, --conlyopt 플래그의 플래그 시퀀스
unfiltered_compile_flags compile unfiltered_cxx_flag 기존 CROSSTOOL 필드 또는 unfiltered_compile_flags 기능의 플래그 시퀀스입니다. 이는 nocopts 규칙 속성으로 필터링되지 않습니다.
sysroot sysroot
runtime_library_search_directories 링크 링커 런타임 검색 경로의 항목 (일반적으로 -rpath 플래그로 설정됨).
library_search_directories 링크 링커 검색 경로의 항목 (일반적으로 -L 플래그로 설정됨).
libraries_to_link 링크 링커 호출의 입력으로 연결할 파일을 제공하는 플래그입니다.
def_file_path 링크 MSVC를 사용하는 Windows에서 사용되는 def 파일의 위치입니다.
linker_param_file 링크 명령줄 길이 제한을 초과하기 위해 bazel에서 만든 링커 매개변수 파일의 위치입니다.
output_execpath 링크 링커 출력의 실행 경로입니다.
generate_interface_library 링크 인터페이스 라이브러리를 생성해야 하는지 여부에 따라 "yes" 또는 "no"입니다.
interface_library_builder_path 링크 인터페이스 라이브러리 빌더 도구의 경로입니다.
interface_library_input_path 링크 인터페이스 라이브러리 ifso 빌더 도구의 입력입니다.
interface_library_output_path 링크 ifso 빌더 도구를 사용하여 인터페이스 라이브러리를 생성할 경로입니다.
legacy_link_flags 링크 기존 CROSSTOOL 필드에서 가져오는 링커 플래그입니다.
user_link_flags 링크 --linkopt 또는 linkopts 속성에서 비롯되는 링커 플래그
linkstamp_paths 링크 링크스탬프 경로를 제공하는 빌드 변수입니다.
force_pic 링크 이 변수가 있으면 PIC/PIE 코드를 생성해야 함을 나타냅니다 (Bazel 옵션 `--force_pic` 이 전달됨).
strip_debug_symbols 링크 이 변수가 있으면 디버그 기호를 제거해야 함을 나타냅니다.
is_cc_test 링크 현재 작업이 cc_test 연결 작업인 경우 Truthy, 그렇지 않으면 false입니다.
is_using_fission 컴파일, 링크 이 변수가 있으면 분할 (객체별 디버그 정보)이 활성화되었음을 나타냅니다. 디버그 정보는 .o 파일이 아닌 .dwo 파일에 있으며 컴파일러와 링커가 이를 알아야 합니다.
fdo_instrument_path 컴파일, 링크 FDO 계측 프로필을 저장하는 디렉터리의 경로입니다.
fdo_profile_path compile FDO 프로필의 경로입니다.
fdo_prefetch_hints_path compile 캐시 미리 가져오기 프로필의 경로입니다.
cs_fdo_instrument_path 컴파일, 링크 컨텍스트에 민감한 FDO 계측 프로필을 저장하는 디렉터리의 경로입니다.

잘 알려진 기능

다음은 기능 및 해당 활성화 조건에 대한 참조입니다.

기능 문서
opt | dbg | fastbuild 컴파일 모드에 따라 기본적으로 사용 설정됩니다.
static_linking_mode | dynamic_linking_mode 연결 모드에 따라 기본적으로 사용 설정됩니다.
per_object_debug_info supports_fission 기능이 지정되고 사용 설정되고 현재 컴파일 모드가 --fission 플래그에 지정된 경우 사용 설정됩니다.
supports_start_end_lib 사용 설정되면 (옵션 --start_end_lib가 설정됨) Bazel은 정적 라이브러리에 연결되지 않고 대신 --start-lib/--end-lib 링커 옵션을 사용하여 객체에 직접 연결합니다. Bazel이 정적 라이브러리를 빌드할 필요가 없으므로 빌드 속도가 빨라집니다.
supports_interface_shared_libraries 사용 설정되면 (옵션 --interface_shared_objects가 설정됨) Bazel은 인터페이스 공유 라이브러리에 linkstatic가 False로 설정된 (기본적으로 cc_test) 있는 대상을 인터페이스 공유 라이브러리에 연결합니다. 이렇게 하면 증분 재연결이 더 빨라집니다.
supports_dynamic_linker 사용 설정하면 C++ 규칙에서 도구 모음이 공유 라이브러리를 생성할 수 있음을 인식합니다.
static_link_cpp_runtimes 사용 설정하면 Bazel이 정적 연결 모드에서는 C++ 런타임을 정적으로 연결하고 동적 연결 모드에서는 동적으로 연결합니다. 연결 모드에 따라 cc_toolchain.static_runtime_lib 또는 cc_toolchain.dynamic_runtime_lib 속성에 지정된 아티팩트가 연결 작업에 추가됩니다.
supports_pic 사용 설정하면 도구 모음이 동적 라이브러리에 PIC 객체를 사용할 수 있음을 인식합니다. `pic` 변수는 PIC 컴파일이 필요할 때마다 존재합니다. 기본적으로 사용 설정되지 않고 `--force_pic` 이 전달되는 경우 Bazel은 `supports_pic` 을 요청하고 기능이 사용 설정되어 있는지 확인합니다. 기능이 없거나 사용 설정할 수 없는 경우 `--force_pic` 을 사용할 수 없습니다.
static_linking_mode | dynamic_linking_mode 연결 모드에 따라 기본적으로 사용 설정됩니다.
no_legacy_features 기존 기능이 있는 경우 Bazel이 C++ 구성에 기존 기능을 추가하지 못하도록 합니다. 아래에서 전체 기능 목록을 참조하세요.

기존 기능 패치 로직

Bazel은 이전 버전과의 호환성을 위해 도구 모음의 기능에 다음 변경 사항을 적용합니다.

  • legacy_compile_flags 기능을 도구 모음 상단으로 이동합니다.
  • default_compile_flags 기능을 도구 모음 상단으로 이동합니다.
  • dependency_file (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • pic (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • per_object_debug_info (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • preprocessor_defines (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • includes (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • include_paths (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • fdo_instrument (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • fdo_optimize (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • cs_fdo_instrument (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • cs_fdo_optimize (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • fdo_prefetch_hints (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • autofdo (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • build_interface_libraries (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • dynamic_library_linker_tool (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • shared_flag (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • linkstamps (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • output_execpath_flags (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • runtime_library_search_directories (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • library_search_directories (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • archiver_flags (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • libraries_to_link (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • force_pic_flags (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • user_link_flags (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • legacy_link_flags (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • static_libgcc (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • fission_support (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • strip_debug_symbols (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • coverage (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • llvm_coverage_map_format (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • gcc_coverage_map_format (존재하지 않는 경우) 기능을 도구 모음 상단에 추가합니다.
  • fully_static_link (존재하지 않는 경우) 기능을 도구 모음 하단에 추가합니다.
  • user_compile_flags (존재하지 않는 경우) 기능을 도구 모음 하단에 추가합니다.
  • sysroot (존재하지 않는 경우) 기능을 도구 모음 하단에 추가합니다.
  • unfiltered_compile_flags (존재하지 않는 경우) 기능을 도구 모음 하단에 추가합니다.
  • linker_param_file (존재하지 않는 경우) 기능을 도구 모음 하단에 추가합니다.
  • compiler_input_flags (존재하지 않는 경우) 기능을 도구 모음 하단에 추가합니다.
  • compiler_output_flags (존재하지 않는 경우) 기능을 도구 모음 하단에 추가합니다.

긴 기능 목록입니다. Starlark의 Crosstool이 완료되면 이를 제거할 계획입니다. 궁금한 점이 있으면 CppActionConfigs에서 구현을 참조하고, 프로덕션 도구 모음의 경우 no_legacy_features를 추가하여 도구 모음을 더 독립적으로 만드는 것이 좋습니다.