Re: [PATCH] Use UTF-8 active code page for Windows host.

[Costas Argyris]

I don't think this is needed: if GetACP returns the UTF-8 codepage, it
must be that UTF-8 is supported.  I'm not aware of any way of
affecting GetACP other than by a manifest such as this one (or perhaps
making UTF-8 a system-wide default, which is fine by us).

This is the scenario I am concerned about:

Assume Make was built with UTF-8 support, and downloaded by a

user running Windows < 1903.    I am not sure what GetACP would

return in this case - If it returns the legacy code page, despite the

fact that the UTF-8 manifest is embedded in Make, then we are good.

But if GetACP returns UTF-8, because of the manifest that was

embedded at build time, this will be confusing because --version will

say UTF-8 but Make will actually work in the legacy encoding because

of the < 1903 Windows version.

I haven't tested this though, so it might not even be a real issue, just

noting it down to check it later when I have the implementation.

If Paul is also OK with forgetting about Basic.mk for UTF-8 support,

sounds like we have a plan.

On Tue, 11 Apr 2023 at 13:29, Eli Zaretskii <eliz@gnu.org> wrote:

> From: Costas Argyris <costas.argyris@gmail.com>
> Date: Tue, 11 Apr 2023 12:01:20 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, bug-make@gnu.org
>
> > Being able to know whether UTF-8 is supported or not is a valid
> > concern.  How about adding this information to what "make --version"
> > shows?
>
> I agreed with that suggestion and proposed a plan, but didn't receive
> final confirmation on it.
>
> As far as I can tell, the only scenario where GNU Make is not built
> with UTF-8 is if it gets built with tcc, which doesn't have a resource
> compiler.    Both gcc and msvc have resource compilers (gcc through
> binutils which gcc depends on anyway).    But since tcc is a supported
> compiler as well, and we don't want to break it for the sake of UTF-8,
> then we must provide users with a way to tell if Make was built with
> UTF-8 support or not.
>
> I think outputting this info can be as simple as adding a call to GetACP
> in some appropriate place in the source code.

Yes, I think so.

> Note that this is going
> to be a windows-specific call.    If you can point me at some candidate
> locations in the source code for adding that call, it would greatly speed
> things up.    Otherwise I would just try to find where the --version output
> is computed and try and add a windows-specific branch somewhere
> there.

I think Windows-specific code in print_version (in main.c) should be
fine, but perhaps just call a function there, and the function itself
should be in a Windows-specific file, like w32/w32os.c.

> There is one more complication about this: As we have stated before,
> this work only has a positive effect on Windows Version 1903 or later.
> Earlier versions will still work, but won't get UTF-8.    So would it make
> any sense if we reported UTF-8 in --version for versions of Windows
> earlier than 1903?    Perhaps the check should include both Windows
> version and GetACP - thoughts?

I don't think this is needed: if GetACP returns the UTF-8 codepage, it
must be that UTF-8 is supported.  I'm not aware of any way of
affecting GetACP other than by a manifest such as this one (or perhaps
making UTF-8 a system-wide default, which is fine by us).

> To summarize, I think the list of things do be done is:
>
> 1) Make build optional with respect to UTF-8:    If windres is available,
> use it, if not, just build without UTF-8 support (current behavior).
> 2) Implement Paul's suggestion above to avoid having an empty target
> if HAVE_WINDRES is not set.
> 3) Add active code page used in "make --version" output, for Windows.
> Potentially also check Windows version.
> 4) Can we officially forget about bringing the UTF-8 changes to Basic.mk?
> As I have said before, I haven't managed to build using these Makefiles.
> Actually, having the code page output by --version would greatly help with
> this as well - if one built GNU Make using Basic.mk, they wouldn't get
> UTF-8 support but this would still be readable in --version so no surprises.

I agree with the list.  As for Basic.mk, we can forget about it from
my POV.  Paul should make the call, but from my POV that file was
unmaintained and therefore unsupported.

Thanks.