[MPlayer-cvslog] r27240 - trunk/configure

[Michael Niedermayer]

On Tue, Jul 15, 2008 at 12:11:43AM +0300, Uoti Urpala wrote:
> 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? 

You said that it requires __asm__ instead of asm amongth other things.


> 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.

Thats nonsense as well, i just compiled ffmpeg with them sucessfully.


> 
> 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.

ROTFL


> 
> > > -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.

Thank you for sharing your hyphoteses.


> 
> > > 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).

1. We are not using "-std=gnu89"
2. We arent picking just from the options choosen by you. That is 
   gnu89 vs. gnu99
3. We != You


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

As the little brat decided ...


> 
> > 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". 

We should really use --std=uoti99


> There are exactly 3 available options worth considering: 

1. ban you
2. use you for some entertainment
3. ignore you


> gnu89
> (which was used before), gnu99 and c99. Moving from gnu89 to gnu99 is an
> improvement.

we did not use gnu89


> 
> > 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.

It is not 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?

We are not using gnu89 and did not and i did not suggest it and it is not 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.

we did not use gnu89

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-cvslog/attachments/20080714/11356247/attachment.pgp>