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

Dmitriy Kuminov coding at dmik.org
Wed Apr 20 02:57:03 CEST 2016


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.

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

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

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

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

-- 
Kind regards,
Dmitriy Kuminov
CPO of bww bitwise works GmbH


More information about the ffmpeg-devel mailing list