GH-47039: [C++] Bump RapidJSON dependency in Meson configuration #47041
Conversation
|
|
kou
changed the title
|
How about migrating to simdjson from RapidJSON instead? |
|
Sure I can take a look. Although I think there is still value in bumping this in the meantime, since it was done for CMake too |
WillAyd
force-pushed
the
fix-meson-rapidjson
branch
from
76afe86 to
1a381f9
Compare
|
I commented on the upstream discussion, but it unfortunately looks like SIMDJSON does not offer serialization support, so I don't think it would be suitable to replace RAPIDJSON completely any time soon |
cpp/src/arrow/meson.build
Outdated
| rapidjson_proj = subproject('rapidjson') | ||
| rapidjson_dep = rapidjson_proj.get_variable('rapidjson_dep') |
There was a problem hiding this comment.
Does this mean that we always use bundled RapidJSON?
Can we use bundled RapidJSON only when system RapidJSON is old?
There was a problem hiding this comment.
Yes that was the intent here. In theory we could do what you are looking for with the version argument of the dependency call, but I am not sure how that would work with RapidJSON given there haven't been any official releases in 9 years
There was a problem hiding this comment.
Hmm. I think that most distributions such as Debian, Ubuntu, AlmaLinux and conda ships patched RapidJSON. So we can use system RapidJSON in most distributions.
I think that it's a problem that the current Meson configuration doesn't detect system RapidJSON: #47318 (comment)
Anyway, let's use this approach. Because this will be removed sooner or later. We'll migrate to simdjson: #35460
github-actions
bot
added
awaiting changes
cpp/subprojects/rapidjson.wrap
Outdated
| source_fallback_url = https://github.com/mesonbuild/wrapdb/releases/download/rapidjson_1.1.0-2/rapidjson-1.1.0.tar.gz | ||
| wrapdb_version = 1.1.0-2 | ||
| directory = rapidjson-232389d4f1012dddec4ef84861face2d2ba85709 | ||
| source_url = https://github.com/miloyip/rapidjson/archive/232389d4f1012dddec4ef84861face2d2ba85709.tar.gz |
There was a problem hiding this comment.
| source_url = https://github.com/miloyip/rapidjson/archive/232389d4f1012dddec4ef84861face2d2ba85709.tar.gz | |
| source_url = https://github.com/Tencent/rapidjson/archive/232389d4f1012dddec4ef84861face2d2ba85709.tar.gz |
cpp/src/arrow/meson.build
Outdated
| rapidjson_proj = subproject('rapidjson') | ||
| rapidjson_dep = rapidjson_proj.get_variable('rapidjson_dep') |
There was a problem hiding this comment.
Hmm. I think that most distributions such as Debian, Ubuntu, AlmaLinux and conda ships patched RapidJSON. So we can use system RapidJSON in most distributions.
I think that it's a problem that the current Meson configuration doesn't detect system RapidJSON: #47318 (comment)
Anyway, let's use this approach. Because this will be removed sooner or later. We'll migrate to simdjson: #35460
github-actions
bot
added
awaiting merge
WillAyd
force-pushed
the
fix-meson-rapidjson
branch
from
ecfe6b1 to
96cfc70
Compare
WillAyd
force-pushed
the
fix-meson-rapidjson
branch
from
96cfc70 to
d7d2da2
Compare
| if needs_json or needs_integration | ||
| rapidjson_dep = dependency('rapidjson', include_type: 'system') | ||
| rapidjson_dep = dependency( | ||
| 'RapidJSON', |
There was a problem hiding this comment.
@kou thanks for pointing out #47318 (comment) - that was really helpful. This should fix the issue
|
System RapidJSON was found: https://github.com/apache/arrow/actions/runs/16994828223/job/48182918285?pr=47041#step:6:502 |
|
After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit 15662e6. There weren't enough matching historic benchmark results to make a call on whether there were regressions. The full Conbench report has more details. |
2 participants
Rationale for this change
The Meson configuration is unusable on gcc 14.2 given issues with the RapidJSON release of 1.1.0 (released in 2016)
What changes are included in this PR?
Bumps the RapidJSON version to a commit hash that matches what is used in CMake by default
Are these changes tested?
Yes
Are there any user-facing changes?
No