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

[Don Moir]

----- Original Message ----- 
From: "James Almer" <jamrial at gmail.com>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Friday, November 29, 2013 9:52 AM
Subject: Re: [FFmpeg-devel] [PATCH 5/5] build: rename version.htolibavutil/ffversion.h


> 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.

Right, but a simple file copy such as version.h to avutil/ffmpeg_version.h after build would work. Then you could just include if 
needed. The other thing is version.h may not be available and just depends on how and where you built I think

Since I build ffmpeg on linux, this doesn't bother me too much, but for some it would not be available if say you downloaded from 
zernoe or whatever. Basically the version.h file would not be included with normal headers. Think there is a comment somewhere that 
in essence says FFMPEG_VERSION should not be used by app but there is nothing better.

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

Thanks James, I will check what you did shortly.