Thread: [Mlt-devel] mlt/src/framework mlt_types.h,1.15,1.16
Brought to you by:
ddennedy,
lilo_booter
From: Dan D. <dde...@us...> - 2005-07-26 17:41:47
|
Update of /cvsroot/mlt/mlt/src/framework In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23802/src/framework Modified Files: mlt_types.h Log Message: Add names to enums to make newer versions of swig (noticed on 1.3.24) happy. Index: mlt_types.h =================================================================== RCS file: /cvsroot/mlt/mlt/src/framework/mlt_types.h,v retrieving revision 1.15 retrieving revision 1.16 diff -u -d -r1.15 -r1.16 --- mlt_types.h 24 Dec 2004 08:58:21 -0000 1.15 +++ mlt_types.h 26 Jul 2005 17:41:38 -0000 1.16 @@ -25,7 +25,7 @@ #include "mlt_pool.h" -typedef enum +typedef enum mlt_image_format_enum { mlt_image_none = 0, mlt_image_rgb24, @@ -35,14 +35,14 @@ } mlt_image_format; -typedef enum +typedef enum mlt_audio_format_enum { mlt_audio_none = 0, mlt_audio_pcm } mlt_audio_format; -typedef enum +typedef enum mlt_whence_enum { mlt_whence_relative_start, mlt_whence_relative_current, @@ -50,7 +50,7 @@ } mlt_whence; -typedef enum +typedef enum mlt_service_type_enum { invalid_type, unknown_type, |
From: Dan D. <da...@de...> - 2005-07-27 16:11:37
|
I don't know of any other solution. Why are you so concerned about ABI at this point? It's not like there are many users or widespread distribution. The ones who would be affected are already running off CVS HEAD and need to be willing to rebuild things if willing to do CVS updates, update FFMPEG from CVS routinely, etc. On Wednesday 27 July 2005 10:14 am, charlie wrote: > On Tue, 2005-07-26 at 17:41 +0000, Dan Dennedy wrote: > > Update of /cvsroot/mlt/mlt/src/framework > > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23802/src/framework > > > > Modified Files: > > mlt_types.h > > Log Message: > > Add names to enums to make newer versions of swig (noticed on 1.3.24) > > happy. > > Hmm - turns out that this sort of confuses MLT++ - mlt and mlt++ ABI is > preserved if you update mlt alone, but mlt++ linking gets confused if > you update mlt without a make clean all and install in mlt++. And that > action breaks ABI compatibility with stuff already linked to mlt++. > > Are there any solutions which preserve ABI? > > Cheers, > > Charlie |
From: charlie <cha...@pa...> - 2005-07-27 17:50:04
|
On Wed, 2005-07-27 at 11:29 -0400, Dan Dennedy wrote: > I don't know of any other solution. Why are you so concerned about ABI at this > point? It's not like there are many users or widespread distribution. General point of interest - have been focusing on ABI for a long time and haven't broke it for a while. > The > ones who would be affected are already running off CVS HEAD and need to be > willing to rebuild things if willing to do CVS updates, update FFMPEG from > CVS routinely, etc. Well, yes, but I still don't want to be forced to recompile everything that links to the libs just because I do an update, nor do I like finding odd behaviour simply because I've forgotten to do so... Thing is that I'm unsure of precisely what the problem is here - mlt and mlt++ compiled, and swig broke. That seems to point to a problem with the swig generated code doesn't it? AFAICT, there's nothing wrong with the original code.. |
From: charlie <cha...@pa...> - 2005-07-27 17:13:25
|
On Tue, 2005-07-26 at 17:41 +0000, Dan Dennedy wrote: > Update of /cvsroot/mlt/mlt/src/framework > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23802/src/framework > > Modified Files: > mlt_types.h > Log Message: > Add names to enums to make newer versions of swig (noticed on 1.3.24) happy. Hmm - turns out that this sort of confuses MLT++ - mlt and mlt++ ABI is preserved if you update mlt alone, but mlt++ linking gets confused if you update mlt without a make clean all and install in mlt++. And that action breaks ABI compatibility with stuff already linked to mlt++. Are there any solutions which preserve ABI? Cheers, Charlie |