GH-46067: [CI][C++] Remove system Flatbuffers from macOS #46105
Conversation
|
@github-actions crossbow submit verify-rc-source-cpp-macos-amd64 |
|
Revision: b27bf7e Submitted crossbow builds: ursacomputing/crossbow @ actions-4ebe73daec
|
|
@kou maybe this is viable? Or we should pin the version of flatbuffers used in the Brewfile? |
|
@github-actions crossbow submit verify-rc-source-ruby-macos-amd64 |
|
@github-actions crossbow submit verify-rc-source-*-macos-arm64 |
|
Revision: b27bf7e Submitted crossbow builds: ursacomputing/crossbow @ actions-febc5892d7
|
kou
left a comment
kou
left a comment
There was a problem hiding this comment.
+1
Yes. We can use this for 20.0.0. But I feel that this is a workaround... I think that our build should work with system Flatbuffers (that isn't 24). In the case, we should use bundled Flatbuffers not system Flatbuffers.
|
Revision: b27bf7e Submitted crossbow builds: ursacomputing/crossbow @ actions-4c932a1672
|
github-actions
bot
added
awaiting merge
|
I believe flatbuffers requires that the version used to generate the code must be exactly the same version used to compile the code. So from that perspective the Arrow build system dependency should either be vendored, or you would have to ensure your system has the exact same version |
|
Right. We're using the vendored approach. So I think that we should use the vendored Flatbuffers even when there is a system Flatbuffers. (I think that it's a real fix.) |
kou
changed the title
|
After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit 32641ec. There were no benchmark performance regressions. 🎉 The full Conbench report has more details. It also includes information about 20 possible false positives for unstable benchmarks that are known to sometimes produce them. |
|
@github-actions crossbow submit verify-rc-source-*-macos-amd64 |
|
Revision: b27bf7e Submitted crossbow builds: ursacomputing/crossbow @ actions-34dfae5216
|
### Rationale for this change Flatbuffers statically requires that the version used to generate the prototypes within the code base is the same version used to compile it. A system install of Flatbuffers is therefore highly unlikely to be usable ### What changes are included in this PR? Removed the system install of Flatbuffers on macOS ### Are these changes tested? In CI ### Are there any user-facing changes? No * GitHub Issue: #46067 Authored-by: Will Ayd <[email protected]> Signed-off-by: Sutou Kouhei <[email protected]>
…e#46105) ### Rationale for this change Flatbuffers statically requires that the version used to generate the prototypes within the code base is the same version used to compile it. A system install of Flatbuffers is therefore highly unlikely to be usable ### What changes are included in this PR? Removed the system install of Flatbuffers on macOS ### Are these changes tested? In CI ### Are there any user-facing changes? No * GitHub Issue: apache#46067 Authored-by: Will Ayd <[email protected]> Signed-off-by: Sutou Kouhei <[email protected]>
…e#46105) ### Rationale for this change Flatbuffers statically requires that the version used to generate the prototypes within the code base is the same version used to compile it. A system install of Flatbuffers is therefore highly unlikely to be usable ### What changes are included in this PR? Removed the system install of Flatbuffers on macOS ### Are these changes tested? In CI ### Are there any user-facing changes? No * GitHub Issue: apache#46067 Authored-by: Will Ayd <[email protected]> Signed-off-by: Sutou Kouhei <[email protected]>
3 participants
Rationale for this change
Flatbuffers statically requires that the version used to generate the prototypes within the code base is the same version used to compile it. A system install of Flatbuffers is therefore highly unlikely to be usable
What changes are included in this PR?
Removed the system install of Flatbuffers on macOS
Are these changes tested?
In CI
Are there any user-facing changes?
No