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