Skip to content

Automated build process with GitHub actions - #115

Merged
gpufit merged 2 commits into
gpufit:masterfrom
JKISoftware:automated-build-process
Oct 14, 2022
Merged

Automated build process with GitHub actions#115
gpufit merged 2 commits into
gpufit:masterfrom
JKISoftware:automated-build-process

Conversation

@jimkring

Copy link
Copy Markdown
Contributor

Support for Windows and Ubuntu builds:

- os: windows-2019
  cuda: "11.4.0"
  visual_studio: "Visual Studio 16 2019"
  python: "3.9"

- os: ubuntu-20.04
  cuda: "11.4.0"
  python: "3.9"

@jimkring

Copy link
Copy Markdown
Contributor Author

@gpufit
gpufit merged commit 2f3f4fa into gpufit:master Oct 14, 2022
@jimkring
jimkring deleted the automated-build-process branch October 15, 2022 05:04
jimkring added a commit to JKISoftware/Gpufit-fork that referenced this pull request Oct 18, 2022
@gpufit

gpufit commented Oct 20, 2022

Copy link
Copy Markdown
Owner

The build on linux is currently failing, but passing on windows. Confusing since I can’t see anything in the latest commits which could cause a linux-specific failure

@jimkring

Copy link
Copy Markdown
Contributor Author

@gpufit I'm not sure why the python wheel isn't building.

That said, the cmake updates (from @ironictoo) in PR #94 fix the build -- I verified this in my own fork by merging PR #94 branch into the latest Gpufit main which triggered a CI build that worked just fine.

@ironictoo

Copy link
Copy Markdown

This is a problem using the deprecated find_package(pythonInterp) instead of find_package(python). Cmake is trying to use python 3.9.14 (the default Ubuntu version), and wheel gets setup on 3.9.15 (the version we install and configure). Probably the install python scripts were updated to version 3.9.15 in the last few days, but the default ubuntu install is still 3.9.14. I'm guessing before they were both on 3.9.14 before (when it worked) so it didn't matter if CMake screwed up, but now it does. This is because the old CMake function doesn't respect the common environment variables that are set to indicate the "correct" python to use.

As Jim said, this is fixed in PR #94

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