Hi, Cayetano Santos <csant...@inventati.org> writes:
> Hi, > > I’ve been having a look around all our HPC related packages. I tried to > classify by organisation: > > - UxlFoundation (uxlfoundation.org) > > + oneTBB - tbb, python-tbb, tbb-2020 - in (gnu packages tbb) > + oneDNN - oneapi-dnnl, oneapi-dnnl-for-r-torch - in (gnu packages > machine-learning) > + oneDPM - > + oneDPL - > + oneDAL - > + oneCCL - > + oneMath - > > - AdaptiveCpp (adaptivecpp.github.io) > > + adaptivecpp - adaptivecpp - in (gnu packages sycl) > > - KhronosGroupd (khronosgroup.github.io) > > + opensles - opensles - in (gnu packages audio) > + mangohud - mangohud - in (gnu packages graphics) > + opencl-headers - opencl-headers - in (gnu packages opencl) > + opencl-icd-loader - opencl-icd-loader - in (gnu packages opencl) > + xxx - xxx - in (gnu packages vulkan) > > - Rocm (rocm.docs.amd.com) > > + llvm - llvm-for-rocm - in (gnu packages llvm) > + xxx - xxx - in (gnu packages rocm) > > Some of the previous need an update. I probably forget something, I’ll > complete as I further investigate. > > To facilitate the upcoming maintenance of this (increasingly complex) > ecosystem, I think we should probably try to organise these packages. At > a minimum, we might: > > - UxlFoundation (uxlfoundation.org) I'm not sure I like naming modules by the organization producing the packages -- it sounds a bit like advertising at the level of the Guix API :-). Which we've been happy to do with GNU packages but less so with other packages. I personally prefer the current state where things sorted by areas/topographically; this is what we've historically done and it makes for a nicer API in my opinion: (gnu packages electronics) is a good example of a recent one that fit that. [...] > - Rocm (rocm.docs.amd.com) > > + llvm - llvm-for-rocm - in (gnu packages rocm) > + xxx - xxx - in (gnu packages rocm) Note that llvm-for-rocm is a variant of llvm that inherits from it (IIRC), so can't be moved elsewehere without introducing cyclic dependencies at the top level, as the inherit field is not delayed or thunked (info "(guix) Cyclic Module Dependencies"). Note also that even if a single org packages are spread in multiple modules, that's easy to work around with a per-team manifest that can be placed under etc/teams/ with the listing of the revelant packages to be maintained by the team. -- Thanks, Maxim
