On 12/08/14 8:13 PM, Michael Niedermayer wrote:
> On Tue, Aug 12, 2014 at 07:31:58PM -0300, James Almer wrote:
>> On 11/08/14 11:33 PM, Michael Niedermayer wrote:
>>> Its API is marked as experimental, we should not export experimental API
>>> from shared libs
>>>
>>> Signed-off-by: Michael Niedermayer <michae...@gmx.at>
>>> ---
>>> configure | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/configure b/configure
>>> index 0ac6132..84d308e 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -4861,7 +4861,9 @@ enabled opencl && { check_lib2 OpenCL/cl.h
>>> clEnqueueNDRangeKernel -Wl
>>> die "ERROR: opencl not found"; } &&
>>> { check_cpp_condition "OpenCL/cl.h"
>>> "defined(CL_VERSION_1_2)" ||
>>> check_cpp_condition "CL/cl.h"
>>> "defined(CL_VERSION_1_2)" ||
>>> - die "ERROR: opencl must be installed and
>>> version must be 1.2 or compatible"; }
>>> + die "ERROR: opencl must be installed and
>>> version must be 1.2 or compatible"; } &&
>>> + { enabled shared &&
>>> + die "ERROR OpenCL API is experimental and
>>> not safe to be used with shared libs"; }
>>> enabled opengl && { check_lib GL/glx.h glXGetProcAddress "-lGL"
>>> ||
>>> check_lib2 windows.h wglGetProcAddress
>>> "-lopengl32 -lgdi32" ||
>>> check_lib2 OpenGL/gl3.h glGetError
>>> "-Wl,-framework,OpenGL" ||
>>>
>>
>> The API hasn't been touched in several months and is functional, and
>> considering
>> distros already link to opencl if available in previous ffmpeg releases, i
>> don't
>> know if removing the feature like this is a good idea.
>> Of course they can just remove this check and keep using opencl if they want
>> to,
>> but that's besides the point.
>>
>> Maybe a warning instead?
>
> The question is if people intend to change the API and IIRC its
> design makes it hard to make changes without breaking ABI
OpenCL maintainers should probably chime in at this point. CCing Wei Gao then.
>
> i can add a warning if preferred but i think we either should
> choose to support the ABI/API until the next bump which wouldnt
> need a warning or not support it in which case we probably should
> disable it hard for shared libs or put a warning in the release notes
> where its hard to miss
A warning in release notes and in the configure script is IMO preferable than
disabling existing functionality, but i'm fine doing whatever causes the less
headaches for everyone.
>
> [...]
>
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
