Skip to content
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

bpo-30912: Don't check ffi.h for specific contents #2687

Merged
merged 1 commit into from
Sep 6, 2017

Conversation

shlomif
Copy link
Contributor

@shlomif shlomif commented Jul 12, 2017

See http://bugs.python.org/issue30912 - ffi.h does not match the
substrings on Mageia v6. Now we just check that it is not empty,
otherwise it is not our problem. Notifying @zware per his request.

@the-knights-who-say-ni
Copy link

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Unfortunately we couldn't find an account corresponding to your GitHub username on bugs.python.org (b.p.o) to verify you have signed the CLA (this might be simply due to a missing "GitHub Name" entry in your b.p.o account settings). This is necessary for legal reasons before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

Thanks again to your contribution and we look forward to looking at it!

setup.py Outdated
@@ -2003,11 +2003,11 @@ def detect_ctypes(self, inc_dirs, lib_dirs):
ffi_inc = find_file('ffi.h', [], inc_dirs)
if ffi_inc is not None:
ffi_h = ffi_inc[0] + '/ffi.h'
# Just check that the file is not empty
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checking that the header exists and not empty is strange. If you install an empty ffi header failing the build seems like the best way.

I would check why the code checking for LIBFFI_H was added.

If we really want to know if there is a non empty file we can just do:

os.path.getsize(ffi_h) > 0

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on my "git blame"-fu it was introduced by this commit which is a large merge commit from a non-existent branch in the git repo:

commit 49fd7fa
Author: Thomas Wouters [email protected]
Date: Fri Apr 21 10:40:58 2006 +0000

Merge p3yk branch with the trunk up to revision 45595. This breaks a fair
number of tests, all because of the codecs/_multibytecodecs issue described
here (it's not a Py3K issue, just something Py3K discovers):
http://mail.python.org/pipermail/python-dev/2006-April/064051.html

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the real origin is bpo-1464444, in which @doko42 noted that the check for #define LIBFFI_H may or may not be worth much. At this point, I don't think we need to even check that there is anything in the file, just that ffi.h exists.

@shlomif
Copy link
Contributor Author

shlomif commented Jul 13, 2017 via email

'ffi_wrapper_h'.format(ffi_h))
if not os.path.exists(ffi_h):
ffi_inc = None
print('Header file {} does not exist'.format(ffi_h))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

But we need a proper commit message describing this change. The previous patch commit message is not relevant any more, and this patch commit message is not useful. People looking at python git history should not have to search github pull requests comments.

I think the proper way to do this would be to fixup this change into the previous patch, and upgrade the commit message to describe the actual change.

@shlomif shlomif force-pushed the issue30912-find-libffi-on-mageia branch from 4b4956a to 4b85973 Compare July 14, 2017 17:41
@shlomif
Copy link
Contributor Author

shlomif commented Jul 14, 2017 via email

@nirs
Copy link
Contributor

nirs commented Jul 14, 2017

The body of the commit message looks ok, but the title:

Fix issue30912 - cannot find "ffi.h" w multiarch.

Does not match other commits in the git log. I don't know if this is required, but I would
use this for consistency:

bpo-30912: Fixed cannot find "ffi.h" with multiarch

@zware
Copy link
Member

zware commented Jul 14, 2017

@nirs, @shlomif Don't worry about the commit messages or squashing commits. Leave that to the core contributor who merges the PR. The merge is done by GitHub's 'squash and merge' option, and the merger has to make some edits to the message anyway.

@zware zware changed the title bpo-30912: fix issue30912 - cannot find "ffi.h" with multiarch. bpo-30912: Don't check ffi.h for specific contents Jul 14, 2017
Copy link
Contributor

@nirs nirs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, but I think @doko42 should approve this, since he added the code removed by this patch.

See http://bugs.python.org/issue30912 - ffi.h does not match the
substrings on Mageia v6. Now we just check that it exists,
otherwise it is not our problem.

(Fixed per the comments on the pull-req at
python#2687 (comment) . ).
@shlomif shlomif force-pushed the issue30912-find-libffi-on-mageia branch from 4b85973 to 4aadd1c Compare July 14, 2017 18:30
@@ -2003,16 +2003,9 @@ def detect_ctypes(self, inc_dirs, lib_dirs):
ffi_inc = find_file('ffi.h', [], inc_dirs)
if ffi_inc is not None:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't checked the implementation of find_file, but it looks like it probably takes care of the os.path.exists check and I'm not sure that the printed message is worth a whole lot in the grand spam of things. Could you check on that and probably just remove this whole branch?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zware: the problem is that find_file does not always get called and moreover that message may be useful to pinpoint a build problem,

@shlomif
Copy link
Contributor Author

shlomif commented Aug 23, 2017

Hi all!

Do you need anything else from me or may this pull-req be merged already? It's been over a month.

@zware
Copy link
Member

zware commented Aug 23, 2017

I agree with @nirs that it would be nice to have @doko42's input. If we don't get that before the first week of September, I'll merge it then.

@shlomif
Copy link
Contributor Author

shlomif commented Aug 23, 2017

@zware : thanks! I can wait for now.

@zware zware merged commit 6d51b87 into python:master Sep 6, 2017
@shlomif
Copy link
Contributor Author

shlomif commented Sep 7, 2017

Thanks for merging it and thus fixing the problem, @zware! Also thanks to @nirs for the commentary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants