Thanks for looking into this, and good to hear that you are feeling better!
I still can't get Basic.mk to work, so not much to say on that...
Should we fail here? Or should we build without UTF-8 support since we
don't have a resource compiler? I think that's what the configure
version does, right?
You are right, that was an inconsistency on my part, sorry about that.
It's true that the configure version is optional on this, whereas
build_w32.bat errors out.
I think the answer depends on what is going to be the policy regarding
Make on Windows and UTF-8. If we want to claim that Make on Windows
has gone UTF-8, matching fully the Unix-based platforms, then it has to
be an error if it can't be built as such. My personal opinion is that this
is the way forward, because it may be confusing if we end up in a
situation where some users have a UTF-8 version of Make and some
others don't. I think just go full UTF-8 like the other systems.
Of course, users on versions of Windows earlier than the target version
that supports this feature still won't get UTF-8, but that would be because
of their version of Windows, not because of the way Make was built.
That is, I am more inclined to make the configure version also error
out if windres was not found, than to make build_w32.bat optional.
This is mostly based on the fact that windres is part of binutils which is
pretty much ubiquitous because gcc itself relies on its tools (most
notably the assembler and linker). So if someone is building with
gcc, they will almost certainly already have windres. For building
with MSVC that's a non-issue because MSVC comes bundled with its
own resource compiler, so it is always going to be there.
So I think it is reasonable to expect that there is always going to be a
resource compiler available. Even if not, say, when building with tcc,
it is always possible to error out with a message saying to install binutils.
For this (and the GCC version) shouldn't we be testing for failure and
failing the build if it doesn't work?
This is done by the existing CompileDone subroutine. The code you
flagged and the GCC version right under it (and the TCC version for
that matter) calls CompileDone as their last command which is an
existing function that checks for the presence of the compiled object
file and errors out if it wasn't found.