[MPlayer-cvslog] r27240 - trunk/configure

[Uoti Urpala]

On Mon, 2008-07-14 at 21:58 +0200, Michael Niedermayer wrote:
> On Mon, Jul 14, 2008 at 10:45:58AM +0200, Diego Biurrun wrote:
> > Stop flaming already.
>
> And accept the lies of uoti and your lack of any clue about the subject?
> 
> As an example of one of uotis lies, try
> --std=c99 -fasm it will compile asm() just fine.

What do you claim is a lie? Are you saying it's not true that -std=c99
is not so easy to use, and we could use it if we simply add -fasm too?
If so then you're wrong.

If you want to claim that the option should have been changed to
-std=c99 instead of -std=gnu99 then test compiling MPlayer with -std=c99
first. And note that even if you manage to make it compile on one system
that doesn't show there are no problems because of issues with external
headers.

> > -std=gnu99 is closer to C99 than -std=gnu89, period.  
> 
> That may be true but we did NOT explicitly use -std=gnu89

Whether it was used explicitly or implicitly makes very little
difference.

> > This change
> > already helped find and fix some non-C99 constructs in FFmpeg.  If you
> > want to see -std=c99 used, then make FFmpeg compilable with that flag,
> > which is a prerequisite for MPlayer to use it.
> 
> I did not suggest --std=c99 to be used. I just said that there are many
> solutions and --std=gnu99 is the worst. And not what we want at all ...

You said there are other possible solutions to the particular issue of
glibc not defining certain standard functions. However even if that
issue did not exist at all we'd STILL want -std=gnu99 rather than the
default -std=gnu89 (to get standard inline behavior etc).

So even if those defines you talked about were added for the benefit of
other compilers we'd still keep -std=gnu99 for GCC.

> Of course that does not mean that --std=c99 should not be considered, just
> that these 2 are not the only options.

The most relevant question for the issue of whether to use -std=gnu99 is
not "how to solve the header problem" but "what language standard should
we use". There are exactly 3 available options worth considering: gnu89
(which was used before), gnu99 and c99. Moving from gnu89 to gnu99 is an
improvement.

> What -std=gnu99 enables is nowhere clearly defined. Its not mentioned in any
> standard document. The assumtation that gnu99 would enable exactly what
> we want to use and nothing we do not want to use due to portability issues
> is ridiculous.

It doesn't enable "exactly what we want to use". However it is a closer
match than the gnu89 that was used before, and no worse defined.

> How could gcc even know what we want? Compared to what other lets say gnu
> projects want?
> Its clear gnu99 enabled one of the #defines mentioned above otherwise the
> missing prototypes would not be there as they are protected by #ifdefs
> Its also clear it enabled -fasm.
> What else does it enable? Do we want all of it?

Why do you think using gnu89 would be any better?

> Why do we not just enable one of the defines directly like the standards
> recommand??? This would work with any compiler. --std=gnu99 will only
> work with gnu compatible compilers. 

I'm not against adding such defines. However even if they're added there
is no reason to go back to gnu89 with gcc.