[FFmpeg-devel] [VOTE] drop support for using libav* compiled with mingw/cygwin in msvc

Måns Rullgård mans
Tue Feb 26 22:25:56 CET 2008


"Ivan Kalvachev" <ikalvachev at gmail.com> writes:

> On Tue, Feb 26, 2008 at 10:44 PM, M?ns Rullg?rd <mans at mansr.com> wrote:
>>
>> Ramiro Polla <ramiro at lisha.ufsc.br> writes:
>>
>>  > Hello,
>>  > Aurelien Jacobs <aurel <at> gnuage.org> writes:
>>  >
>>  >>
>>  >> Michael Niedermayer wrote:
>>  >>
>>  >> > Hi
>>  >> >
>>  >> > r12154 has as it seems broken the in the past supported use of
>>  >> > mingw/cygwin compiled libav* in msvc. Also the change has increased
>>  >> > code complexity and size. I was already mildly against this change
>>  >> > before it was commited though i left it to mans to decide. Now as it
>>  >> > breaks use of libav* under msvc iam more strongly against it ...
>>  >> >
>>  >> > Anyway, my vote is to revert it. Theres no advantage in this commit
>>  >> > and it breaks what was supported and also documented as such in the
>>  >> > docs.
>>  >>
>>  >> I'm not in favor of dropping msvc support for no good reason (but I
>>  >> think it wasn't the goal of r12154 either).
>>  >> But I would like to keep something similar to current code (ie.
>>  >> avoid duplicating version number).
>>  >> And there's no reason we can't have both. So I vote for improving
>>  >> current code to make msvc happy without duplicating version number.
>>  >>
>>  >> The patch proposed in this thread uses something like this:
>>  >>
>>  >> #define LIBAVCODEC_VERSION_MAJOR  51
>>  >> #define LIBAVCODEC_VERSION_MINOR  50
>>  >> #define LIBAVCODEC_VERSION_MICRO   1
>>  >>
>>  >> This solution adds one more advantage: no one will confuse minor
>>  >> and micro anymore.
>>  >> Would this be an acceptable compromise ?
>>  >
>>  > I vote for this solution. It is pretty much what I proposed some
>>  > time ago (and was declared "much messier" by Mans).
>
> I'm in favor of the new "messy" code, too.
>
>>
>>  Fine, I give in.  But now it's even more "code"...
>
> I'd say that including avutil.h inside postprocess.h just to use one
> internal macro and nothing else is far more messy than ...

It's one #include line.  That can't be messy.  Until you have
something more substantial to back your accusations, please keep
quiet.  FYI, postprocess_internal.h already #includes avutil.h.

> sorry can't came up with anything more messy.

I'll help you out on this one: MPlayer.

> I guess you should redefine you definition of messy. You can't simply
> measure mess with code size. By all means obfuscated code is usually
> quite shorter.

To me, code is messier if it is longer without being either faster or
more readable.  In fact, lots of simple code can be just as hard to
read as a small piece of magic.

-- 
M?ns Rullg?rd
mans at mansr.com




More information about the ffmpeg-devel mailing list