[FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
coding at dmik.org
Thu Apr 21 00:48:22 CEST 2016
On 2016-04-20 11:48:33 +0000, KO Myung-Hun said:
> No, it's not because ln_s overriding is already there. And there is just
> no need to replace it.
Wrong. "There is no need" sounds like if it were the truth but in fact
it's not, it's just your opinion.
> Did you present any real-life cases where not using symlinks in FFmpeg
> development hurts ?
Yes, I did. In detail. Please read my previous message closer.
> However, Dave reported some failure cases due to removing ln_s
Where did he do that? I didn't see it. He only mentioned that he often
gets less failures in his old environment than in the new one (by the
new one he refers to RPM/YUM with gcc 4.9.2 I suppose). But this
doesn't even mean that ln is involved here. Nor does it mean that ln
shouldn't be used per se if some tests fail (it would mean, however,
that I'd have to fix tests before asking for my patch to be accepted.
And if anybody gives me any evidence that FATE tests fail because of
*my* patch, I will fix it — when I have some spare time.)
> BTW, maybe aren't you thinking that FATE is not a part of
> FFmpeg development ?
It of course is. See above.
> Because it just does just what is already doing well, without any
Not true. I named you the benefits. And you still can't give me at
least one real problem of using ln instead of cp.
> In addition, I suggested that you check if ln -s works really
> before overriding ln_s, however you did not. I don't have to do it
> because FFmpeg already works well even if without it.
I asked you to do so because it's you who needs this in the first place
and who can test it in the environment that does not support symlinks.
My environment supports them so it's rather problematic to check. And
also this is what I call collaboration. BTW, when I work with your
patches to the projects that I maintain as a committer, I discuss it
with you and if you refuse to modify something in your patch because
you don't care, I simply do it myself and I give you credit for your
work. I expect something similar from you at least.
> I don't understand what you are saying. You disabled those DLL creations
> in this patch, didn't you ?
If you checked my patch and makefiles closer before arguing you would
understand me. There are two places where versioned DLLs are created:
the library build stage and the install stage. For the install stage it
was enough to remove a couple of variables. But the build stage always
first links avcodeXX.dll and then calls ln_s on it to create
avcodec.dll (via a separate target), this can't be altered via
variables. If you use cp, you will get a dumb and broken library that
will also be lxlite'd. If you use ln, the library will also be broken
but it will at least not occupy any disk space and will not be lxlite'd.
> There is nobody who is less busy than you, here. If you don't modify
> this patch yourself, nobody will do that. And who cares about divergent
> downstream ?
I do care about consistency, collaboration and prevention of artificial
entropy growth. But if I'm the only one who cares, I assure you I feel
perfectly fine maintaining our own BWW repositories and I also don't
need my name to be listed in the maintainers file or among commiters.
It's you who's sabotaging my work here without any particular reason
besides your religious belief that symlinks is evil. And it's quite
natural that in this situation I don't have any further wish to change
my patch just to make your internal believer happy. What about "ups"
and "downs", well, it's just a matter of viewport, please don't be so
A question to maintainers with commit rights: please clarify, what
should I do to have my patches applied?
CPO of bww bitwise works GmbH
More information about the ffmpeg-devel