Files
arrow/cpp/subprojects
Narendra 1998ed3556 GH-51007: [C++] Make uriparser an external dependency (#51244)
### Rationale for this change

The vendored uriparser in `cpp/src/arrow/vendored/uriparser/` is 0.9.3, which is old and misses upstream security fixes. Instead of refreshing the vendored copy, this makes uriparser an external dependency like our other third-party dependencies.

### What changes are included in this PR?

- Add `uriparser` to `ARROW_THIRDPARTY_DEPENDENCIES`
- Add `build_uriparser()` that builds uriparser 1.0.2 with `FetchContent` for `uriparser_SOURCE=BUNDLED` (static; docs, tests, tools and `wchar_t` support are disabled). The built library is bundled into `arrow_bundled_dependencies`.
- Require uriparser 0.9.6 or later for `uriparser_SOURCE=SYSTEM`. All uriparser APIs used by Arrow are available in 0.9.6, so supported platforms such as Ubuntu 22.04 can use their distribution package.
- Add `cmake_modules/FinduriparserAlt.cmake`. It tries uriparser's CMake package configuration first and falls back to pkg-config (`liburiparser.pc`), because Debian and Ubuntu's `liburiparser-dev` provides only the pkg-config file.
- Add `uriparser::uriparser` to `ARROW_STATIC_INSTALL_INTERFACE_LIBS` for `uriparser_SOURCE=SYSTEM`, so that static library users link uriparser.
- meson: Use the system uriparser 0.9.6 or later if available. Otherwise, build uriparser 1.0.2 via `subprojects/uriparser.wrap` with the CMake subproject support.
- Remove `cpp/src/arrow/vendored/uriparser/` and its section in `LICENSE.txt`.
- Packaging: Install uriparser in our Docker images, conda environment, `Brewfile`, vcpkg manifests, MSYS2 setup and Linux packages build environments.
- Packaging: Pass `-Duriparser_SOURCE` in `ci/scripts/cpp_build.sh`.
- Packaging: Add uriparser to the dependency list in `docs/source/developers/cpp/building.rst`.

***NOTICE*** : The floor is 0.9.6 rather than 1.0.2, so supported platforms such as Ubuntu 22.04 can use their distro package and CI does not have to build uriparser from source. 

### Are these changes tested?

All existing tests pass. 

### Are there any user-facing changes?

Now Arrow requires uriparser or builds it . No user facing changes as such because no API changes . 

**This PR contains a "Critical Fix".** It has security fixes that has gone in uriparser. 

**AI Usage**:
- Used for testing <-> building loop. 

* GitHub Issue: #51007

Authored-by: Narendra <naskastark11@gmail.com>
Signed-off-by: Raúl Cumplido <raulcumplido@gmail.com>
2026-10-01 08:54:40 +02:00
..

Meson Subprojects

The contents of this directory are exclusively used by the Meson build configuration to manage project dependencies. The Meson documentation for this functionality can be found at https://mesonbuild.com/Subprojects.html

To summarize, Arrow relies upon other projects to successfully compile and link. In the case that those dependencies cannot be found on the host system, Meson by convention forces users to place those dependencies in the subprojects directory at the root of the project.

The easiest way to populate subprojects is to use Meson's WrapDB system. To illustrate how this works, let's take a look at the googletest library that Arrow depends upon for its test system. To create that as a subproject, a developer once ran:

meson wrap install gtest

From the project root directory. From that invocation, Meson creates the subprojects/gtest.wrap file which instructs the build system where it can get the source for gtest (if required), optionally alongside any "patch files" required to build gtest. If a project uses Meson natively, there is no need for patch files. However, if the project uses another build system (in the case of gtest , Bazel or CMake), then the patch files are user-created Meson configuration files that still expose the required build targets, without being a full rewrite of the native build generator. For an example of a user-created patch file for googletest, check out https://github.com/mesonbuild/wrapdb/tree/9e3862083a250680061aa46e8746499c419ad43c/subprojects/packagefiles/gtest

If you depend upon a project that is not available in Meson's WrapDB system, you may still be able to have Meson auto-generate a wrapper for it. An example of this is the subprojects/azure.wrap, which looks like:

[wrap-file]
source_url = https://github.com/Azure/azure-sdk-for-cpp/archive/azure-identity_1.9.0.tar.gz
source_filename = azure-sdk-for-cpp-azure-identity_1.9.0.tar.gz
source_hash = 97065bfc971ac8df450853ce805f820f52b59457bd7556510186a1569502e4a1
directory = azure-sdk-for-cpp-azure-identity_1.9.0
method = cmake

The method = cmake line is important here; it instructs Meson to inspect any CMakeLists.txt files from the downloaded source and auto generate Meson configuration files therefrom. The generated meson.build configuration(s) will be placed in <build_directory>/subprojects/<subproject_name> at project configuration time.

In the default case, Meson will use the wrap file as a fallback. If a dependency can be satisfied by the system, then it will not use the wrap file to download any sources. However, you can toggle the behavior of the wrap system via the --wrap-mode= configuration option. --wrap-mode=forcefallback will always download and use the source defined in a wrap file, even if the dependency could be satisfied by the system. By contrast, --wrap-mode=nofallback will require that the system satisfies dependencies. For more ways to handle wrap dependencies, see https://mesonbuild.com/Subprojects.html#commandline-options

For more information on Meson's wrap system, see also https://mesonbuild.com/Wrap-dependency-system-manual.html

In the majority of cases you will be using wrap files to describe subprojects, although it is not always required. You could alternatively place a copy of the third party project into the subprojects directory, if your preference is to completely vendor it.