The "busybox --install" step has always been an unfortunate extra step
that I've watned to eliminate. I hoped I could do it via batch scripts
command "aliases". However, each aliased command has cmd.exe as its
parent interfering with its operation — particularly the disruptive and
infamous "Terminate batch job (Y/N)?" message which cannot be disabled.
The usual suggestion when people complain about this misfeature is to
use PowerShell. However, unlike batch scripts, PowerShell scripts are
not first class citizens on Windows. PowerShell is not always available
(often disabled by the adminstrator), and its scripts generally can't be
installed on and executed via the PATH, at least not without system-wide
configuration (i.e. PATHEXT).
The here is to use a tiny 4kB executable as a kind of crude compiled
shell script that, unlike cmd.exe, does the right thing. Since there are
so many, it adds about 150kB to the final .zip, but it does eliminate
this finall installation step.
Unlike batch script aliases, this program will be well-behaved and will
not produce a disruptive "Terminate batch job (Y/N)" prompt. The program
is always compiled freestanding in order to be as small as possible.
Interactive programs (vi, vim, gvim, vimtutor) are fine with a batch
script alias.
Since my busybox-w32 ash patch has been accepted upstream, BusyBox's
shell is now quite adequate and capable, so there's little reason to
consider a replacement shell at this point.
The windres --preprocessor command changed behavior in this release,
likely due to a bug, and it no longer word splits its argument (Binutils
commit 21c33bcb), though this was a misfeature to begin with. Vim uses
this option and so its build broke. Fortunately it doesn't actually need
to use --preprocessor sine the default is already fine, so it's been
removed.
This issue should be revisited on the next Binutils release.
About half the time I run fresh builds, at least one of the tarballs is
not downloaded correctly. The mirror is down, it has a bad certificate,
or it's serving HTTP 404 responses for files that should exist.
This isn't ideal since it undermines the shell to support Windows' awful
command line semantics. However, it *is* pragmatic and that's one of the
major goals of the project.
Fixes#3.
Some of the size optimizations from the first stage bootstrap leak into
the second stage itself. This means the distribution can be made slighly
smaller by optimizing for size in certain parts of the first stage.
As discussed in the README, this makes it easier for users to comply
with the Mingw-w64 licenses, and it's probably necessary for the
distribution itself anyway.
The script now "copies" the tutor file to the temporary directory with a
"unique" file name, so the tutorial now lines up with the buffer state.
This one-liner already works far better than the official vimtutor.bat
ever did! It's only missing language selection, but this doesn't matter
since w64devkit discards internationalization anyway.
It would be interesting for w64devkit to be part of some sort of intro
to programming that targets Windows users who haven't yet graduated to a
more appropriate operating system. These people would need vimtutor in
order to make use of Vim.
Unfortunately the Vim developers decided that vimtutor should be a
complicated, fragile script rather than a feature built into Vim. After
a couple hours of trying, I still can't get the original vimtutor.bat
working reliably. So instead I included a one liner script that does 95%
of the job reliably. Unfortunately it's not an exact match with the
instructions, but this is the best I've found so far.
pthreads already works fine in C, so I assumed C++ threads worked.
However, it requires choosing POSIX, not Win32, threads during GCC's
configuration, which, in retrospect, makes sense.
I would have used this in the first place, but the official Mingw-w64
website still supplies the wrong download link six months after v7.0.0
was released.
This upgrade is required to work around a bug in Mingw-w64 7.0.0:
https://github.com/vim/vim/issues/4913
I would have used this version of Vim initially, but the Vim website
still lists 8.1 as the latest version five months after the release of
8.2.
Unfortunately Universal Ctags has never made an official release, and
the maintainer doesn't seem to be interesting in ever making one. So
there's no official stable tarball of the source code. GitHub's
automatically generated tarballs are not stable, so we can't use them.
So the best we can do is use a stable snapshot from a Linux
distribution, in this case Debian. This means we're limited to whatever
version Debian packages.
