On Tue, Jun 8, 2021 at 1:54 AM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote:
> Diederick Niehorster: > > NB: will break build, makes needed corresponding changes to avformat. > > > > Then said changes should be part of this patch. Patches should be > logically self-contained and atomic; this is not the same as splitting > by file/library. > > But that is a moot point: James already told you a better way to fix this. > Made sense. But indeed, James' way of doing it obviates that next patch changing avformat.h > > --- a/libavdevice/internal.h > > +++ b/libavdevice/internal.h > > We prefer the order libavutil-libavcodec-libavformat (the reverse of > linking order). > fixed. > > + * AVOption table used by devices to implement device capabilities API. > Should not be used by a user. > > That last part is superfluous, as (external) users by definition have no > business looking into internal.h. > Ah yes, copy paste.. Fixed. > > + */ > > +extern const AVOption av_device_capabilities[]; > > Don't use this name: av_* is our namespace for public symbols. Our > linker script makes sure that all symbols that start with av_* are > exported; whether they are in a public header is irrelevant. > Not exporting the symbol in the first place also solves the problem of > users using it despite it not being part of the API. > (I btw don't know whether said linker script is used on Windows.) > I changed it to a ff_ prefix. Is that correct? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
