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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
