Xilinx
Add workflow that builds deb package using debian/rules
Problem solved by the commit
Debian build rules are not used in regular builds and break from time to time.
Bug / issue (if any) fixed, which PR introduced the bug, how it was discovered
How problem was solved, alternative solutions (if any) and why they were rejected
Workflow uses dependencies list extracted from debian/control with simple perl script to make sure they are valid.
Risks (if any) associated the changes in the commit
What has been tested and how, request additional testing if necessary
Documentation impact (if any)
This is draft until some issues are clarified and resolved:
- [ ] It looks like packaging is gradually shifting from /opt/xilinx/xrt to /usr (see f47d3cd5 for example). Is it true?
- [ ] What is minimal amount of tests that should be performed on installed package? Calling xclbinutil and compiling xrt/00_hello tests is enought?
- [ ] This pull request uses ccache (that greatly reduces compilation time) that depends on #9231 (if it is not merged then using ccache does not make sense).
- [ ] Also there are files installed (but not packaged) in /usr/src/xrt-aws-2.20.0 (dkms files reports that this is xrt-awsmgmt driver). Should it be packaged into xrt-aws-dkms package?
It looks like packaging is gradually shifting from /opt/xilinx/xrt to /usr (see https://github.com/Xilinx/XRT/commit/f47d3cd549dff89f7bcaa48b83254c40f4598503 for example). Is it true?
The CMake files were changed to obey and never set CMAKE_INSTALL_PREFIX. So it's entirely up to the build to specify the install for packages.
What is minimal amount of tests that should be performed on installed package? Calling xclbinutil and compiling xrt/00_hello tests is enough?
Sound sufficient to me.
This pull request uses ccache (that greatly reduces compilation time) that depends on https://github.com/Xilinx/XRT/pull/9231 (if it is not merged then using ccache does not make sense).
I will look at #9231. However, ccache is already supported with build.sh. It sets -DXRT_CCACHE=1 during configuration and disables inclusion of version.h. Do we need anything additional? I do like the fact that the generated version file is in the same relative location as the installed header.
Also there are files installed (but not packaged) in /usr/src/xrt-aws-2.20.0 (dkms files reports that this is xrt-awsmgmt driver). Should it be packaged into xrt-aws-dkms package?
@ManojTakasi , @chvamshi-xilinx ?
The CMake files were changed to obey and never set CMAKE_INSTALL_PREFIX. So it's entirely up to the build to specify the install for packages.
But what is right way in your opinion? Use /opt/xilinx/xrt or /usr for packaging? Official packages (last available at least) use /opt/xilinx/xrt.
I will look at #9231. However, ccache is already supported with build.sh. It sets -DXRT_CCACHE=1 during configuration and disables inclusion of version.h. Do we need anything additional? I do like the fact that the generated version file is in the same relative location as the installed header.
Oh, i've missed XRT_CCACHE define, but it is not needed if datetime field is not included into whole build tree. Please take a look at #9231, maybe you'll find it usefull.
But what is right way in your opinion? Use /opt/xilinx/xrt or /usr for packaging? Official packages (last available at least) use /opt/xilinx/xrt.
I am under the impression that upstream is in control of CMAKE_INSTALL_PREFIX. I am working on a Debian upstream for XRT for NPU. It will use /usr as the install root. I am not familiar with what build/debian is used for or by whom? But I would not recommend changing the install location as this time; let's see if ultimately this build/debian can be merged with what I am working on.
Please take a look at https://github.com/Xilinx/XRT/pull/9231, maybe you'll find it usefull.
Yes, very useful. Thank you.
I am not familiar with what build/debian is used for or by whom?
We were using build/debian (with minor tweaks) for 3+ years for Alveo cards but it looks like I've picked up wrong base for packaging.
At first glance 'official' debianization that can be found at https://salsa.debian.org/xilinx-packages-team/xrt lacks xrt-xocl-dkms. So at least for now build/debian is pretty useful.
I'll try to use package from salsa and report back.
I am not familiar with what build/debian is used for or by whom?
We were using build/debian (with minor tweaks) for 3+ years for Alveo cards but it looks like I've picked up wrong base for packaging.
At first glance 'official' debianization that can be found at https://salsa.debian.org/xilinx-packages-team/xrt lacks xrt-xocl-dkms. So at least for now build/debian is pretty useful.
I'll try to use package from salsa and report back.
The salsa repo XRT packages is what I am working on updating. But this upstreaming will change to support NPU only. It will not be an edge build and there will be no xocl-dkms. It sounds like buid/debian serves a different purpose.
The salsa repo XRT packages is what I am working on updating. But this upstreaming will change to support NPU only. It will not be an edge build and there will be no xocl-dkms. It sounds like buid/debian serves a different purpose.
Is it true that XRT_NPU and XRT_ALVEO (or XRT_XRT) modes of compilation are in conflict? It looks like that enabling both (NPU and ALVEO or NPU and XRT) is possible.
XRT_NPU mostly affect CMake component names that are not used in packaging, at least one test is disabled (xclbinutil file-check) and src/runtime_src/core/common/xdp/profile.cpp compiled with -DXDP_CLIENT_BUILD.