Abseil 빌드와 의존성 — Bazel vs CMake
한 줄 요약: Abseil은 Bazel-first 라이브러리지만 CMake도 동급으로 지원한다. 패키지 매니저(vcpkg/Conan)는 LTS 스냅숏만 다루고, source build가 ABI 안전성의 기본 전제다.
#어떤 문제를 푸는가
C++의 빌드 생태계는 분열되어 있다. Bazel, CMake, Meson, Buck, MSBuild가 공존하고 각자의 관습이 다르다. 라이브러리 저자는 어느 빌드 시스템을 first-class로 다룰지 정해야 한다. Abseil의 답은 Bazel을 우선하되 CMake를 동등하게 지원한다.
여기에 더해 ABI 정책이 빌드 방식에 직접 영향을 미친다. “단일 빌드 단위 내에서만 ABI 호환을 보장”하므로, 사전 빌드된 binary를 갖다 쓰는 것보다 source build가 권장된다.
#Bazel — first-class
Bazel은 Google이 만든 빌드 시스템이고 Abseil이 사내에서 사용하는 도구다. 그래서 Abseil의 BUILD 파일은 사내 코드와 동일한 룰을 따른다.
#WORKSPACE 방식 (Bazel 5 이전)
# WORKSPACEload("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive( name = "com_google_absl", sha256 = "f50e5ac311a81382da7fa75b97310e4b9006474f9560ac46f54a9967f07d4ae3", strip_prefix = "abseil-cpp-20240722.0", urls = ["https://github.com/abseil/abseil-cpp/releases/download/20240722.0/abseil-cpp-20240722.0.tar.gz"],)#MODULE.bazel 방식 (Bazel 6+)
# MODULE.bazel — bzlmodbazel_dep(name = "abseil-cpp", version = "20240722.0")bzlmod는 의존성 충돌을 자동으로 해소해주고, 같은 라이브러리의 여러 버전이 transitive하게 들어오는 문제를 해결한다. Bazel 7부터 기본이 되었다.
#BUILD 파일에서 사용
cc_library( name = "my_lib", srcs = ["my_lib.cc"], hdrs = ["my_lib.h"], deps = [ "@com_google_absl//absl/strings", "@com_google_absl//absl/status", "@com_google_absl//absl/container:flat_hash_map", ],)target 이름은 sub-library 단위로 잘게 나뉘어 있다. absl::strings를 쓴다고 해서 absl::container가 따라오지 않는다. 필요한 것만 명시한다.
#CMake — second-class지만 동등
CMake는 외부 사용자의 다수가 쓰기 때문에 Abseil이 동등한 수준으로 지원한다. 두 가지 방식이 있다.
#FetchContent 방식 (권장)
cmake_minimum_required(VERSION 3.16)project(my_project CXX)set(CMAKE_CXX_STANDARD 17)set(CMAKE_CXX_STANDARD_REQUIRED ON)
include(FetchContent)FetchContent_Declare( abseil-cpp GIT_REPOSITORY https://github.com/abseil/abseil-cpp.git GIT_TAG 20240722.0)set(ABSL_PROPAGATE_CXX_STD ON)set(BUILD_TESTING OFF)FetchContent_MakeAvailable(abseil-cpp)
add_executable(my_app main.cc)target_link_libraries(my_app PRIVATE absl::strings absl::status absl::flat_hash_map)ABSL_PROPAGATE_CXX_STD를 켜야 Abseil이 사용자 프로젝트의 C++ 표준 설정을 따른다. 끄면 Abseil이 자체적으로 C++ 표준을 결정하고, 사용자 프로젝트와 불일치할 수 있다.
#add_subdirectory 방식
# Abseil source를 third_party/abseil-cpp에 git submodule로 둔 경우set(ABSL_PROPAGATE_CXX_STD ON)add_subdirectory(third_party/abseil-cpp)
target_link_libraries(my_app PRIVATE absl::strings)submodule을 직접 관리하고 싶을 때 쓴다. 보안 감사를 통과해야 하는 환경에서 외부 fetch가 금지된 경우 자주 본다.
#find_package 방식 (시스템 설치)
find_package(absl REQUIRED)target_link_libraries(my_app PRIVATE absl::strings)시스템에 미리 설치된 Abseil을 쓴다. apt/yum/brew로 깔린 버전. ABI 정책 때문에 권장되지 않는다.
#CMake target 이름
CMake에서 노출되는 target은 Bazel의 sub-library와 1
대응한다.| Bazel | CMake |
|---|---|
@com_google_absl//absl/strings | absl::strings |
@com_google_absl//absl/status | absl::status |
@com_google_absl//absl/status:statusor | absl::statusor |
@com_google_absl//absl/container:flat_hash_map | absl::flat_hash_map |
@com_google_absl//absl/synchronization | absl::synchronization |
@com_google_absl//absl/time | absl::time |
CMake도 sub-library 단위로 link 해야 한다. absl::all 같은 통짜 target은 의도적으로 제공하지 않는다.
#vcpkg
Microsoft의 vcpkg는 LTS 스냅숏만 다룬다.
vcpkg install abseilfind_package(absl CONFIG REQUIRED)target_link_libraries(my_app PRIVATE absl::strings absl::status)vcpkg는 두 모드가 있다. classic mode는 시스템 전역에 설치하는 방식이고, manifest mode는 프로젝트별로 의존성을 lockfile로 관리한다.
{ "name": "my-project", "version": "1.0.0", "dependencies": [ "abseil" ], "builtin-baseline": "..."}manifest mode가 권장된다. lockfile이 reproducible build를 보장한다.
#Conan
JFrog의 Conan도 LTS만 다룬다.
[requires]abseil/20240722.0
[generators]CMakeDepsCMakeToolchainconan install . --output-folder=build --build=missingcmake -B build -DCMAKE_TOOLCHAIN_FILE=build/conan_toolchain.cmakecmake --build buildConan은 source build와 prebuilt 둘 다 지원한다. ABI 안전성을 생각하면 source build (--build=abseil)를 권장한다.
#ABI와 빌드 방식의 관계
빌드 방식별 ABI 안전성을 정리하면 다음과 같다.
| 방식 | ABI 안전성 | 이유 |
|---|---|---|
| Bazel | 안전 | 전체 의존성을 같은 옵션으로 source build |
| CMake FetchContent | 안전 | 사용자 프로젝트와 같이 빌드 |
| CMake add_subdirectory | 안전 | 같은 빌드 |
| vcpkg manifest + source | 안전 | lockfile 기반 source build |
| Conan source build | 안전 | source build |
| Conan prebuilt | 위험 | 다른 사람이 빌드한 binary |
| 시스템 패키지 (apt/yum) | 위험 | 시스템 컴파일러 옵션에 묶임 |
#의존성 그래프
Abseil 내부의 sub-library는 서로 의존한다. 예를 들어 absl::status는 absl::strings에 의존한다. CMake target은 이 의존을 자동으로 전파한다.
target_link_libraries(my_app PRIVATE absl::status)# absl::strings, absl::synchronization 등이 자동으로 따라온다Bazel도 동일하다. transitive dependency가 자동 해결된다.
#빌드 옵션
Abseil이 노출하는 주요 옵션은 다음과 같다.
set(ABSL_PROPAGATE_CXX_STD ON) # 사용자 C++ 표준을 따름set(ABSL_USE_EXTERNAL_GOOGLETEST OFF)set(ABSL_FIND_GOOGLETEST OFF)set(BUILD_TESTING OFF)set(ABSL_ENABLE_INSTALL OFF) # 시스템 설치 안 함ABSL_PROPAGATE_CXX_STD를 켜는 것이 거의 항상 정답이다.
#코드 리뷰 포인트
# 회피 — find_package(absl) 단독find_package(absl REQUIRED)# 시스템에 깔린 Abseil을 가정. 빌드 환경마다 결과가 다를 수 있다.
# Good — FetchContent로 명시적 버전 고정FetchContent_Declare(abseil-cpp GIT_TAG 20240722.0)# 회피 — Bazel WORKSPACE에 git_repository(branch="master")git_repository(name = "com_google_absl", remote = "...", branch = "master")# 빌드마다 다른 commit을 가져올 수 있음.
# Good — http_archive에 sha256 고정http_archive(name = "com_google_absl", sha256 = "f50e...", urls = [...])리뷰에서 봐야 할 것은 세 가지다.
- 버전이 명시되어 있는가 — branch가 아닌 tag/commit/sha256 고정.
- source build인가 prebuilt인가 — ABI 정책에 맞는지.
- C++ 표준이 일치하는가 —
ABSL_PROPAGATE_CXX_STD또는 동등한 설정.
#자주 보는 안티패턴
# 회피 — Abseil을 PUBLIC으로 exposetarget_link_libraries(my_lib PUBLIC absl::strings)# 사용자 코드가 자동으로 Abseil header를 보게 됨.# 사용자가 다른 버전의 Abseil을 쓰고 있다면 충돌.
# Good — 가능하면 PRIVATEtarget_link_libraries(my_lib PRIVATE absl::strings)# 인터페이스에 string_view 같은 type이 노출되면 어쩔 수 없이 PUBLIC.# 회피 — system Abseil + bundled Abseil 혼용find_package(absl REQUIRED)add_subdirectory(third_party/abseil-cpp) # 충돌#정리
- Bazel이 first-class, CMake가 동등한 second-class.
- vcpkg, Conan은 LTS만 다루고, source build가 ABI 안전성의 전제.
- CMake target은 sub-library 단위로 나뉘어 있다.
absl::all은 없다. - 버전 고정과 source build를 우선한다. branch 기반 fetch, prebuilt mix는 피한다.
#다음 편
Part 1-04에서 LTS와 HEAD의 차이를 깊이 본다. 어떤 프로젝트가 어느 모드를 선택해야 하는지, 모드 간 마이그레이션 비용이 얼마나 드는지를 다룬다.
#관련 항목
Abseil Code Review · 4 of 79
- 1 Abseil Code Review — Google production-grade C++ 라이브러리 분석
- 2 Abseil 개요 — Google이 std를 보완한 이유
- 3 Abseil 설계 철학 — std 호환과 추가 기능의 균형
- 4 Abseil 빌드와 의존성 — Bazel vs CMake
- 5 Abseil LTS vs HEAD 릴리스 모델 분석
- 6 Abseil Versioning과 ABI 호환성 정책
- 7 Abseil 매크로 — ABSL_HAVE_*·ABSL_ATTRIBUTE_*
- 8 Abseil ABSL_PREDICT_TRUE/FALSE — branch hint
- 9 absl::LogSeverity — 로그 레벨 타입
- 10 Abseil type_traits — negation·conjunction·void_t
- 11 Abseil Conformance·Policy 분석
- 12 Abseil Memory utilities 분석
- 13 Abseil raw_logging — heap-free 로깅
- 14 Abseil thread_annotations — clang TSA 통합
- 15 absl::Status — exception-free error handling
- 16 absl::StatusOr<T> — 값 또는 에러
- 17 absl status_macros — ASSIGN_OR_RETURN·RETURN_IF_ERROR
- 18 absl::Status payload — 구조화된 에러 컨텍스트
- 19 absl::Status ↔ exception 변환 패턴
- 20 absl::string_view — non-owning 문자열 참조
- 21 absl::string_view 함정 — dangling·c_str·임시 객체
- 22 absl::StrCat — 가변 인자 문자열 연결과 AlphaNum
- 23 absl::StrSplit — Delimiter·Predicate·컨테이너 변환
- 24 absl::StrJoin — 컨테이너 결합과 Formatter
- 25 absl::StrFormat — type-safe printf·FormatSpec
- 26 Abseil ASCII 함수 — locale-free 분류·대소문자 변환
- 27 Abseil Escape — CEscape·HexEscape·Base64
- 28 absl::flat_hash_map — Swiss Table 기반 hash map
- 29 absl::flat_hash_set — set 버전 Swiss Table
- 30 absl::node_hash_map — stable pointer가 필요할 때
- 31 absl::btree_map — sorted·cache-friendly B-tree
- 32 absl::FixedArray — 런타임 크기 stack 배열
- 33 absl::InlinedVector — small buffer optimization
- 34 Abseil Swiss Table internals — control byte·SIMD probing
- 35 absl::Mutex — reader-writer·fairness·deadlock 검출
- 36 absl::Mutex Conditional Critical Section — Await로 cv 없애기
- 37 absl::Notification — once-only signal
- 38 absl::BlockingCounter·Barrier — 다중 thread 조율
- 39 absl::Mutex annotations — clang thread-safety로 race를 컴파일 타임에
- 40 absl::Time·Duration 분석 — 단단한 type
- 41 absl::Time Format·Parse
- 42 absl::CivilTime 분석
- 43 absl::time_zone 분석
- 44 absl::Time mocking — 테스트 친화 시간
- 45 absl::BitGen — 모던 난수 생성기
- 46 Abseil Random Distributions — Uniform·Exponential
- 47 Abseil Mocking Random — 테스트 결정성
- 48 Abseil Random Seeding·Entropy
- 49 absl::int128·uint128 분석
- 50 absl::bits — popcount·countl_zero
- 51 absl::optional vs std::optional
- 52 absl::variant 분석
- 53 absl::span 분석
- 54 absl::any 분석
- 55 absl::compare — three-way 비교
- 56 Abseil utility — apply·in_place
- 57 Abseil AbslHashValue 분석
- 58 Abseil HashState chaining
- 59 Abseil Custom hashable 구현
- 60 Abseil LOG·VLOG·CHECK 분석
- 61 Abseil LogSink 분석
- 62 Abseil LogEntry·structured logging
- 63 Abseil Stack trace·failure_signal_handler
- 64 ABSL_FLAG 정의 분석
- 65 Abseil ParseCommandLine 동작
- 66 Abseil Flag introspection·validation
- 67 Google 스타일의 Abseil 사용 패턴
- 68 Abseil 자주 보는 anti-pattern
- 69 std → absl 마이그레이션 전략
- 70 absl::Cleanup — 함수 종료 시 실행 보장
- 71 Abseil algorithm container 확장 — c_sort·c_find_if·c_count_if
- 72 absl::function_ref와 any_invocable — 함수 객체 전달의 두 축
- 73 absl::bind_front와 Overload — 함수 객체 보조 도구
- 74 absl::Cord — 분산 시스템용 대용량 문자열
- 75 absl::from_chars·SimpleAtoi — 빠른 숫자 변환
- 76 absl::Cord vs std::string — 선택 기준과 메모리 프로파일
- 77 absl::GetStackTrace와 Symbolize — crash 시 readable stack
- 78 absl::ComputeCrc32c — 하드웨어 가속 체크섬
- 79 absl::PeriodicSampler — 적응형 샘플링·jitter 회피
관련 글
absl::PeriodicSampler — 적응형 샘플링·jitter 회피
absl::profiling_internal::PeriodicSampler — sampling rate를 동적으로 조정, geometric distribution으로 jitter 회피. 메모리 할당 추적·profiling 인프라의 기반.
같은 시리즈에서 이어 읽기
absl::ComputeCrc32c — 하드웨어 가속 체크섬
absl::ComputeCrc32c — SSE4.2 CRC32, ARM CRC 명령어로 가속된 CRC32C 구현. iSCSI·Btrfs·protobuf에서 표준화된 무결성 검사.
같은 시리즈에서 이어 읽기
absl::GetStackTrace와 Symbolize — crash 시 readable stack
absl::GetStackTrace로 PC 배열을 받고 absl::Symbolize로 함수 이름·파일·라인으로 변환. signal handler 안에서도 동작하는 async-safe API.
같은 시리즈에서 이어 읽기