[FFmpeg-devel] [PATCH] define _BSD_SOURCE for bktr.c

[Jacob Meuser]

On Sat, Dec 13, 2008 at 10:16:45PM +0100, Reimar D?ffinger wrote:
> On Sat, Dec 13, 2008 at 08:54:29PM +0000, Jacob Meuser wrote:
> > On Sat, Dec 13, 2008 at 02:26:57PM +0100, Reimar D?ffinger wrote:
> > > On Sat, Dec 13, 2008 at 01:07:15PM +0100, Reimar D?ffinger wrote:
> > > > > patch-tests_regression_sh: half-merged, half mysterious
> > > > 
> > > > I just realized I made a bad assumption there, the sed expression
> > > > probably is wrong...
> > > > Which of course also means all this not a good solution, since we have
> > > > two different md5 binaries with no way to distinguish them except that
> > > > hopefully one is in the path and the other in /sbin, which is a bad
> > > > way...
> > > > I'll check if sed 's#.*= ##' is the right one (too many of the
> > > > regression tests fail, which is why I missed it originally).
> > > 
> > > Oh silly me, it actually works right in the regression tests, I forgot
> > > to add -r when trying it on the command-line, so that part is okay.
> > > The LD_LIBRARY_PATH is just to allow make test without installing first,
> > > but it's not portable (e.g. won't work on Windows).
> > 
> > and did I submit this to you guys?  no.  why?  because it's not
> > for upstream inclusion.  so why bother saying it's not portable
> > to Windows?
> 
> Well, because there is a lot of other stuff you did not submit but is
> necessary to make ffmpeg work on OpenBSD and acceptable.
> So we have to find out ourselves which parts are good and which are not,
> and I made clear that one isn't. In particular, it was not directed at
> you. And in particular 2) I felt the need to say it because I would have
> considered such a thing useful in the past too, but decided it to be a
> bad idea, in particular because of that.
> 
> > it's like complaining that OpenBSD doesn't follow standards, then when
> > it does (_BSD_SOURCE vs POSIX), you complain that it's stupid.
> 
> Uh, I only complained that its very own headers are not compatible amongst
> each other. Obviously sys/types.h should not define u_short etc. without
> _BSD_SOURCE but the bktr header should either fail in a cleaner way or
> not require u_short.
> 
> > I dropped maintainership of ffmpeg because of all this needless
> > bashing.  I hope you don't get an onslaught of idiots trying to
> > make ffmpeg work on OpenBSD ...
> 
> I'm sorry if you do not like it, but the current OpenBSD patches
> IMHO certainly do not qualify as a "good" way of making it work,
> and if you truly think of most of them as more as quick-and-dirty hacks
> I don't think it can get that much worse.
> Still, bashing certainly was not even remotely the intention, getting
> things fixed was, a bit of bashing just makes all these workarounds a
> bit less annoying.

I have tried bringing up many of these issues in the past.  I was
told to fix OpenBSD.  I tried.  I got gmake updated.  I don't maintain
gcc, nm, or od or any of that other stuff.  I mentioned some issues
but didn't get much response.  I didn't really push it because it
seems silly to add the nm/od "standards compliance features" for just
one configure script (yes, ffmpeg is the only one).

maybe the way I was doing things wasn't quite the best, but there
was no review, just bashing.

and now I'm being told I never did anything.  that's pretty insulting.

-- 
jakemsr at sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org