On 01/07/15 20:01, wm4 wrote:
> This returns something like "v12_dev0-1332-g333a27c". This is much more
> useful than the individual library versions, of which there are too
> many, and which are very hard to map back to releases or git commits.
> ---
> - comment on the ../version.h include
> - rename to av_version_info(), as it's more popular
> ---
>  doc/APIchanges     | 3 +++
>  libavutil/avutil.h | 7 +++++++
>  libavutil/utils.c  | 8 ++++++++
>  3 files changed, 18 insertions(+)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 5d39ec6..f3026b7 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -13,6 +13,9 @@ libavutil:     2014-08-09
>  
>  API changes, most recent first:
>  
> +2015-xx-xx - xxxxxxx - lavu 56.xx.0
> +  Add av_version_info().
> +
>  2015-xx-xx - xxxxxxx - lavc 56.23.0
>    Add av_vda_default_init2.
>  
> diff --git a/libavutil/avutil.h b/libavutil/avutil.h
> index f056415..8ca773e 100644
> --- a/libavutil/avutil.h
> +++ b/libavutil/avutil.h
> @@ -164,6 +164,13 @@
>  unsigned avutil_version(void);
>  
>  /**
> + * Return an informative version string. This usually the actual release 
> version
> + * number and a git hash. This string has no fixed format and can change any
> + * time. It should never be parsed by code.
> + */
> +const char *av_version_info(void);
> +
> +/**
>   * Return the libavutil build-time configuration.
>   */
>  const char *avutil_configuration(void);
> diff --git a/libavutil/utils.c b/libavutil/utils.c
> index c8c161d..a5f9c80 100644
> --- a/libavutil/utils.c
> +++ b/libavutil/utils.c
> @@ -19,11 +19,19 @@
>  #include "config.h"
>  #include "avutil.h"
>  
> +// For LIBAV_VERSION. libavutil/version.h does not provide this symbol.
> +#include "../version.h"
> +
>  /**
>   * @file
>   * various utility functions
>   */
>  
> +const char *av_version_info(void)
> +{
> +    return LIBAV_VERSION;
> +}
> +
>  unsigned avutil_version(void)
>  {
>      return LIBAVUTIL_VERSION_INT;
> 

Sounds good enough to me.

lu
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to