[Ffmpeg-devel] [PATCH] Correct inttypes.h emulation for VisualStudio

[Måns Rullgård]

Steve Lhomme <slhomme at divxcorp.com> writes:

> Diego Biurrun wrote:
>> On Tue, Dec 05, 2006 at 01:39:51PM +0100, Michel Bardiaux wrote:
>>> Luca Abeni wrote:
>>>> What's the problem with copying some "stdint.h" approximation somewhere
>>>> in the include path? (some windows users are saying that the typedefs
>>>> proposed in the patch that originated this thread work ok... So why not
>>>> putting them in the include path, but _outside_ ffmpeg's libraries?)
>>>> I think something like this has been proposed in this tread, but I am
>>>> failing to see why this solution would not fix the problem.
>>>>
>>>> I am serious: I understand that there are people that want to use libav*
>>>> in msvc projects, and I think this is not an unreasonable expectation
>>>> (of course, it is unreasonable to expect that other people will do the
>>>> work).
>>> The whole point of the thread is whether it is reasonable or not to
>>> wish for this work to be integrated in the main tree.
>> It will not be done.  So will somebody step forward and create an
>> inttypes emulation for MSVC that can be used by more than just
>> FFmpeg or will the MS crowd just continue lobbying for the easy way
>> out in vain?  I'm serious, will somebody provide a constructive
>> solution or will there be just more complaints?  We had a similar
>> situation with Intel Mac support.  Michael stood firm and rejected
>> the hacky solutions until finally somebody came up with an
>> acceptable patch.  The inttypes issue will be no different.
>
> The problem is: what is considered not a hack when attempting to
> support a compiler that is actively rejected ?

Giving a strict set of rules is difficult, but I know a hack when I
see one.

> IMO libavcodec, libavformat and libavutil are libraries, and
> therefore should be usable when you get a binary (DLL in this case)
> and the headers.

To use a library and its headers, you need a compiler that supports
the language the headers were written in.  You can't use libavcodec
with Fortran either, without translating the headers first, and Pascal
is completely impossible.

> In this case the headers are not sufficient

Wrong.  It's your compiler that is not sufficient.  Accept it and stop
whinging.

> and you have to look around on the net for the file you need or
> create the missing file from scratch.

Looks like your lucky day.  That broken compiler of yours turns out to
be rather easy to fix after all.

> If these libs were ever to be distributed on windows that would be a
> problem as the lib is not standalone.

Save for the odd zlib dependency, I'd argue that the ffmpeg libs are
quite standalone.  What will you be demanding next?  That we ship a
compiler with it so people don't have to install that themselves?
Maybe an entire OS.

> I think having a msvc/inttypes.h would be nice. You can call it
> c89/inttypes.h too. Then you can add something like this in the code:
>
> #if __STDC_VERSION__ < 199901L
> #include "c89/inttypes.h"
> #endif

And now I'm looking at a hack.

> BTW, Intel's compiler doesn't have a inttypes.h in its windows
> version. And it claims there's a C99 mode (/Qc99 flag). Although it
> could build FFMPEG with the ASM code is it supports the GNU format
> (and produce faster code than gcc).

What is that supposed to mean?  Can it or can it not compile ffmpeg?

-- 
M?ns Rullg?rd
mru at inprovide.com