From dba7d7523a103586bea305ac6c766e5530660384 Mon Sep 17 00:00:00 2001 From: "romain.biessy" Date: Fri, 23 Aug 2024 14:00:20 +0200 Subject: [PATCH 1/9] [RFC] oneMKL Interface renaming --- .../README.md | 164 ++++++++++++++++++ 1 file changed, 164 insertions(+) create mode 100644 rfcs/20240903-onemkl-interface-rename/README.md diff --git a/rfcs/20240903-onemkl-interface-rename/README.md b/rfcs/20240903-onemkl-interface-rename/README.md new file mode 100644 index 000000000..101dc72e8 --- /dev/null +++ b/rfcs/20240903-onemkl-interface-rename/README.md @@ -0,0 +1,164 @@ +# OneMKL Interface renaming + +### Revision + + +|Date |Revision | Comments | +|-----------|---------|--------------------------------------------------------------------------| +| 20240903 | 1.0 | Initial version | + +## Motivation + +As oneMKL interface is moving to the UXL foundation we should make sure that it +does not reuse the same name as the existing [Intel oneMKL +product](https://www.intel.com/content/www/us/en/developer/tools/oneapi/onemkl.html). + +We have been discussing 2 solutions to avoid this issue: +1. Renaming the [oneMKL](https://github.com/oneapi-src/oneMKL) GitHub project to + a new name to be discussed and replacing or clarifying the occurrences of + "oneMKL" in that repository. +2. Using this opportunity to also split this GitHub project per domain. In this + case the names that are advertised would be based on each domain of oneMKL + like `one`. + +We think that the first solution should be enough to answer the main concern. It +is not clear whether the second solution could better answer the need of users +so we are not planning to split oneMKL per domain unless there is clear and +strong feedback from users. + +**We aim to agree on a solution by October 4, 2024 and have the proposal +implemented by the end of November 2024.** + +There has been a number issues of where we have had to clarify the differences +between oneMKL Interface and the Intel oneMKL product +[#501](https://github.com/oneapi-src/oneMKL/issues/501#issuecomment-2134681621); +[#377](https://github.com/oneapi-src/oneMKL/issues/377); +[#253](https://github.com/oneapi-src/oneMKL/issues/253); +[#222](https://github.com/oneapi-src/oneMKL/issues/222); +[#211](https://github.com/oneapi-src/oneMKL/issues/211); +[#207](https://github.com/oneapi-src/oneMKL/issues/207); +[#206](https://github.com/oneapi-src/oneMKL/issues/206). Many of these issues +are from 2022. I believe this is still an issue today since this has been an +issue on multiple occasion internally when Codeplay started to contribute to +oneMKL Interface. The oneMKL Interface +[README](https://github.com/oneapi-src/oneMKL?tab=readme-ov-file#onemkl) already +explains the differences between oneMKL Interface and Intel oneMKL product but +this is not enough for people who are not working directly on the projects. + +## Outline + +1. [Introduction](#introduction) +2. [Proposal](#proposal) +3. [User impact](#user-impact) +4. [Open questions](#open-questions) + +## Introduction + +oneMKL Interface has historically been implemented and supported by Intel. As +the project is moving to the UXL foundation it we want to avoid using the name +of an Intel product. This RFC describes the solution of renaming oneMKL +Interface to a new name. + +## Proposal + +The main purpose of this RFC is to agree on a new name for oneMKL Interface. +Some of the suggested names are: +* **oneMath** +* **oneSLA** (SYCL Linear Algebra) + +Other suggestions are welcomed. + +The suggested solution is to proceed in the following steps: +1. The UXL foundation agrees on the new name. +2. Codeplay submits a oneMKL Interface PR to: + * Update the root README to use the new name, with a mention that the project + was formerly called oneMKL Interface. + * Update the references to "oneMKL" and `onemkl_` in the documentation as + seen in the first few lines of + [docs/onemkl-datatypes.rst](https://github.com/oneapi-src/oneMKL/blob/develop/docs/onemkl-datatypes.rst?plain=1#L1) + for instance. + * Update occurrences of "onemkl" in internal functions such as + [onemkl_cublas_host_task](https://github.com/oneapi-src/oneMKL/blob/1ce98a699f93bd3a78350269b2e34d822fe43b91/src/blas/backends/cublas/cublas_task.hpp#L77). + * Update macros such as include guards and other internal macros like + `ONEMKL_EXPORT` to use the new name. + * Rename CMake targets `onemkl` and `onemkl__` to use the + new name. The existing targets name can be added with a deprecation + messages for anyone using them. See the section on [CMake target + deprecation](#cmake-deprecated-target) for more details. +3. Codeplay submits a oneAPI-spec PR to rename the occurrences of "oneMKL" to + the new name. +4. Once the PRs are approved, Codeplay transfers the + [oneMKL](https://github.com/oneapi-src/oneMKL) GitHub project to the + [uxlfoundation](https://github.com/uxlfoundation) organization under the new + name. We use the + [transferring](https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository) + feature from GitHub so the links from the previous repository are redirected + to the new one. +5. The PRs from the step 2 and 3 are merged. + +We are not planning to rename the occurrences of "mkl" such as the `oneapi::mkl` +namespace, the `include/oneapi/mkl` folder or the `include/oneapi/mkl.hpp` file. +Whether this is needed is an open question. + +### CMake target deprecation + +CMake allows to set a +[`DEPRECATION`](https://cmake.org/cmake/help/latest/prop_tgt/DEPRECATION.html) +property on a target which will print a custom message whenever the target is +used. The property cannot be set on an [alias +target](https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#alias-targets) +as they are read-only. The property can be set on an imported target instead +like the example below: + +```cmake +add_library(onemath lib.cpp) # New main target, for the example + +add_library(onemkl INTERFACE IMPORTED) # onemkl works like an alias of onemath which can have different properties +target_link_libraries(onemkl INTERFACE onemath) +set_target_properties(onemkl PROPERTIES DEPRECATION "onemkl target is deprecated, please use onemath instead") + +add_executable(main main.cpp) +target_link_libraries(main PUBLIC onemkl) # Prints a warning at CMake configuration time +``` + +The same solution can be used for the `onemkl__` targets. This does +not add any extra targets to the generated `Makefile` or `build.ninja` files so +the library will not be built twice. + +### Other Considered Approaches + +Another considered approach is to split the existing oneMKL Interface per domain +like so: oneBLAS, oneLAPACK, oneDFT, oneRNG, oneSPARSE. This shifts the need of +renaming "oneMKL Interface" as the main visible names will be based on the +domain. It is not clear whether this better answers the users needs. + +With this approach the suggested solution is to have a common repository for +common types (`transpose`, `uplo`, `diag`, `side`, `offset`, `index_base`, +`layout`), exceptions and some CMake logic. Each domain would have its own +repository automatically pulling the common headers. Another repository could be +created to automatically pull multiple domains which would mimic the behavior of +the current oneMKL Interface. + +We are not planning to proceed with this approach unless users express a strong +preference. + +## User impact + +The suggested solution does not break any existing code. +* The repository is transferred using the [GitHub + transfer](https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository) + feature so users accessing or pulling from + https://github.com/oneapi-src/oneMKL will be redirected to the new link. +* The changes in oneMKL do not affect the public API. The macros renamed or the + header files in the `detail` folders renamed should not be used outside of the + oneMKL Interface project. +* The CMake changes will still provide the same targets but will print a warning + message if users use targets with the `onemkl` name. + +## Open questions + +* Other suggestions for new names are welcomed. +* Is it needed to rename the occurrences of "mkl"? + * This will have a bigger impact and require more time to complete. + * It should be possible to rename these occurrences without any breaking + change. This would need to be further investigated. From d55ef091f1a57f26a2d31b6a6b219b3041c143a7 Mon Sep 17 00:00:00 2001 From: "romain.biessy" Date: Thu, 5 Sep 2024 13:42:51 +0200 Subject: [PATCH 2/9] Fix typos --- rfcs/20240903-onemkl-interface-rename/README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/rfcs/20240903-onemkl-interface-rename/README.md b/rfcs/20240903-onemkl-interface-rename/README.md index 101dc72e8..0c17e30dd 100644 --- a/rfcs/20240903-onemkl-interface-rename/README.md +++ b/rfcs/20240903-onemkl-interface-rename/README.md @@ -9,8 +9,8 @@ ## Motivation -As oneMKL interface is moving to the UXL foundation we should make sure that it -does not reuse the same name as the existing [Intel oneMKL +As oneMKL interface is moving to the UXL foundation we should make sure that the +name does not collide with the existing [Intel oneMKL product](https://www.intel.com/content/www/us/en/developer/tools/oneapi/onemkl.html). We have been discussing 2 solutions to avoid this issue: @@ -55,9 +55,9 @@ this is not enough for people who are not working directly on the projects. ## Introduction oneMKL Interface has historically been implemented and supported by Intel. As -the project is moving to the UXL foundation it we want to avoid using the name -of an Intel product. This RFC describes the solution of renaming oneMKL -Interface to a new name. +the project is moving to the UXL foundation we want to avoid using the name of +an Intel product. This RFC describes the solution of renaming oneMKL Interface +to a new name. ## Proposal From 9dc802e460837abce61e1c78513dd4239f22a020 Mon Sep 17 00:00:00 2001 From: "romain.biessy" Date: Mon, 9 Sep 2024 12:42:10 +0200 Subject: [PATCH 3/9] Swap step 2 and 3 --- rfcs/20240903-onemkl-interface-rename/README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/rfcs/20240903-onemkl-interface-rename/README.md b/rfcs/20240903-onemkl-interface-rename/README.md index 0c17e30dd..025d3ea16 100644 --- a/rfcs/20240903-onemkl-interface-rename/README.md +++ b/rfcs/20240903-onemkl-interface-rename/README.md @@ -70,7 +70,9 @@ Other suggestions are welcomed. The suggested solution is to proceed in the following steps: 1. The UXL foundation agrees on the new name. -2. Codeplay submits a oneMKL Interface PR to: +2. Codeplay submits a oneAPI-spec PR to rename the occurrences of "oneMKL" to + the new name. +3. Codeplay submits a oneMKL Interface PR to: * Update the root README to use the new name, with a mention that the project was formerly called oneMKL Interface. * Update the references to "oneMKL" and `onemkl_` in the documentation as @@ -85,8 +87,6 @@ The suggested solution is to proceed in the following steps: new name. The existing targets name can be added with a deprecation messages for anyone using them. See the section on [CMake target deprecation](#cmake-deprecated-target) for more details. -3. Codeplay submits a oneAPI-spec PR to rename the occurrences of "oneMKL" to - the new name. 4. Once the PRs are approved, Codeplay transfers the [oneMKL](https://github.com/oneapi-src/oneMKL) GitHub project to the [uxlfoundation](https://github.com/uxlfoundation) organization under the new From dccf718455e4be4265cf8fe5a1196bd9c13ccf07 Mon Sep 17 00:00:00 2001 From: "romain.biessy" Date: Mon, 9 Sep 2024 14:16:51 +0200 Subject: [PATCH 4/9] Add deadline to choose a new name --- rfcs/20240903-onemkl-interface-rename/README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/rfcs/20240903-onemkl-interface-rename/README.md b/rfcs/20240903-onemkl-interface-rename/README.md index 025d3ea16..e5c321d45 100644 --- a/rfcs/20240903-onemkl-interface-rename/README.md +++ b/rfcs/20240903-onemkl-interface-rename/README.md @@ -66,7 +66,8 @@ Some of the suggested names are: * **oneMath** * **oneSLA** (SYCL Linear Algebra) -Other suggestions are welcomed. +Other suggestions are welcomed. The name **oneMath** will be chosen if there are +no objections by October 4, 2024. The suggested solution is to proceed in the following steps: 1. The UXL foundation agrees on the new name. From 88e1cb691c828342c592a12e7818e676d42d6891 Mon Sep 17 00:00:00 2001 From: "romain.biessy" Date: Mon, 16 Sep 2024 12:10:53 +0200 Subject: [PATCH 5/9] Add open question on the naming of the specification --- rfcs/20240903-onemkl-interface-rename/README.md | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/rfcs/20240903-onemkl-interface-rename/README.md b/rfcs/20240903-onemkl-interface-rename/README.md index e5c321d45..41cf7a136 100644 --- a/rfcs/20240903-onemkl-interface-rename/README.md +++ b/rfcs/20240903-onemkl-interface-rename/README.md @@ -61,10 +61,12 @@ to a new name. ## Proposal -The main purpose of this RFC is to agree on a new name for oneMKL Interface. -Some of the suggested names are: +The main purpose of this RFC is to agree on a new name for the oneMKL specification and oneMKL Interface. +Some of the suggested names for the implementations are: * **oneMath** + * The specification would be renamed oneMath Specification * **oneSLA** (SYCL Linear Algebra) + * The specification would be renamed oneSLA Specification Other suggestions are welcomed. The name **oneMath** will be chosen if there are no objections by October 4, 2024. @@ -163,3 +165,12 @@ The suggested solution does not break any existing code. * This will have a bigger impact and require more time to complete. * It should be possible to rename these occurrences without any breaking change. This would need to be further investigated. +* Should the specification and the existing implementation have different names? + * Currently both the specification and implementation are named based on + "oneMKL" which suggests that the oneMKL Interface is the main or only + implementation of the specification. If the goal of the specification is to + encourage for multiple implementations to co-exist then it should be named + differently than the implementation. + * Given the nature of the project that allows for multiple backends I don't + see any value in encouraging multiple implementations as of today. + * Using multiple names may create more confusion. From f3e5ccf77adafb187837648ece54aad7ece80161 Mon Sep 17 00:00:00 2001 From: "romain.biessy" Date: Mon, 16 Sep 2024 16:16:53 +0200 Subject: [PATCH 6/9] Rename occurrences mkl and add open question on specification name --- .../README.md | 79 +++++++++++++------ 1 file changed, 54 insertions(+), 25 deletions(-) diff --git a/rfcs/20240903-onemkl-interface-rename/README.md b/rfcs/20240903-onemkl-interface-rename/README.md index 41cf7a136..10ae005a9 100644 --- a/rfcs/20240903-onemkl-interface-rename/README.md +++ b/rfcs/20240903-onemkl-interface-rename/README.md @@ -6,6 +6,7 @@ |Date |Revision | Comments | |-----------|---------|--------------------------------------------------------------------------| | 20240903 | 1.0 | Initial version | +| 20240916 | 1.1 | Rename occurrences of "mkl" and add an open question | ## Motivation @@ -27,7 +28,7 @@ so we are not planning to split oneMKL per domain unless there is clear and strong feedback from users. **We aim to agree on a solution by October 4, 2024 and have the proposal -implemented by the end of November 2024.** +implemented by the end of January 2025.** There has been a number issues of where we have had to clarify the differences between oneMKL Interface and the Intel oneMKL product @@ -65,31 +66,47 @@ The main purpose of this RFC is to agree on a new name for the oneMKL specificat Some of the suggested names for the implementations are: * **oneMath** * The specification would be renamed oneMath Specification + * The C++ namespace would be `oneapi::math` + * The CMake namespace would be `ONEMATH` * **oneSLA** (SYCL Linear Algebra) * The specification would be renamed oneSLA Specification + * New namespace would be `oneapi::sla` + * The CMake namespace would be `ONESLA` Other suggestions are welcomed. The name **oneMath** will be chosen if there are no objections by October 4, 2024. The suggested solution is to proceed in the following steps: 1. The UXL foundation agrees on the new name. -2. Codeplay submits a oneAPI-spec PR to rename the occurrences of "oneMKL" to - the new name. +2. Codeplay submits a oneAPI-spec PR to rename the occurrences of "oneMKL" and + "mkl" to the new name. 3. Codeplay submits a oneMKL Interface PR to: - * Update the root README to use the new name, with a mention that the project - was formerly called oneMKL Interface. - * Update the references to "oneMKL" and `onemkl_` in the documentation as - seen in the first few lines of - [docs/onemkl-datatypes.rst](https://github.com/oneapi-src/oneMKL/blob/develop/docs/onemkl-datatypes.rst?plain=1#L1) - for instance. - * Update occurrences of "onemkl" in internal functions such as - [onemkl_cublas_host_task](https://github.com/oneapi-src/oneMKL/blob/1ce98a699f93bd3a78350269b2e34d822fe43b91/src/blas/backends/cublas/cublas_task.hpp#L77). - * Update macros such as include guards and other internal macros like - `ONEMKL_EXPORT` to use the new name. - * Rename CMake targets `onemkl` and `onemkl__` to use the - new name. The existing targets name can be added with a deprecation - messages for anyone using them. See the section on [CMake target - deprecation](#cmake-deprecated-target) for more details. + * Update the root README to use the new name, with a mention that the project + was formerly called oneMKL Interface. + * Update the references to "oneMKL" and `onemkl_` in the documentation as + seen in the first few lines of + [docs/onemkl-datatypes.rst](https://github.com/oneapi-src/oneMKL/blob/develop/docs/onemkl-datatypes.rst?plain=1#L1) + for instance. + * Update occurrences of "onemkl" in internal functions such as + [onemkl_cublas_host_task](https://github.com/oneapi-src/oneMKL/blob/1ce98a699f93bd3a78350269b2e34d822fe43b91/src/blas/backends/cublas/cublas_task.hpp#L77). + * Update macros such as include guards and other internal macros like + `ONEMKL_EXPORT` to use the new name. + * Rename CMake targets `onemkl` and `onemkl__` to use the + new name. The existing targets name can be added with a deprecation + messages for anyone using them. See the section on [CMake target + deprecation](#cmake-deprecated-target) for more details. The namespace of + the exported and installed targets are changed to use the new name. + * The namespace `oneapi::mkl` is deprecated and aliased to the new namespace + name. + * The main header and domain headers are deprecated and include the new headers as shown below: + * `include/oneapi/` + * `mkl.hpp` -> `onemath.hpp` + * `mkl/` -> `onemath/` + * `blas.hpp` + * `dft.hpp` + * `lapack.hpp` + * `rng.hpp` + * `sparse_blas.hpp` 4. Once the PRs are approved, Codeplay transfers the [oneMKL](https://github.com/oneapi-src/oneMKL) GitHub project to the [uxlfoundation](https://github.com/uxlfoundation) organization under the new @@ -99,9 +116,7 @@ The suggested solution is to proceed in the following steps: to the new one. 5. The PRs from the step 2 and 3 are merged. -We are not planning to rename the occurrences of "mkl" such as the `oneapi::mkl` -namespace, the `include/oneapi/mkl` folder or the `include/oneapi/mkl.hpp` file. -Whether this is needed is an open question. +We suggest to keep the deprecated features for 1 year before removing them. ### CMake target deprecation @@ -147,7 +162,22 @@ preference. ## User impact -The suggested solution does not break any existing code. +The suggested solution can break user's code in 2 ways: +* Only the headers listed below should be included by the users. Any other + headers will be moved and will not have an equivalent header with a + deprecation warning. + * `include/oneapi/` + * `mkl.hpp` + * `mkl/` + * `blas.hpp` + * `dft.hpp` + * `lapack.hpp` + * `rng.hpp` + * `sparse_blas.hpp` +* The CMake logic using the `MKL::` or `ONEMKL::` namespaces will need to be + renamed to a new namespace based on the chosen name. + +The following changes have no impact: * The repository is transferred using the [GitHub transfer](https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository) feature so users accessing or pulling from @@ -161,10 +191,9 @@ The suggested solution does not break any existing code. ## Open questions * Other suggestions for new names are welcomed. -* Is it needed to rename the occurrences of "mkl"? - * This will have a bigger impact and require more time to complete. - * It should be possible to rename these occurrences without any breaking - change. This would need to be further investigated. +* Is it needed to rename the occurrences of "mkl"? + * From the feedback gathered, users and maintainers are keen to rename these + occurrences. * Should the specification and the existing implementation have different names? * Currently both the specification and implementation are named based on "oneMKL" which suggests that the oneMKL Interface is the main or only From 1182a951fb51a347a2a0a40437d430a759bdf55e Mon Sep 17 00:00:00 2001 From: "romain.biessy" Date: Tue, 17 Sep 2024 10:53:24 +0200 Subject: [PATCH 7/9] Rename onemath folder and header to math --- rfcs/20240903-onemkl-interface-rename/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfcs/20240903-onemkl-interface-rename/README.md b/rfcs/20240903-onemkl-interface-rename/README.md index 10ae005a9..5df396da5 100644 --- a/rfcs/20240903-onemkl-interface-rename/README.md +++ b/rfcs/20240903-onemkl-interface-rename/README.md @@ -100,8 +100,8 @@ The suggested solution is to proceed in the following steps: name. * The main header and domain headers are deprecated and include the new headers as shown below: * `include/oneapi/` - * `mkl.hpp` -> `onemath.hpp` - * `mkl/` -> `onemath/` + * `mkl.hpp` -> `math.hpp` + * `mkl/` -> `math/` * `blas.hpp` * `dft.hpp` * `lapack.hpp` From 637610d8cabd400c20f9f32d90704528473e8211 Mon Sep 17 00:00:00 2001 From: "romain.biessy" Date: Tue, 17 Sep 2024 17:34:02 +0200 Subject: [PATCH 8/9] Add rng/device.hpp to the list headers to deprecate --- rfcs/20240903-onemkl-interface-rename/README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/rfcs/20240903-onemkl-interface-rename/README.md b/rfcs/20240903-onemkl-interface-rename/README.md index 5df396da5..0dc1c6ca8 100644 --- a/rfcs/20240903-onemkl-interface-rename/README.md +++ b/rfcs/20240903-onemkl-interface-rename/README.md @@ -106,6 +106,7 @@ The suggested solution is to proceed in the following steps: * `dft.hpp` * `lapack.hpp` * `rng.hpp` + * `rng/device.hpp` * `sparse_blas.hpp` 4. Once the PRs are approved, Codeplay transfers the [oneMKL](https://github.com/oneapi-src/oneMKL) GitHub project to the @@ -173,6 +174,7 @@ The suggested solution can break user's code in 2 ways: * `dft.hpp` * `lapack.hpp` * `rng.hpp` + * `rng/device.hpp` * `sparse_blas.hpp` * The CMake logic using the `MKL::` or `ONEMKL::` namespaces will need to be renamed to a new namespace based on the chosen name. From 3847831a75b1c15e0aa09190e89458f4bacee153 Mon Sep 17 00:00:00 2001 From: "romain.biessy" Date: Wed, 25 Sep 2024 16:14:27 +0200 Subject: [PATCH 9/9] Update with feedback from UXL WG --- .../README.md | 24 ++++++++++++------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/rfcs/20240903-onemkl-interface-rename/README.md b/rfcs/20240903-onemkl-interface-rename/README.md index 0dc1c6ca8..cf59eee38 100644 --- a/rfcs/20240903-onemkl-interface-rename/README.md +++ b/rfcs/20240903-onemkl-interface-rename/README.md @@ -7,6 +7,7 @@ |-----------|---------|--------------------------------------------------------------------------| | 20240903 | 1.0 | Initial version | | 20240916 | 1.1 | Rename occurrences of "mkl" and add an open question | +| 20240925 | 1.2 | Update wth feedback from UXL WG | ## Motivation @@ -91,11 +92,12 @@ The suggested solution is to proceed in the following steps: [onemkl_cublas_host_task](https://github.com/oneapi-src/oneMKL/blob/1ce98a699f93bd3a78350269b2e34d822fe43b91/src/blas/backends/cublas/cublas_task.hpp#L77). * Update macros such as include guards and other internal macros like `ONEMKL_EXPORT` to use the new name. - * Rename CMake targets `onemkl` and `onemkl__` to use the - new name. The existing targets name can be added with a deprecation - messages for anyone using them. See the section on [CMake target - deprecation](#cmake-deprecated-target) for more details. The namespace of - the exported and installed targets are changed to use the new name. + * Rename CMake targets `onemkl`, `onemkl_` and + `onemkl__` to use the new name. The existing targets name + can be added with a deprecation messages for anyone using them. See the + section on [CMake target deprecation](#cmake-deprecated-target) for more + details. The namespace of the exported and installed targets are changed to + use the new name. * The namespace `oneapi::mkl` is deprecated and aliased to the new namespace name. * The main header and domain headers are deprecated and include the new headers as shown below: @@ -140,9 +142,10 @@ add_executable(main main.cpp) target_link_libraries(main PUBLIC onemkl) # Prints a warning at CMake configuration time ``` -The same solution can be used for the `onemkl__` targets. This does -not add any extra targets to the generated `Makefile` or `build.ninja` files so -the library will not be built twice. +The same solution can be used for the `onemkl_` and +`onemkl__` targets. This does not add any extra targets to the +generated `Makefile` or `build.ninja` files so the library will not be built +twice. ### Other Considered Approaches @@ -192,7 +195,8 @@ The following changes have no impact: ## Open questions -* Other suggestions for new names are welcomed. +The following questions have been answered: + * Is it needed to rename the occurrences of "mkl"? * From the feedback gathered, users and maintainers are keen to rename these occurrences. @@ -205,3 +209,5 @@ The following changes have no impact: * Given the nature of the project that allows for multiple backends I don't see any value in encouraging multiple implementations as of today. * Using multiple names may create more confusion. + * We discussed that the existing oneMKL Interface implementation should be the + main implementation and therefore the specification can share the same name.