Build artifact and release assets #13
Conversation
|
With the latest change I created a new test tag https://github.com/henning-gerhardt/mfakto/releases/tag/v0.0.3. The build artifacts are available under https://github.com/primesearch/mfakto/actions/runs/12095551380 for the latest changes of this pull request. After this change is merged they are available under https://github.com/primesearch/mfakto/actions -> Commit name -> Artifacts |
|
I pulled down mfakto-v0.0.2-windows-msvc. Self tests passed. Windows 11, RDNA3 7700 XT.
|
|
Thank you for testing this build, jcoxdco. I'm hoping that the builds are helping everyone who want to use mfakto. |
.github/workflows/ci.yml
Outdated
| uses: actions/upload-artifact@v4 | ||
| with: | ||
| name: mfakto-windows-msvc | ||
| path: x64/Debug/ |
There was a problem hiding this comment.
Does this package the debug build? I believe the release build would a better choice, especially for the users who download the binary without the sources.
There was a problem hiding this comment.
Currently the debug build was in place which I used. A release build should be possible too. I must try it how to do this as I have only GitHub to build the Windows build.
There was a problem hiding this comment.
I adjusted the build process to use a release build. I'm hoping this is working. Can someone please test it? Build should be available in a few minutes.
| if: startsWith(github.ref, 'refs/tags/') | ||
| with: | ||
| files: | | ||
| mfakto-windows-msys2.zip |
There was a problem hiding this comment.
What's the rationale for making two different builds for Windows available for download? The CI script checks two documented ways to build mfakto for Windows. Developers would care, as they use one or another. But why should the end users care?
There was a problem hiding this comment.
I don't know. I did only extending the existing builds. Which version is the better one on Windows?
There was a problem hiding this comment.
It should be tested. Generally, the faster version should be used. If there is no significant difference in speed, I would go with MSYS2 because it's open source and because it shares the build system with Linux (the same compiler, the same compiler flags).
| - name: Upload build artifact | ||
| uses: actions/upload-artifact@v4 | ||
| with: | ||
| name: mfakto-${{ matrix.os }} |
There was a problem hiding this comment.
I downloaded mfakto-macos-13.zip and tried running it on a Mac. I got
Select device - Error: No platform found
ERROR: init_CL(3, 0) failed
That can be expected, as the binary is linked against pocl rather than against the MacOS OpenCL library. I believe separate builds would be needed to test mfakto with pocl and to distribute mfakto that uses the actual OpenCL.
Also, the binary names are misleading. The main difference between macos-13 and macos-14 on GitHub is that macos-13 is x86_64 and macos-14 is aarch64. It might be possible to make a fat binary to support both architectures.
There was a problem hiding this comment.
You error message is good to know. How did the previous executed test success on GitHub but not on your system? I'm familiar only with Linux and do only guessing how it could work on Windows and MacOS.
There was a problem hiding this comment.
I believe the mfakto version compiled against pocl would look for pocl. If pocl is not installed, mfakto won't fall back to the native OpenCL drivers. The only reason to use pocl is to run tests without any GPUs. The users who download the binary are expected to have a GPU and are not expected to have pocl.
There was a problem hiding this comment.
I removed the pocl dependency from MacOS build but without this dependency the executed tests on MacOS on GitHub did not work anymore. For Windows builds there are no tests executed too so it should be okay for now.
There was a problem hiding this comment.
We'll need two different builds, one for testing and another for distribution. We can only avoid it if it's possible to use the OpenCL linked binaries to use pocl at the runtime, but I read somewhere that it's impossible on MacOS, so I didn't try.
There was a problem hiding this comment.
I see 3 possible options:
- use the current version as is without test execution on the MacOS builds
- use different builds for CI and making the builds file available. But this has 2 disadvantages: more files to maintain and if the CI build is failing then the other build will be continue
- extend the current CI build for MacOS: Build with the
pocldependency and execute the tests. Then additionalmake cleanrun and a normalmakerun without thepocldependency and use this build for the downloadable files.
There was a problem hiding this comment.
The number 3 would be the best.
There was a problem hiding this comment.
I will try option 3 but this must wait a few days as I'm now on vacation.
There was a problem hiding this comment.
Back from vacation and I adjusted the MacOS build with option 3: additional make clean run and a make run without the pocl dependency in use.
@proski can you verify that both MacOS executables are now correct build? They are available at https://github.com/henning-gerhardt/mfakto/actions/runs/12893233610#artifacts
There was a problem hiding this comment.
Yes, I can confirm that the macos-13 build is working on an Intel iMac with a Radeon.
This pull request may superseed #12.
Instead of running two workflows and two possible different builds the created files from the CI workflow are used to create even the release builds assets. Benefit is that every build now create all artifacts assets for every operation system so even without a release every one on every supported operation system can try the most recent version out without the need to build mfakto itself.
I discovered too how to build the artifact and release assert on windows-msvc. This can even be pack ported to #12 if two independent build workflows should be used.
I could only test the created Linux based assets in a successful way, so Windows and MacOS should be tested who can access them.
Edit: