It is unclear from looking at 22f186c9f5 (Add vim package., 2013-11-05)
why its `package` function needed to invoke `make install` twice.
Whatever reason there might have been, it does not look as if it should
be necessary anymore. So let's drop the first one, assuming that the
second invocation would have fixed whatever the first invocation got
wrong.
Incidentally, this patch fixes the build of newer `vim` versions that
would otherwise fail like this:
[...]
cd /C/_/vim/pkg/vim/usr/bin; ln -s vim.exe ex
ln: failed to create symbolic link 'ex': File exists
make[1]: *** [Makefile:2693: /C/_/vim/pkg/vim/usr/bin/ex] Error 1
make[1]: Leaving directory '/C/_/vim/src/vim-9.0.1907/src'
make: *** [Makefile:39: install] Error 2
==> ERROR: A failure occurred in package().
Aborting...
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The major Perl version is encoded in the file name of the Perl DLL,
which makes it much more desirable to link _dynamically_ to the DLL,
i.e. on demand. Otherwise `vim.exe` would not even start unless Perl is
installed, at the exact expected version.
However, due to a bug, even `--enable-perlinterop=dynamic` would let
`vim.exe` link to the Perl DLL, defeating the purpose of the `dynamic`
part.
This was fixed in the VIM project, via
https://github.com/vim/vim/commit/55460da26c27, and here is a backport
to get this fix into MSYS2.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In some cases this will introduce cycles which could likely be cleaned
up by only depending on some unix tools instead of the whole autotools.
Rebuilding doesn't make much sense at this point since it just adds a subset
of base-devel which is still installed by default.
We haven't updated quite in a while, and it would appear that our
current VIM is susceptible to CVE-2019-12735 (reported via
https://github.com/git-for-windows/git/issues/2232).
So let's just update to the latest version and get all kinds of
fixes/features.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
