On 2015-07-01 16:31:42 +0200, Luca Barbato wrote: > On 01/07/15 15:59, 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. > > --- > > Don't forget the version bump. > > --- > > doc/APIchanges | 3 +++ > > libavutil/avutil.h | 7 +++++++ > > libavutil/utils.c | 6 ++++++ > > 3 files changed, 16 insertions(+) > > > > diff --git a/doc/APIchanges b/doc/APIchanges > > index 5d39ec6..e309834 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 avutil_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..126f047 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 *avutil_version_info(void);
I'd prefer av_version_info() > > + > > +/** > > * Return the libavutil build-time configuration. > > */ > > const char *avutil_configuration(void); > > diff --git a/libavutil/utils.c b/libavutil/utils.c > > index c8c161d..1b5acd5 100644 > > --- a/libavutil/utils.c > > +++ b/libavutil/utils.c > > @@ -18,12 +18,18 @@ > > > > #include "config.h" > > #include "avutil.h" > > +#include "../version.h" > > Probably the file can be moved to libavutil as well. no, it can't. That is the auto generasted version header. Besides renaming the top level version.h. #include_next would work if it were standard C. The "../version.h" is probably the simplest solution. A explanatory comment would be welcome though. Janne _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
