[Ffmpeg-devel] [PATCH] Partial port of ffmpeg to MS Visual C - and a note on the inttypes.h issue

[Steve Lhomme]

Aurelien Jacobs wrote:
> On Tue, 30 Jan 2007 09:25:38 +0100
> Steve Lhomme <steve.lhomme at free.fr> wrote:
> 
>> Michael Niedermayer wrote:
>>> Hi
>>>
>>> On Mon, Jan 29, 2007 at 10:15:00AM +0100, Steve Lhomme wrote:
>>>> Alex Beregszaszi wrote:
>>>>> Hi,
>>>>>
>>>>>>> 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.
> 
> Why would nasm or yasm be more portable than gas for example ?
> Do nasm or yasm support ppc, arm, alpha, sparc, sh4... ?

WTH are you talking about ? I'm saying that the hardware acceleration 
could be available to more than a tuned gcc, not that ASM code is 
portable across platforms.

Steve