Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

build: regression after #1021 — Arrow's arrow_SOURCE_DIR collides with FetchContent on CMake 3.28, breaks vendored Arrow build

已關閉
#1,028 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 3 天內回覆

@raulcd 已經在處理了。

開始於 2026年10月16日。

  • #1029 來自 @raulcd —— 未關閉

評估

難度
3/5
預估耗時
半天
新手友好度
22/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
停滯
技術堆疊
cmake, cpp
領域
build-system

研究方向

The collision comes from the FetchContent_Declare(Arrow ...) call that commit 31659e7 introduced in the top-level CMake files, and Arrow's cpp/cmake_modules/ThirdpartyToolchain.cmake, which reads arrow_SOURCE_DIR to find thirdparty/versions.txt. Reproduce by configuring with CMake 3.28 and checking the file(STRINGS) error. Done means configure succeeds on CMake 3.28 with vendored Arrow. Linked PR #1029 already targets this, so check it before starting.

由索引模型根據 Issue 內容生成。

描述

After #1021 (commit 31659e7), configuring iceberg-cpp with vendored Arrow fails on CMake 3.28 (Ubuntu 24.04 LTS). The rename of the FetchContent content name from VendoredArrow to Arrow creates a variable-name collision with Arrow's own project(arrow) call, which Arrow's cpp/cmake_modules/ThirdpartyToolchain.cmake relies on.

Environment

  • Ubuntu 24.04 LTS
  • CMake 3.28.3
  • GCC 14.2.0
  • Fresh clone of main

Reproduction

git clone https://github.com/apache/iceberg-cpp.git
cd iceberg-cpp
cmake -S . -B build -G Ninja -DCMAKE_C_COMPILER=gcc-14 -DCMAKE_CXX_COMPILER=g++-14

Error

CMake Error at build/_deps/arrow-src/cpp/cmake_modules/ThirdpartyToolchain.cmake:446 (file):
file STRINGS file
"/_deps/arrow-src/thirdparty/versions.txt"
cannot be read.

The file actually lives at _deps/arrow-src/cpp/thirdparty/versions.txt (inside cpp/). Because versions.txt can't be read, all *_BUILD_SHA256_CHECKSUM variables become empty and the subsequent Boost ExternalProject_Add fails with URL_HASH SHA256= (empty).

Root cause

Arrow's cpp/cmake_modules/ThirdpartyToolchain.cmake sets:

set(THIRDPARTY_DIR "${arrow_SOURCE_DIR}/thirdparty")

In a standalone Arrow build, project(arrow) in cpp/CMakeLists.txt sets arrow_SOURCE_DIR to the cpp/ directory. But when Arrow is pulled in by iceberg-cpp via FetchContent_Declare(Arrow ...), CMake pre-sets arrow_SOURCE_DIR to the tarball root (parent of cpp/). On CMake 3.28, the subsequent project(arrow) does not override the inherited arrow_SOURCE_DIR — PROJECT_SOURCE_DIR is updated, but arrow_SOURCE_DIR keeps the FetchContent value.

Verified with a minimal repro:

cmake_minimum_required(VERSION 3.25)
project(TestFC)

cmake_minimum_required(VERSION 3.25)
project(TestFC)
include(FetchContent)
FetchContent_Declare(Arrow URL file:///path/to/apache-arrow-25.0.0.tar.gz SOURCE_SUBDIR cpp)
FetchContent_Populate(Arrow)

arrow_SOURCE_DIR is set by FetchContent to the tarball root

Add a subdir that calls project(arrow)

→ PROJECT_SOURCE_DIR updates to /subdir, but arrow_SOURCE_DIR does NOT change

Before #1021 this worked because the FetchContent name was VendoredArrow (variable vendoredarrow_SOURCE_DIR), separate from Arrow's own arrow_SOURCE_DIR.

Why CI didn't catch it

CI runs on ubuntu-26.04, which ships a newer CMake. Either the newer CMake behaves differently for project() overrides, or a system Arrow is picked up by FIND_PACKAGE_ARGS CONFIG. Either way, CMake 3.28 on Ubuntu 24.04 LTS — the current widely-used LTS — isn't exercised.

Suggested fix

Rename back to VendoredArrow (or any name other than Arrow/arrow) to avoid the collision. Alternatively, consider adding ubuntu-24.04 with its stock CMake to the CI matrix.

Workaround

git revert 31659e7 locally.

主要語言
C++
星號
230
分支
138
平均合併
4 天 2 小時
30 天內合併 PR
61

環境準備

這個專案沒有提供開發容器、Dockerfile 或貢獻指南,環境需要你自己搭建:先看它的 README,通用步驟見我們的新手貢獻指南。

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

apache/iceberg-cpp 的其他 Issue

查看 apache/iceberg-cpp 的全部 Issue

相似的 Issue

更多 C++ Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。