[Ffmpeg-devel] [PATCH] Partial port of ffmpeg to MS Visual C - and a note on the inttypes.h issue
Tue Jan 30 09:25:38 CET 2007
Michael Niedermayer wrote:
> On Mon, Jan 29, 2007 at 10:15:00AM +0100, Steve Lhomme wrote:
>> Alex Beregszaszi wrote:
>>>>> If you really want to be that gnucentric,
>>>> do you know why everyone who uses visual <bluescreen, restarts system) C++
>>>> has a problem with understanding the different between standart and gcc?
>>>> we HATE gcc and we certainly are not, where not and never will be
>>>> gnucentric, ffmpeg code is stanard C, everything else is under #ifdefs
>>>> like asm, always_inline and so on
>>>> it must be something like
>>>> * user sees vc++ fail with random program
>>>> * user sees gcc to suceed with same random program
>>>> * user concludes that program is written specifically for gcc as he knows
>>>> MS always follows all standards very carefully
>>> Thats a great point here.
>> It's like the difference between people who prefer to use C99 and the
>> ones who prefer to use a real-world compiler.
>> Anyway, C99 doesn't cover inline ASM AFAIK so you can't seriously say
>> that FFMPEG is not designed for gcc.
> you know very well that they are under #ifdefs (some of the other people
> who claimed that ffmpeg where written for gcc may or may not have known that
> but you do as you have worked with the code) so could you maybe spare
The ASM code is #ifdef'd by the makefile. If you compile the code with
another compiler it will fail because the ifdefs are not clean. I
actually made some changes recently to DrFFMPEG to have both ppc and
i386 ASM compiled in the same project at the same time (to make
universal binaries in XCode) and I had to add some cleaner #ifdef's.
Nevertheless, the "full" FFMPEG is only usable with a tuned gcc. That's
my whole point. Portable ASM files (to be processed by nasm and yasm) is
always possible and make the code much more portable. But I understand
it's not the goal of this project.
More information about the ffmpeg-devel