Xilinx
Install /opt/xilinx/xrt/include/CL/cl_ext_xilinx.h directly in /usr/include/CL
While playing with the Intel SYCL implementation, @agozillon noticed that the file cl_ext_xilinx.h does not go to the standard OpenCL location while using the generated Debian XRT package.
This makes a little bit more difficult the use of Xilinx extensions by requiring to change the build system.
Note that by contrast xilinx.icd goes directly into /etc/OpenCL/vendors.
Otherwise, I do not think that /opt/xilinx/xrt/include/CL/cl_ext.h is fundamental since it just includes cl_ext_xilinx.h. Furthermore, installing it in /usr/include/CL would break the file defining the standard extensions... Perhaps we can just keep this one there, just in case of some old application using it?
I see your point, but then we have a problem with #include_next, dont' we? The current idea is that with search path pointing to /opt/xilinx/xrt/include, users including cl_ext.h will get our wrapper /opt/xilinx/xrt/include/cl_ext.h which only includes cl_ext_xilinx.h then turns around and includes /usr/include/CL cl_ext.h. This is done for backwards compatibility because someone once upon a time found it a great idea to put our extensions directly in our copy of cl_ext.h, alas, many tests currently include only cl_ext.h when they should in fact include cl_ext_xilinx.h.
Ah, I missed this #include_next atrocity... :-)
I have the feeling that just having a normal cl_ext_xilinx.h in /usr/include/CL would work for normal users desiring to use explicitly Xilinx extensions and having a backward compatibility /opt/xilinx/xrt/include/CL/cl_ext.h to next-include /usr/include/CL/cl_ext.h and to include /usr/include/CL/cl_ext_xilinx.h.
It looks like it would solve your problem and my problem with the same number of files.
By comparison Intel GPU stack comes with an Intel extension header /usr/include/CL and they do not bother to include or be included from /usr/include/CL/cl_ext.h.