oneDNN issue with migrating to the new versions

[densamoilov]

I looked into the bot's logs and the error message says the following:

"Could not find all output sections in meta.yaml! Found 4 sections for outputs names = {'onednn', 'onednn-cpu-omp', 'onednn-dpcpp', 'onednn-cpu-threadpool', 'onednn-cpu-tbb'}."

I'm not sure what output section is missing and how to approach the issue. Can you please give me some pointers?

[beckermr]

This is an issue with one of the mini migrators. I can try and look tomorrow.

[beckermr]

This issue in the recipe causing this is here: https://github.com/conda-forge/onednn-feedstock/blob/a13544ea98101f4338d74ff3ebceba891e928db3/recipe/meta.yaml#L79-L83

The bot is not able to handle if statements from jinja2 that make big changes to the recipe. I think the recipe could be rewritten to avoid this if statement by zipping the name of the output you want as another conda-build-variant variable in with the existing ones likes this

# use a docker image with glibc 2.28 in it for testing
docker_image:                                  # [x86_64 and linux64]
- quay.io/condaforge/linux-anvil-alma-x86_64:8 # [x86_64 and linux64]

dnnl_cpu_runtime:
  - tbb  # [not (ppc64le or aarch64)]
  - omp
  - threadpool # [not (ppc64le or aarch64 or arm64)]
  - dpcpp # [x86_64 and linux64]

dnnl_cpu_runtime_name:
  - cpu-tbb  # [not (ppc64le or aarch64)]
  - cpu-omp
  - cpu-threadpool # [not (ppc64le or aarch64 or arm64)]
  - dpcpp # [x86_64 and linux64]

zip_keys:
  - 
    - dnnl_cpu_runtime_name
    - dnnl_cpu_runtime

Then you can replace the if statement with this

  - name: onednn-{{ dnnl_cpu_runtime_name }}

[densamoilov]

Thanks @beckermr, I implemented the fix, hope it will fix auto-update.