-
Notifications
You must be signed in to change notification settings - Fork 4k
ARROW-17160: [C++] Create a base directory for PyArrow CPP header files #14275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
jorisvandenbossche
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is still the question about moving the include paths from "arrow/python/.." to "pyarrow/.." (and how to provide some transition path for this), but assuming the current status of exposing those as "arrow/python/.." (which seems the safe assumption for 10.0), this seems like a good change to use those paths in the code and headers itself.
I suggest we try to move the include paths from |
|
Could you create a separate JIRA issue for it? |
|
I am sorry for rerunning this travis ci job at https://app.travis-ci.com/github/apache/arrow/builds/256419696 while the job was already succeeded. |
No problem at all =) |
pitrou
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very much @AlenkaF !
|
@kou Do you have any other concerns? |
|
No. |
|
I will merge later today, if there is no objection =) |
|
The Python failure is one of the flaky dataset tests |
|
Thanks @AlenkaF ! |
|
Benchmark runs are scheduled for baseline = d8f3946 and contender = 21dbf4a. 21dbf4a is a master commit associated with this PR. Results will be available as each benchmark for each run completes. |
This PR is a follow-up of #13311 where it was decided to change the base directory for PyArrow C++ headers to avoid top level inclusions. See #13311 (comment)