Charles Wilson wrote:
Diego Biurrun wrote:
llrint is required, so I guess Cygwin compilation will indeed be
broken for a while. We don't add OS-specific workarounds to FFmpeg.
I call shenanigans.
Next time you call shenanigans, get your facts straight first please. I
never claimed that we do not *have* OS-specific workarounds, I said we
do not *add* them.
> The libavcodec directory has entirely separate
subdirs for different processors -- platform specificity is BUILT IN to
the ffmpeg source tree.
Nonsense. These are assembler optimizations for speed-critical
functions (and the reason why you can watch movies without GHz CPUs).
These are, by their very nature, processor-specific, but they are not
workarounds. Nothing could be further from the truth.
> That file ALSO contains a
half-dozen implementations of read_time depending on which
microprocessor architecture is in use.
What does this have to do with a workaround? read_time is internally
used in some benchmarking macros, it is not an OS function.
Oh, and lookee here, in the same file:
#ifndef HAVE_LRINTF
/* XXX: add ISOC specific test to avoid specific BSD testing. */
/* better than nothing implementation. */
/* btw, rintf() is existing on fbsd too -- alex */
static av_always_inline long int lrintf(float x)
{
return (int)(rint(x));
}
#endif /* HAVE_LRINTF */
Good catch, this is cruft from ages ago. I will look into nuking this
very soon.
So, we have:
architecture-specific workarounds
compiler-specific workarounds
OS-specific workarounds
AND capability-specific (!HAVE_FOO) workarounds
All god's chillins gots workaround code. "We don't add OS-specific
workarounds", indeed...
So all in all you have refuted some points I never made, while bungling
some of the research used to substantiate your claims. What is the
point you are trying to prove here?
best regards
Diego
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/