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 <e...@gnu.org> wrote: > > From: Costas Argyris <costas.argy...@gmail.com> > > Date: Tue, 11 Apr 2023 12:01:20 +0100 > > Cc: Eli Zaretskii <e...@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. >
