search

sudara / pamplejuce

A JUCE audio plugin template. JUCE 7, Catch2, Pluginval, macOS notarization, Azure Trusted Signing, Github Actions
https://melatonin.dev/blog/
MIT License
372 stars 36 forks source link

IPP Cache on Windows broken #68

Closed tobiashienzsch closed 5 months ago

tobiashienzsch commented 6 months ago

Example Workflow: https://github.com/sudara/pamplejuce/actions/runs/6990519747/job/19020107980

I have/had the same issue, when copying your 3 yaml steps to another project of mine. Same issue.

My many attempts:

https://github.com/neo-sonar/neo-dsp/actions

My CMake script fails when IPP is not found, so maybe that's why you have not noticed it here.

tobiashienzsch commented 6 months ago

Relates to #49

sudara commented 6 months ago

OK, this also interfaces with #56, as apparently there are less heavy ways to install IPP only (maybe some call will need to be made about excluding MKL)

sudara commented 6 months ago

Thanks a lot for reporting this! We should probably break the build if IPP isn't present, just need to make sure we don't break downstream builds for people who don't care about IPP (which is probably 95% of people)

tobiashienzsch commented 6 months ago

I tried the python packages on fedora a couple of days ago, but no luck. But I didn't do much troubleshooting either. So who knows...

tobiashienzsch commented 5 months ago

Found this forum post. Might help. Problem seems to be the symlink to latest is lost.

https://community.intel.com/t5/Intel-Fortran-Compiler/Cache-restore-fails-on-Windows-worker-on-Github-Actions/m-p/1406814

sudara commented 5 months ago

@tobiashienzsch Good sleuthing. That would line up with what I saw when I looked into this.

sudara commented 5 months ago

Actually, i wonder if it's just setvars stuff... the symlink should be restored according to https://github.com/actions/cache/issues/984#issuecomment-1372052193 — should be easy to test anyway with a ls -ahl i guess...

sudara commented 5 months ago

Maybe the answer is here: https://github.com/oneapi-src/oneapi-ci/blob/master/.github/workflows/build_all.yml#L39-L57

sudara commented 5 months ago

Think i got it:

Confirmed the latest symlink is there:

drwxr-xr-x 1 runneradmin 197121  0 Feb  7 00:05 2021.10
lrwxrwxrwx 1 runneradmin 197121 47 Feb  7 00:05 latest -> /c/Program Files (x86)/Intel/oneAPI/ipp/2021.10

Configure was giving this warning:

CMake Warning at cmake/PamplejuceIPP.cmake:3 (find_package):
  By not providing "FindIPP.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "IPP", but
  CMake did not find one.

  Could not find a package configuration file provided by "IPP" with any of
  the following names:

    IPPConfig.cmake
    ipp-config.cmake

  Add the installation prefix of "IPP" to CMAKE_PREFIX_PATH or set "IPP_DIR"
  to a directory containing one of the above files.  If "IPP" provides a
  separate development package or SDK, be sure it has been installed.
Call Stack (most recent call first):
  CMakeLists.txt:1[47](https://github.com/sudara/pamplejuce/actions/runs/7807769260/job/21297676136#step:13:48) (include)

So I just set IPP_DIR to point to where the CMake lives and it seems happy....

tobiashienzsch commented 5 months ago

FYI: You can just downgrade the Linux runner to 20.04. Then the stdlib workaround isn't needed. As you are installing clang anyway, the older Distro doesn't matter.

sudara commented 5 months ago

Do you mean for the failing linux builds on that branch? Or is this IPP related?

tobiashienzsch commented 5 months ago

Not IPP related

sudara commented 5 months ago

Ok cool, that's actually good to know. I have it working again on main, but keeping up with the workarounds is driving me crazy. Hate to downgrade to an older version, but it's pragmatic, thx.