Future of scripts/*py helper scripts for generating a new backend template

[vmalia]

The generate_*.py scripts in https://github.com/oneapi-src/oneMKL/tree/develop/scripts work mostly for BLAS and LAPACK domains only because of the differences in how oneMKL domains work and are implemented.

One recommendation is to remove these scripts and let new backends be added by contributors from existing backend files and replicate+replace the contents approximately as described in https://oneapi-src.github.io/oneMKL/create_new_backend.html. This document will be updated as per the decision of this poll.

Alternatively, if the consensus is to keep these scripts, we need to update them to support all the domains that are implemented in oneMKL. This is a high-maintenance-cost option, but provides a better development experience.

If you have other ideas, please comment.

[Rbiessy]

Thanks for the poll, I am copying my previous comments on the topic for better visibility. I am in favor of removing the Python scripts for the following reasons:

1. The Codeplay team tried these scripts in the past and the generated files were not compiling and not aligned with the existing domains in oneMKL. Part of the reason is that the project has 3 different kind of backends today:

   • BLAS and LAPACK which are mostly independent free functions
   • RNG and DFT which rely a lot on oriented-object programming
   • SPARSE_BLAS which also uses free functions but has many opaque objects to store information across functions

2. It is common in software engineering to get inspiration from existing code and adapting it for a different purpose. We have found it was easier to copy existing domains or backends rather than starting from scratch.

3. Even if we were to fix them now the python scripts are not often used or updated. They are more likely to fail or generate outdated file than work at first try.

4. We have some relatively recent PRs that add new domains (DFT domain [DFT] Initial DFT work & MKLGPU backend #259, SPARSE domain [SPARSE] Add support for sparse gemv with MKLCPU #374) or add new backends to existing domains (cuFFT backend [DFT] Introduce the cuFFT backend for the DFT interface. #284, rocFFT [DFT] Add rocFFT backend for DFT interface #330 or cuSPARSE [SPARSE] Add support for cuSPARSE backend #527). They are a more concrete example of what is needed to add new backends.