r11326 - in trunk: configure libavutil/internal.h
Author: diego Date: Thu Dec 27 02:53:02 2007 New Revision: 11326 Log: Check for the presence of llrint(), lrint(), round() and roundf() and provide simple replacements if they are unavailable. patch by Michael Kostylev, mik niipt ru Modified: trunk/configure trunk/libavutil/internal.h Modified: trunk/configure ============================================================================== --- trunk/configure (original) +++ trunk/configure Thu Dec 27 02:53:02 2007 @@ -706,6 +706,8 @@ HAVE_LIST=" getrusage imlib2 inet_aton + llrint + lrint lrintf machine_ioctl_bt848_h machine_ioctl_meteor_h @@ -714,6 +716,8 @@ HAVE_LIST=" mkstemp mlib ppc64 + round + roundf sdl sdl_video_size soundcard_h @@ -1593,12 +1597,14 @@ done check_lib math.h sin -lm -# test for lrintf in math.h -check_exec <<EOF && enable lrintf || disable lrintf +# test for C99 functions in math.h +for func in llrint lrint lrintf round roundf; do + check_exec <<EOF && enable $func || disable $func #define _ISOC9X_SOURCE 1 #include <math.h> -int main(void) { return (lrintf(3.999f) > 0)?0:1; } +int main(void) { return ($func(3.999f) > 0)?0:1; } EOF +done enabled_any libamr_nb libamr_wb && enable libamr Modified: trunk/libavutil/internal.h ============================================================================== --- trunk/libavutil/internal.h (original) +++ trunk/libavutil/internal.h Thu Dec 27 02:53:02 2007 @@ -270,6 +270,20 @@ if((y)<(x)){\ }\ } +#ifndef HAVE_LLRINT +static av_always_inline long long llrint(double x) +{ + return rint(x); +} +#endif /* HAVE_LLRINT */ + +#ifndef HAVE_LRINT +static av_always_inline long int lrint(double x) +{ + return rint(x); +} +#endif /* HAVE_LRINT */ + #ifndef HAVE_LRINTF static av_always_inline long int lrintf(float x) { @@ -277,4 +291,18 @@ static av_always_inline long int lrintf( } #endif /* HAVE_LRINTF */ +#ifndef HAVE_ROUND +static av_always_inline double round(double x) +{ + return (x > 0) ? floor(x + 0.5) : ceil(x - 0.5); +} +#endif /* HAVE_ROUND */ + +#ifndef HAVE_ROUNDF +static av_always_inline float roundf(float x) +{ + return (x > 0) ? floor(x + 0.5) : ceil(x - 0.5); +} +#endif /* HAVE_ROUNDF */ + #endif /* FFMPEG_INTERNAL_H */
On Dec 27, 2007 3:53 AM, diego <subversion at mplayerhq.hu> wrote:
Author: diego Date: Thu Dec 27 02:53:02 2007 New Revision: 11326
Log: Check for the presence of llrint(), lrint(), round() and roundf() and provide simple replacements if they are unavailable. patch by Michael Kostylev, mik niipt ru
Modified: trunk/configure trunk/libavutil/internal.h
Would you be so kind when you commit changes in FFmpeg that break MPlayer to fix MPlayer too, instead of leaving it broken for (more than 2) days? You are still MPlayer developer, aren't you?
On Fri, Dec 28, 2007 at 04:46:26PM +0200, Ivan Kalvachev wrote:
On Dec 27, 2007 3:53 AM, diego <subversion at mplayerhq.hu> wrote:
Log: Check for the presence of llrint(), lrint(), round() and roundf() and provide simple replacements if they are unavailable. patch by Michael Kostylev, mik niipt ru
Modified: trunk/configure trunk/libavutil/internal.h
Would you be so kind when you commit changes in FFmpeg that break MPlayer to fix MPlayer too, instead of leaving it broken for (more than 2) days?
Would you be so kind as to either fix issues yourself or alternatively refrain from complaining? It's holiday season and I don't compile MPlayer multiple times a day.
You are still MPlayer developer, aren't you?
Send your sarcasm straight to /dev/null. As somebody who does little more than flame I would stay silent more often. Count the number of patches I managed to commit while all you managed to do was flame. Diego
On Dec 28, 2007 5:54 PM, Diego Biurrun <diego at biurrun.de> wrote:
On Fri, Dec 28, 2007 at 04:46:26PM +0200, Ivan Kalvachev wrote:
On Dec 27, 2007 3:53 AM, diego <subversion at mplayerhq.hu> wrote:
Log: Check for the presence of llrint(), lrint(), round() and roundf() and provide simple replacements if they are unavailable. patch by Michael Kostylev, mik niipt ru
Modified: trunk/configure trunk/libavutil/internal.h
Would you be so kind when you commit changes in FFmpeg that break MPlayer to fix MPlayer too, instead of leaving it broken for (more than 2) days?
Would you be so kind as to either fix issues yourself or alternatively refrain from complaining?
I had just found out. While I was writing fix somebody else proposed better one.
It's holiday season and I don't compile MPlayer multiple times a day.
It doesn't require super sharp coding skill to figure out that if ffmpeg configure is changed then probably mplayer configure may need to be changed too.
You are still MPlayer developer, aren't you?
Send your sarcasm straight to /dev/null. As somebody who does little more than flame I would stay silent more often. Count the number of patches I managed to commit while all you managed to do was flame.
You managed to commit 3 patches in MPlayer after the change here. I can hardly believe you don't have time to compile MPlayer before commit. Most probably you worked with outdated repository. All I want is this situation never to happen again. Would you be more careful in future?
On Fri, Dec 28, 2007 at 09:31:49PM +0200, Ivan Kalvachev wrote:
On Dec 28, 2007 5:54 PM, Diego Biurrun <diego at biurrun.de> wrote:
On Fri, Dec 28, 2007 at 04:46:26PM +0200, Ivan Kalvachev wrote:
On Dec 27, 2007 3:53 AM, diego <subversion at mplayerhq.hu> wrote:
Log: Check for the presence of llrint(), lrint(), round() and roundf() and provide simple replacements if they are unavailable. patch by Michael Kostylev, mik niipt ru
Modified: trunk/configure trunk/libavutil/internal.h
Would you be so kind when you commit changes in FFmpeg that break MPlayer to fix MPlayer too, instead of leaving it broken for (more than 2) days?
Would you be so kind as to either fix issues yourself or alternatively refrain from complaining?
I had just found out. While I was writing fix somebody else proposed better one.
I don't care when you find out about things. I repeat: Would you be so kind as to either fix issues yourself or alternatively refrain from complaining?
It's holiday season and I don't compile MPlayer multiple times a day.
It doesn't require super sharp coding skill to figure out that if ffmpeg configure is changed then probably mplayer configure may need to be changed too.
Good. This means there is no need for a build system guru to take care of things. In other words, you can do it yourself and you don't need to prod or flame me into doing it.
You are still MPlayer developer, aren't you?
Send your sarcasm straight to /dev/null. As somebody who does little more than flame I would stay silent more often. Count the number of patches I managed to commit while all you managed to do was flame.
You managed to commit 3 patches in MPlayer after the change here. I can hardly believe you don't have time to compile MPlayer before commit. Most probably you worked with outdated repository.
I don't distclean before every commit. It's simply not necessary.
All I want is this situation never to happen again. Would you be more careful in future?
I don't feel an obligation to fix any problems introduced by FFmpeg changes myself, irrespective of whether I did the actual commit or not. I'm also not inclined to do you any kind of favor, you do not return them anyway. If you want to avoid this situation *work* for it. No amount of flaming will help. Diego
On Jan 5, 2008 11:27 AM, Diego Biurrun <diego at biurrun.de> wrote:
I don't distclean before every commit. It's simply not necessary.
If you had updated svn and you had built valid dependencies, then modification of header file would cause recompilation of all modules that include it, without the need to make clean build. You made that build system, you should know how it works and why it exists.
I don't feel an obligation to fix any problems introduced by FFmpeg changes myself, irrespective of whether I did the actual commit or not.
Sounds like you don't give a damn about MPlayer. If you take a dog to a walk and it shits on the street, do you feel obligated to clean after it? Even if it is not your dog and you just walk it around. And if people who walk on the street complain to you, would you tell them to shut up and to clean it on their own?
On Wed, Jan 09, 2008 at 11:16:09PM +0200, Ivan Kalvachev wrote:
On Jan 5, 2008 11:27 AM, Diego Biurrun <diego at biurrun.de> wrote:
I don't feel an obligation to fix any problems introduced by FFmpeg changes myself, irrespective of whether I did the actual commit or not.
Sounds like you don't give a damn about MPlayer.
Funny to hear an inactive developer say that to an active developer. Diego
Hello, On Fri, Dec 28, 2007 at 04:54:53PM +0100, Diego Biurrun wrote:
On Fri, Dec 28, 2007 at 04:46:26PM +0200, Ivan Kalvachev wrote:
On Dec 27, 2007 3:53 AM, diego <subversion at mplayerhq.hu> wrote:
Log: Check for the presence of llrint(), lrint(), round() and roundf() and provide simple replacements if they are unavailable. patch by Michael Kostylev, mik niipt ru
Modified: trunk/configure trunk/libavutil/internal.h
Would you be so kind when you commit changes in FFmpeg that break MPlayer to fix MPlayer too, instead of leaving it broken for (more than 2) days?
Would you be so kind as to either fix issues yourself or alternatively refrain from complaining?
The point is that it is much easier for you than anyone else since you know what exactly changed and know configure quite well. I don't expect you to check every change to FFmpeg if it breaks MPlayer, nor do I think that you are "required" to fix it, but your response still seems over-the-top to me. Greetings, Reimar D?ffinger
Hi Reimar D?ffinger wrote:
Hello, On Fri, Dec 28, 2007 at 04:54:53PM +0100, Diego Biurrun wrote:
On Fri, Dec 28, 2007 at 04:46:26PM +0200, Ivan Kalvachev wrote:
Log: Check for the presence of llrint(), lrint(), round() and roundf() and provide simple replacements if they are unavailable. patch by Michael Kostylev, mik niipt ru
Modified: trunk/configure trunk/libavutil/internal.h Would you be so kind when you commit changes in FFmpeg that break MPlayer to fix MPlayer too, instead of leaving it broken for (more
On Dec 27, 2007 3:53 AM, diego <subversion at mplayerhq.hu> wrote: than 2) days? Would you be so kind as to either fix issues yourself or alternatively refrain from complaining?
The point is that it is much easier for you than anyone else since you know what exactly changed and know configure quite well. I don't expect you to check every change to FFmpeg if it breaks MPlayer, nor do I think that you are "required" to fix it, but your response still seems over-the-top to me.
If only Mplayer could stick with using FFmpeg API you would avoid many of the recurring problems. IMHO there shouldn't be any reason modifying FFmpeg libavutil/internal.h or configure would break Mplayer. Btw, demux_mkv.c is including <ffmpeg/intreadwrite.h> which is not an installed header. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
On Mon, 2008-01-07 at 01:44 +0100, Baptiste Coudurier wrote:
If only Mplayer could stick with using FFmpeg API you would avoid many of the recurring problems.
IMHO there shouldn't be any reason modifying FFmpeg libavutil/internal.h or configure would break Mplayer.
The latest breakages have not been related to the API but rather to the build system. Changes to FFmpeg's configure never break MPlayer as it doesn't use the script, but changing other files so that they need the build system to set new variables does cause breakage. In the latest case libavformat/os_support.h started defining socklen_t unless the build system set HAVE_SOCKLEN_T, causing an illegal redefinition on normal systems.
On Sun, Jan 06, 2008 at 07:59:55PM +0100, Reimar D?ffinger wrote:
On Fri, Dec 28, 2007 at 04:54:53PM +0100, Diego Biurrun wrote:
On Fri, Dec 28, 2007 at 04:46:26PM +0200, Ivan Kalvachev wrote:
On Dec 27, 2007 3:53 AM, diego <subversion at mplayerhq.hu> wrote:
Log: Check for the presence of llrint(), lrint(), round() and roundf() and provide simple replacements if they are unavailable. patch by Michael Kostylev, mik niipt ru
Modified: trunk/configure trunk/libavutil/internal.h
Would you be so kind when you commit changes in FFmpeg that break MPlayer to fix MPlayer too, instead of leaving it broken for (more than 2) days?
Would you be so kind as to either fix issues yourself or alternatively refrain from complaining?
The point is that it is much easier for you than anyone else since you know what exactly changed and know configure quite well. I don't expect you to check every change to FFmpeg if it breaks MPlayer, nor do I think that you are "required" to fix it, but your response still seems over-the-top to me.
Sure, I'm just very tired of Ivan who never has time or motivation to fix issues himself but never misses an opportunity to complain and flame. Diego
participants (6)
-
baptiste.coudurier＠smartjog.com -
diego＠biurrun.de -
ikalvachev＠gmail.com -
Reimar.Doeffinger＠stud.uni-karlsruhe.de -
subversion＠mplayerhq.hu -
uoti.urpala＠pp1.inet.fi