Skip to content

fix UR_DDI python class init #94

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

Merged
merged 1 commit into from
Dec 8, 2022

Conversation

pbalcer
Copy link
Contributor

@pbalcer pbalcer commented Dec 8, 2022

This patch fixes all issues that were preventing the python bindings from initializing the loader.

This patch fixes all issues that were preventing the python
bindings from initializing the loader.
@pbalcer
Copy link
Contributor Author

pbalcer commented Dec 8, 2022

The loader PR has a conflict with the recent change to the pull_request.yml workflow (which I'm removing in favor of one that uses cmake targets) that added a check to verify if the python module even imports (#89). That inspired me to add simple test infrastructure using ctest and create a python that actually tried to run the python bindings. This was so that I could add running ctest to the cmake workflow.

Predictably, the python module didn't work ;) Hence this patch.

Once this is merged, I'll either update the loader PR to include the test or create a new PR.

Copy link
Contributor

@FranklandJack FranklandJack left a comment

Choose a reason for hiding this comment

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

LGTM.

Copy link
Contributor

@kbenzie kbenzie left a comment

Choose a reason for hiding this comment

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

LGTM

@FranklandJack FranklandJack merged commit 620c599 into oneapi-src:main Dec 8, 2022
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.

3 participants