Add workflow to build the package and upload to dppy/label/dev

[oleksandr-pavlyk]

Add workflow to build the package and upload to dppy/label/dev

Fix post-link script so that tests pass.

Add SECURTY.md and CODEOWNERS to improve OpenSSF score.

[oleksandr-pavlyk]

Once this package is built and uploaded, activation scripts in dpctl which perform similar function should be removed.

[ZzEeKkAa]

It's a great package, but have you consider to port it to conda-forge directly?

[oleksandr-pavlyk]

Yes, there is a similar one on conda-forge, ocl-icd-system (see feedstock).

It creates a symbolic link from ${PREFIX}/etc/OpenCL/vendors/system_vendors to /etc/OpenCL/vendors. This has several drawbacks for us:

1. The OpenCL loader included in intel-opencl-rt conda package is vanilla Khonos loader, and does not support recursive inspection of OCL_ICD_VENDORS folder, unlike patched loader included in ocl-icd conda package.
2. Should OpenCL loader be able to discovery every files from /etc/OpenCL/vendors, this would lead to data-parallel extensions seeing two CPU devices (one referenced from ${PREFIX}/etc/OpenCL/vendors/intel-ocl-cpu.icd and one from /etc/OpenCL/vendors/intel64.icd. These may be of different versions, causing user's confusion.

[ZzEeKkAa]

I guess my overall idea is to provide just intel-gpu-opencl-rt to conda-forge, that suppose to add only gpu opencl runtime

1. The OpenCL loader included in intel-opencl-rt conda package is vanilla Khonos loader, and does not support recursive inspection of OCL_ICD_VENDORS folder, unlike patched loader included in ocl-icd conda package.

It is not longer true (It was either there before, or was introduced by me)
https://github.com/conda-forge/intel-compiler-repack-feedstock/blob/main/recipe/meta.yaml#L275-L279

2. Should OpenCL loader be able to discovery every files from /etc/OpenCL/vendors, this would lead to data-parallel extensions seeing two CPU devices (one referenced from ${PREFIX}/etc/OpenCL/vendors/intel-ocl-cpu.icd and one from /etc/OpenCL/vendors/intel64.icd. These may be of different versions, causing user's confusion.

Could we set up dependency in the way that it uses either one or another, but not both? Would not it be solved by setting OCL_ICD_LOADER env to the `${PREFIX}/etc/OpenCL/vendors/ocl-icd-system/?

[ZzEeKkAa]

And if we are maintaining feedstock here, is it possible to use conda-smithy to reuse all the things conda-forge have?
https://conda-forge.org/docs/maintainer/updating_pkgs/#rerendering-feedstocks

[oleksandr-pavlyk]

@ZzEeKkAa This package is noarch and python version agnostic, see noarch: generic in the build section of "meta.yaml". Setting up conda-forge-like build infrastructure to build it seems an overkill.