[SYCL] Rename clang binaries to dpclang#21598
[SYCL] Rename clang binaries to dpclang#21598dm-vodopyanov wants to merge 1 commit intointel:syclfrom
Conversation
This patch renames `clang`, `clang++`, `clang-c++`, `clang-cc`, `clang-cpp`, `clang-g++`, `clang-gcc`, `clang-cl` to the same names with a prefix `dp` to make sure the SYCL compiler package can be co-existed with the official clang package for various Linux distributions.
|
|
||
| SmallString<128> ClangPath(C.getDriver().Dir); | ||
| llvm::sys::path::append(ClangPath, "clang"); | ||
| llvm::sys::path::append(ClangPath, "dpclang"); |
There was a problem hiding this comment.
We probably need to change sycl/doc as well
|
Thanks, @dm-vodopyanov. This is more change than I was expecting. How did you identify all the places to change? Trial and error by running the testsuite? Or a more systematic approach? |
dvrogozh
left a comment
There was a problem hiding this comment.
That's just a partial solution as it takes care to rename only clang* kind of things and leaves behind a bunch of lvm-* binaries, include/clang/, libLLVM*, etc. I would like to propose alternative solution which I hope will be easier:
- Change the install prefix for all the stuff borrowed from LLVM. Let default be
$libdir/dpclang-MAJOR/as that's prescribed default by File System Hierarchy Standard. This will immediately resolve all the potential conflicts with already installed LLVM. - Install additional targets, symlinks with the original names likes
dpclang-MAJOR
Above will create the following installation target (assuming the default for LLVM installation):
$bindir/dpclang ->$prefix/bin/dpclang-MAJOR
$bindir/dpclang-MAJOR
....
$libdir/libsycl.so.VERSION
$libdir/dpcpp-MAJOR/bin/clang
$libdir/dpcpp-MAJOR/bin/clang++
$libdir/dpcpp-MAJOR/bin/llvm-ar
...
|
I don't think this PR intended to solve the complete problem, I think it's just one piece of a larger set of changes. If we try to implement all of those in one PR it will become huge, impossible to review, and more likely to have bugs. |
I tend to agree with @dvrogozh's alternate suggestion. What he proposes is similar to what is done for the oneAPI icx compiler distribution (that distribution puts the LLVM utilities in a @dvrogozh, could you please quote the section of the File System Hierarchy Standard that you feel justifies placing the LLVM assets under |
It's section 4.6.1, https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s06.html: "/usr/lib includes object files and libraries. On some systems, it may also include internal binaries that are not intended to be executed directly by users or shell scripts. Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory." Note that Debian's and Ubuntu's Also, to place internal stuff to |
This patch renames
clang,clang++,clang-c++,clang-cc,clang-cpp,clang-g++,clang-gcc,clang-clto the same names with a prefixdpto make sure the SYCL compiler package can be co-existed with the official clang package for various Linux distributions.