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

[KO Myung-Hun]

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.

Thanks.

-- 
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