Project renaming to AdaptiveCpp

[illuhad]

Due to external legal pressure being applied on the old name, Open SYCL, we unfortunately were forced to abandon this name and look for a new one. See here for details: #999 (comment)

After a lengthy community discussion, we have settled on a new name: AdaptiveCpp.

This name encapsulates how the project allows an application to adapt to any hardware it can find one the system, and it highlights the adaptability and flexibility of our compiler and runtime. Additionally, we have also taken this opportunity to highlight that we are no longer just focusing on SYCL by using the "Cpp" suffix. With #1088, the project has gained support for offloading C++ standard parallelism, and is indeed currently the only solution that can offload regular C++ parallel STL algorithms to GPUs from Intel, NVIDIA, and AMD -- even from the same binary.
Thus, the new name should allow the project more room for growth and incorporate these new directions better, as it is now a generic solution for heterogeneous programming in C++.

In the coming days, weeks and months, we will be iteratively moving to the new name. Backwards compatibility to the older hipSYCL and Open SYCL naming schemes will be maintained for user interfaces as far as feasible.

Initially, documentation, cmake infrastructure, compiler flags, repository name and the compiler name (syclcc is now called acpp) will be migrated to the new name.

In the more long term future, other, more deeply ingrained usage of the older name will be tackled (internal usage, builtin names, namespace names etc).

Thank you so much to everybody who has contributed to this process, and thanks to everybody for the patience while we were working on finding a path forward. Looking back, I feel utterly humbled by all the support we have received from this awesome community! ❤️ ❤️

[al42and]

https://github.com/KhronosGroup/Khronosdotorg/blob/main/api/sycl/resources.md is due for an update. Not just the name, but the description too.

[illuhad]

@al42and Thanks, I've created a PR: KhronosGroup/Khronosdotorg#142

[al42and]

@illuhad: When it comes to renaming configuration macros (such as __HIPSYCL_ENABLE_HIP_TARGET__) and feature-test macros (such as HIPSYCL_EXT_QUEUE_WAIT_LIST), will the new name use ACPP or ADAPTIVECPP?

Thinking of future-proofing our code by adding both new and old names to various compile-time checks.

[illuhad]

The old names will definitely be kept for the macros for some time for backwards compatibility, so there should not be an immediate urgency for you to do this.

To your question: I haven't decided yet. You previously argued that the basis for the choice between AdaptiveCpp and the abbreviation should be the risk for name collisions. I think that for everything that starts with __, we could safely use __ACPP. For the rest I'm not sure. Do you think the risk of name collisions is low enough if we have ACPP_* ?

[al42and]

The old names will definitely be kept for the macros for some time for backwards compatibility, so there should not be an immediate urgency for you to do this.

GROMACS 2024 will be in active support till January 2025 (and maintained for one more year). We cannot promise to support unreleased ROCm/AdaptiveCpp versions, but we try to improve the chances of forward-compatibility where possible. And macros look like an easy thing to do.

Also, it would be nice to have new macros sooner rather than later. E.g., today, one still has to check HIPSYCL* macros as long as compatibility with AdaptiveCpp 23.10 is needed. The sooner new macro names are added, the sooner client software can abandon all mentions of the old name (which I have nothing against, but it makes things confusing).

Do you think the risk of name collisions is low enough if we have ACPP_* ?

I guess it's low; on the other hand, the benefit of shorter name is also low, so 🤷