Sustainability of hls external #48937
Description
The hls external corresponds to https://github.com/Xilinx/HLS_arbitrary_Precision_Types for which we have our own clone in https://github.com/cms-externals/HLS_arbitrary_Precision_Types.
This external package seems to be practically unmaintained. The https://github.com/Xilinx/HLS_arbitrary_Precision_Types has its last commit made in March 2019. We have experienced several issues in the past where we (=core software) had to patch the package in order to move other piece in our software stack forward (e.g. compiler, ROOT).
Some examples of the issues
- [ROOT6] Root update master 20250915 cmsdist#10077 / replace stdlib.h with cstdlib cms-externals/HLS_arbitrary_Precision_Types#1
- [DBG_X] Compilation failures in L1Trigger/L1TMuonOverlapPhase2 #44946 / [HLS] Apply constexpr patch cmsdist#9193
- [UBSAN] Warning in
hlsexternal (ap_private.h) #43040 / [hls] Fix for uninitialized/maybe-uninitialized warnings cmsdist#8834- Fix was submitted to upstream in ap_private: Initialize data member in default constructor to avoid compilation warnings Xilinx/HLS_arbitrary_Precision_Types#1 (in 2023) with zero reaction from the upstream
- [GCC12] Multiple maybe-uninitialized warnings in L1CaloLayer1 #41794
- [UBSAN] Runtime errors in
DQMOffline/Configuration#38944 - hls: avoid arithmetic between different enumeration types cmsdist#9311
For historical reference the inclusion of the hls external was requested in https://indico.cern.ch/event/1023733/#17-use-of-hls-in-persistent-or.
Core software having to patch this package every time is not sustainable in the long run (we did not sign up for the maintenance of this package). Especially the upstream showing no updates in 6 years and giving no comments on a PR looks very worrisome for the future. Unless the upstream starts to visibly maintain the code, or someone else in CMS or in wider community stands up for the maintenance, we think we should drop the hls external.