[FFmpeg-devel] [PATCH 5/5] build: rename version.h tolibavutil/ffversion.h

[James Almer]

On 29/11/13 5:45 AM, Don Moir wrote:
> ----- Original Message ----- From: "James Almer" <jamrial at gmail.com>
> To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
> Sent: Thursday, November 28, 2013 10:04 PM
> Subject: Re: [FFmpeg-devel] [PATCH 5/5] build: rename version.h tolibavutil/ffversion.h
> 
> 
>> On 28/11/13 11:38 PM, Timothy Gu wrote:
>>> On Nov 28, 2013 6:25 PM, "James Almer" <jamrial at gmail.com> wrote:
>>>>
>>>> On 28/11/13 10:00 PM, Timothy Gu wrote:
>>>>> Also the libavutil/ffversion.h will be installed.
>>>>>
>>>>> Rationale:
>>>>> * Applications might want to know FFmpeg's version besides the
>>> individual
>>>>>   libraries'.
>>>>> * Avoids file name clash between FFmpeg's ./version.h and
>>> lib*/version.h when
>>>>>   a library source file includes both and is compiled on an out-of-tree
>>> build.
>>>>>
>>>>
>>>> Missing minor bump for lavu.
>>>
>>> Do I need to add it to APIChanges?
>>>
>> It's a new installed header, so I'd say yes.
>>
>>>> You could add a line here mentioning this closes ticket #1769.
>>>
>>> This doesn't close #1769. The ticket is about configure options, this is
>>> about version. (I have a separate patch for that too, see the ticket)
>>
>> I interpreted that ticket as requesting the ffmpeg build string from version.h,
>> and not the list of configure arguments, being available outside of the build
>> environment.
>>
>> If you're reading this Don Moir, could you clear things up?
> 
> FFMPEG_VERSION as defined in header version.h created by version.sh uniquely 
defines the build of the libraries I send out. I have an interface library to the 
ffmpeg libraries that an application deals with. That is, there is no need for 
application to know anything about the ffmpeg libraries as far as interfacing and 
my interface simplifies things as well as adds more capability.
> 
> I provide this FFMPEG_VERSION and the version of my interface back to the calling 
app for tracking etc.
> 
> I could include the appropriate version.h file but messy with name collisions and
still would mean I have do something a little different in order to retrieve this
string. Right now after a build I grab the FFMPEG_VERSION from version.h and just 
code it into my interface library which is not a big deal and works best for me 
currently.
> 
> I would prefer that it be in the public header avutil.h if that makes the most 
sense to you and others. The lib_version functions don't define the absolute build 
and really don't point to anything useful for my intended purpose.

FFMPEG_VERSION can't be in avutil.h since it's a string created at compile time,
and i don't think avutil.h can be edited automatically just like that.
This patch should work for you since it installs the header containing the define 
as ffversion.h inside lavu.

So yes, it does fix ticket #1769 after all.

Regards.