Diederick C. Niehorster: > 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?
Yes (presuming there are (or will eventually be) users of this in different translation units). - Andreas _______________________________________________ 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".
