[FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.

KO Myung-Hun komh78 at gmail.com
Wed Apr 20 13:48:33 CEST 2016

Dmitriy Kuminov wrote:
> On 2016-04-19 12:56:23 +0000, KO Myung-Hun said:
>> I don't understand why you insist on using symlink. Even if without it,
>> current FFmpeg works well, maybe better in according to Dave. I don't
>> know what is the benefit from using symlink.
> Likewise, I don't understand why you insist on not using symlink. Even
> with it, current FFmpeg works well, maybe better in according to me. I
> don't know what is the benefit from not using symlink.
> I wrote it just to show that my statement is as valid as yours.

No, it's not because ln_s overriding is already there. And there is just
no need to replace it.

>> And it is you who would be affecting other people due to a personal
>> favor.
> I don't see how my "personal favor" differs from your "personal favor"
> here. The fact that you and Dave share the same idea of not liking
> symlinks doesn't make it less personal. You didn't present any real-life
> case where using symlinks in FFmpeg develompent hurts.

Did you present any real-life cases where not using symlinks in FFmpeg
development hurts ?

However, Dave reported some failure cases due to removing ln_s
overriding. BTW, maybe aren't you thinking that FATE is not a part of
FFmpeg development ?

>>  I just don't feel to do support symlink on OS/2 because it has no
>> additional benefits. In addition, symlink is not a must-feature, unlike
>> python's virtualenv.
> You are not right, there are benefits. Symlinking a DLL is much faster
> than copying it over and requires less disk space, after all (which is
> somewhat essential for debug builds with a lot of HLL info, e.g. debug
> avcode56.dll is 42 MB here). And it also won't be lxlite'd (which also
> saves a bit of build time). Also, in FFmpeg 3.x symlinking is used to
> bring src into the build tree which shortens source paths considerably.
> All these are rather minor things, I agree, but your insistence in not
> using symlinks has NO real benefits at all.

At least, it passes FATE in according to Dave.

>> I doubt that refusing to write codes for unnecessary features is not
>> collaborative.
> I doubt that you can ultimatively decide which feature is necessary and
> which is not.

Because it just does just what is already doing well, without any
benefits. 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.

>> Finally, ln_s part is not related to the other parts. Split this patch
>> into ln_s part and others, and re-send newly versioned patches, please.
> Well, it has some relation to patch 2/3 because it allows to avoid
> creating an unneeded copy of an (un-)versioned DLL. It could also be

I don't understand what you are saying. You disabled those DLL creations
in this patch, didn't you ?

> separated but unfortunately I don't have any more time to work on these
> patches (as it turns out - just to please you). You can modify it
> yourself if you wish (and if you are fine with the fact that it will
> keep our branches diverged) but please give me some credit in the commit
> message if the essential part of my patch remains.

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 think, we confirmed the opinion of each other. No more discussions are
helpful. Nevertheless, if you want to discuss more, mail me privately.


KO Myung-Hun

Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr

More information about the ffmpeg-devel mailing list