[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