You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We no longer depend on OpenCL library nor headers being available on the system at build time (we load the library dynamically at runtime, and we use our own copy of the headers), but we still check for both in configure and don't enable OpenCL support if either or both are missing.
Do we want to continue checking (I think @claudioandre-br said so)? If so, or regardless, do we possibly want explicit --enable-opencl to override any checks (just like --disable-opencl would)? I've just tested, and it does not yet do that, and indeed we currently only document --disable-opencl. We'll also need to document --enable-opencl if we start supporting it.
As to the default, if we do continue checking, then maybe check only for the library? We definitely don't need the headers anymore, at all, but the library we'd use at runtime, so it makes more sense to check for it. Alternatively, we could make the check an OR - enable OpenCL support by default if at least one of the two - library or headers - is found at build time, indicating that the system is possibly meant to work with OpenCL and is maybe just slightly misconfigured.
The text was updated successfully, but these errors were encountered:
We still check the library. We still do not have --enable-opencl that could be used to build with OpenCL on library-less systems - I think we should at least add that.
I really would like to have --enable-opencl at least for build-testing of changes to OpenCL host code on systems without OpenCL.
Also for --fuzz of OpenCL formats' hash parsing, including on CI, without needing to install an OpenCL library in there. Edit: this use case probably needs more changes, as we currently initialize an OpenCL device even during --fuzz of such formats.
@claudioandre-br Do you want to implement --enable-opencl, please? Looks like besides the reasons in my previous comments here, it'd also let us simplify the documentation. There would be no need to provide an OpenCL library path at build time. Such path, if provided, does not currently help john find the library at runtime anyway.
We no longer depend on OpenCL library nor headers being available on the system at build time (we load the library dynamically at runtime, and we use our own copy of the headers), but we still check for both in
configure
and don't enable OpenCL support if either or both are missing.Do we want to continue checking (I think @claudioandre-br said so)? If so, or regardless, do we possibly want explicit
--enable-opencl
to override any checks (just like--disable-opencl
would)? I've just tested, and it does not yet do that, and indeed we currently only document--disable-opencl
. We'll also need to document--enable-opencl
if we start supporting it.As to the default, if we do continue checking, then maybe check only for the library? We definitely don't need the headers anymore, at all, but the library we'd use at runtime, so it makes more sense to check for it. Alternatively, we could make the check an OR - enable OpenCL support by default if at least one of the two - library or headers - is found at build time, indicating that the system is possibly meant to work with OpenCL and is maybe just slightly misconfigured.
The text was updated successfully, but these errors were encountered: