-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reconsider --enable-opencl / --disable-opencl #5397
Comments
We no longer check the headers due to @claudioandre-br's #5398. We still check the library. We still do not have |
@claudioandre-br I really would like to have |
Also for |
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: