DRAFT: Add first cut of clik jobs #587
Conversation
.github/workflows/run_pr_tests.yml
Outdated
| - name: Checkout repo | ||
| uses: actions/[email protected] | ||
| - name: setup-ubuntu | ||
| uses: ./.github/actions/setup_build |
There was a problem hiding this comment.
I don't think clik requires llvm so maybe we can get rid of that part - it's also so fast I'm not sure we need the cache, but if we do we should be consistent below.
There was a problem hiding this comment.
we also don't need vulkan sdk, I'm wondering if we should not bother calling setup_ubuntu and just install ninja if needed (or add a few more args so we get the basics). That also has advantages in showing how simple it is to use.
There was a problem hiding this comment.
I wondered about that for this job. Both clik jobs are green now so I'll investigate a minimal preamble.
.github/workflows/run_pr_tests.yml
Outdated
| - run: LD_PRELOAD=/lib/x86_64-linux-gnu/libpthread.so.0 ninja -Cbuild_clik check | ||
|
|
||
| # Based on: mr-ubuntu-gcc-x86_64-clik-refsi | ||
| run-ubuntu-gcc-x86_64-clik-refsi: |
There was a problem hiding this comment.
just a thought since the start overheads seem bigger than the actual run-time, maybe just combine into one job (but two different steps).
There was a problem hiding this comment.
OK - I'll do that. Jobs are green with just a ninja install.
.github/workflows/run_pr_tests.yml
Outdated
| echo WORKSPACE is $GITHUB_WORKSPACE && echo PWD is `pwd` && ls -al | ||
| cmake -Bbuild_clik -GNinja -DCMAKE_INSTALL_PREFIX=install clik | ||
| LD_PRELOAD=/lib/x86_64-linux-gnu/libpthread.so.0 ninja -Cbuild_clik check | ||
| - name: Clean |
There was a problem hiding this comment.
can't you just use a different build directory below - no need to clean.
Overview
Provide a brief overview of what your changes do, summarizing their effects
and consequences.
Reason for change
Describe how the current behaviour of the project is causing problems for you
or is otherwise unsatisfactory for your use case.
Description of change
Describe the intended behaviour your changes are meant to introduce to the
project and explain how they resolve the problem stated above. Detail any
relevant changes that may affect other users of the project, such as
compilation options, runtime flags, expected inputs and outputs, API entry
points, etc.
If you have added new testing, provide details on what tests you have added
and what the purpose of them is.
Anything else we should know?
If there's any other relevant information we should know that may help us in
understanding and verifying your patch, please include it here.
Checklist