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

Fix test for pybind11 include on conda #43

Closed
wants to merge 5 commits into from

Conversation

henryiii
Copy link
Contributor

@henryiii henryiii commented Jan 15, 2020

Checklist

  • Used a fork of the feedstock to propose changes
  • Bumped the build number (if the version is unchanged)
  • Reset the build number to 0 (if the version changed)
  • Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
  • Ensured the license file is being packaged.

This fixes the tests to make sure that the pybind11 include exists, rather than just assuming the base folder is the correct one. I expect this to fail, since currently the conda package does report the correct include directory.

@conda-forge-linter
Copy link
Contributor

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@henryiii
Copy link
Contributor Author

@conda-forge-admin, please rerender

@henryiii
Copy link
Contributor Author

henryiii commented Jan 15, 2020

The problem is that this installs the header folder to ${PREFIX}/include/python3.8/* (etc) but reports ${PREFIX}/include for the include directory.

@ax3l
Copy link
Member

ax3l commented Jan 16, 2020

Thank you for the report!
Wait, this is likely due to an adoption of the include logic and imho a bug. (But I cannot reproduce this issue, all tests are green here.) Please do not simply the test for simple file existence, we want to ensure the headers stay placed as we advertise them.

Do you see that issue only in local builds or also on CF? Cannot see an issue on master and the latest include logic update is not yet released.

Refs.:

Copy link
Member

@ax3l ax3l left a comment

Choose a reason for hiding this comment

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

Please do NOT check only for file existence, that will always be true and is not what these two tests try to verify.
The modified test case checks that the files are installed where we intend them to be placed, according to conda-forge conventions. (We can additionally check if they exist.)

@henryiii
Copy link
Contributor Author

Please do NOT check only for file existence, that will always be true

No, it was not true, this is why the PR failed until the patch was applied. The expected behavior is that pybind11.get_include() will return the include directory that contains the pybind11 folder with the pybind11 headers. It was not doing so. It was returning $PREFIX/include, which only contained pythonX.X.

It's a separate issue if that include directory is not the directory that is expected on conda that will also need fixing. I believe that this is being set by

-DUSE_PYTHON_INCLUDE_DIR=ON \

But only for unix (it's not in bld.bat), so I think on unix systems this is going into the nested folder. We can test this too, but we need to know whether it's supposed to be $PREFIX/include or $PREFIX/include/pythonX.X on conda.

@henryiii
Copy link
Contributor Author

(I can test this out locally later and will update if we need to change the include location)

@ax3l ax3l mentioned this pull request Jan 18, 2020
5 tasks
@ax3l
Copy link
Member

ax3l commented Jan 18, 2020

Okay, I think the actual patch we need for CF is to avoid writing the nested (sub)folder in the first place.

@ax3l
Copy link
Member

ax3l commented Jan 18, 2020

Got it, it's a unix-only problem, a leftover from #32.
Patch proposed in #44, thanks again for spotting this! Dang, how could we forgot to check as well for file existence...

@ax3l
Copy link
Member

ax3l commented Jan 18, 2020

Thank you again for your spotting and reporting this!
I applied the patch for Unix in #44 and will close this PR so it does not get accidentally merged.

@ax3l ax3l closed this Jan 18, 2020
@henryiii
Copy link
Contributor Author

henryiii commented Jan 18, 2020

44 and this PR are identical, by the way. Only change is I forgot to delete the unused patch. It's okay, though.

@ax3l
Copy link
Member

ax3l commented Jan 18, 2020

Cheese, I did not see that you also adjusted build.sh in the last diff. Sorry for that! The additional patch that you applied is still in this PR though and should not be in (remconda.patch ).

Yes, this commit is the central one: f649a31

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.

None yet

3 participants