Re: New package: OpenCL-SDK

[ahesford <ahesford@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/pull/48261#issuecomment-1898418994

Comment:
I wouldn't go that far.

The Khronos ICD loader might be superior to ocl-icd (or at least a desirable alternative and we might still want to package it, but we should consider consider whether 1) if ocl-icd will live on in its own right, 2) if so, whether we want to continue support it, and 3) if so, whether we should move all of its dependents to the new option at this point.

If we offer both ICD loaders, they would either need to conflict or present alternatives. If they conflict, we should build all of our packages with whatever the preferred loader is (otherwise, some combination of consumers would be uninstallable). If they offer alternatives, we will need to alter build process.

As for the utilities offered by the SDK repo, my preference for ease of packaging would be to convince upstream to allow building of the extras against "system" versions of its git submodules, allowing us to build the SDK as an add-on. Submodules are kind of a pain in xbps-src, and hard-requiring them as most of the substance of a project seems like strange project management.

If upstream is recalcitrant but we still find a need or desire for the SDK utilities, then I suppose we bite the bullet and subsume the headers and ICD loader into one template as you've proposed.