Being able to know whether UTF-8 is supported or not is a valid
concern. How about adding this information to what "make --version"
I think this is a great idea, despite the fact that I expect most
build environments to actually have a resource compiler (either
windres or the msvc one) and therefore build with UTF-8.
It certainly doesn't hurt to have this information output by Make
itself - I can only see this being useful, even if the answer is
UTF-8 most of the time.
One comment about having it as part of --version is that it probably
won't be easy to parse the used encoding out of the --version
output, say, if a script wants to query for the encoding and pass a
UTF-8 Makefile conditional on Make actually supporting UTF-8.
Whether we want to care for this scenario or not is a different
If we decide to do this, it should simply be a call to the Windows
GetACP() function - it will return 65001 if Make has been built
with the UTF-8 manifest, or the identifier of the legacy system
Actually, it will return 65001 (the UTF-8 identifier) in a couple other
scenarios, even if Make hadn't been built with the manifest:
1) The user embedded the manifest manually using mt.exe
This is officially documented and can very well happen.
2) The user has switched Windows to use UTF-8 as the
active code page globally, for the entire OS. This is possible
to do with a checkbox that is marked as "beta" by MS.
So having Make return the output of GetACP would be useful
because it would capture all these scenarios, including it
having been built with the manifest of course.
This is an example from ninja doing the same thing:
They did it by adding a new flag, so not part of --version. I like
putting it in --version better because this does sound like the type
of information one would expect to see there, the only problem
being that it may not be easy to parse, unless we add it in a standard
easy-to-parse format, like in a line of its own as:
But it isn't "full UTF-8", as we have established during the
discussions. MS-Windows is not yet ready for that, even in its latest
Yes, well, I guess what I really meant was "to the extent that Make
itself can affect things". We can't do anything about Windows
limitations anyway. I think there should be no problems at all
if Make is linked against UCRT, and I hope that we won't hit many
functions in MSVCRT that are not UTF-8-aware, but we couldn't
do anything about these anyway.
> 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.
I'm of the opposite opinion.
Sure, it shouldn't be hard to change build_w32.bat to make it optional.
There is no precedent of such behavior in that batch file, as far as I can
tell, so I'd have to come up with something like:
compile resource file
just skip resource file with no error, and don't try to link it
Then this is a non-issue: the error will not happen except in some
situations we cannot imagine.
That's what I think, but I could be wrong since I really can't imagine
all the build environments people might be using, and, as I learned
from this thread, there are quite a few ways to build so it's hard to
anticipate for every possible scenario.
Maybe it is best to just make compilation of the resource file optional,
but, very importantly, with the addition of your suggestion about printing
the encoding used in --version. That way, everyone will manage to
build as they currently do with no surprises about this, and they will
also be able to query Make any time for its encoding.
I'd like to avoid annoying users with requests to install something
they did well without previously. Some would consider this a
Makes sense, see above response.