Re: [PATCH] Use UTF-8 active code page for Windows host.
Thank you both for your input. I think you should move the assignment of UTF8OBJ out of the if- statement here, and only put the update of make_LDADD into the if- statement. That should be sufficient to have make ignore that target, if there's no WINDRES available. I'll make that change, thanks. I will say that I think this is at the very edge of what we can accept without copyright assignment. If this change gets larger, or if you want to contribute more in the future, we'll need to have paperwork. I think this change will get larger, because of Eli's suggestion: 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.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. 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? If that change is made, which sounds like it will, this will push us over the edge it seems, thereby requiring paperwork. 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. If we all agree on that list, I can make these changes when I find some time and post the updated patch.Once we have the patch approved, we can start on the paperwork before actually committing anything. Does that sound reasonable? Thanks, Costas On Sat, 8 Apr 2023 at 05:32, Paul Smith wrote: > On Fri, 2023-04-07 at 08:29 -0400, Paul Smith wrote: > > > Also, I'm still waiting for Paul to approve the changes to Posix > > > configury part of your patch. > > > > Sorry I will make every effort to get to it today. > > The configure part looks OK to me. This change to Makefile.am seems > not quite correct to me however: > > @@ -90,6 +92,14 @@ else >make_SOURCES += src/posixos.c > endif > > +if HAVE_WINDRES > + UTF8OBJ = src/w32/utf8.$(OBJEXT) > + make_LDADD += $(UTF8OBJ) > +endif > + > +$(UTF8OBJ) : $(w32_utf8_SRCS) > + $(WINDRES) $< -o $@ > + > if USE_CUSTOMS >make_SOURCES += src/remote-cstms.c > else > > Here if HAVE_WINDRES is not set, then UTF8OBJ is empty, and you create > a recipe with an empty target. Now, this works in GNU Make (and is > ignored) but some other versions of make may not like it. > > I think you should move the assignment of UTF8OBJ out of the if- > statement here, and only put the update of make_LDADD into the if- > statement. That should be sufficient to have make ignore that target, > if there's no WINDRES available. > > After that if Eli is happy with it he can push it to Git. > > I will say that I think this is at the very edge of what we can accept > without copyright assignment. If this change gets larger, or if you > want to contribute more in the future, we'll need to have paperwork. > > Thanks for your contribution to GNU Make! >
Re: [PATCH] Use UTF-8 active code page for Windows host.
> From: Costas Argyris > Date: Tue, 11 Apr 2023 12:01:20 +0100 > Cc: Eli Zaretskii , 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.
Re: [PATCH] Use UTF-8 active code page for Windows host.
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 wrote: > > From: Costas Argyris > > Date: Tue, 11 Apr 2023 12:01:20 +0100 > > Cc: Eli Zaretskii , 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. >
Re: [PATCH] Use UTF-8 active code page for Windows host.
> From: Costas Argyris > Date: Tue, 11 Apr 2023 14:42:30 +0100 > Cc: bug-make@gnu.org, Paul Smith > >> 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. AFAIK, GetACP can never return UTF-8, except if the program was compiled with those resources. > 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. Yes, verifying this would be good, thanks.
Re: [PATCH] Use UTF-8 active code page for Windows host.
AFAIK, GetACP can never return UTF-8, except if the program was compiled with those resources. In the scenario I am describing, Make was compiled with the resource, so GetACP should return UTF-8 on the one hand.On the other hand though, since Make is running in Windows version < 1903, it shouldn't return UTF-8 because this functionality is not supported in that version. But yes, I will make sure to check this in practice. On Tue, 11 Apr 2023 at 14:46, Eli Zaretskii wrote: > > From: Costas Argyris > > Date: Tue, 11 Apr 2023 14:42:30 +0100 > > Cc: bug-make@gnu.org, Paul Smith > > > >> 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. > > AFAIK, GetACP can never return UTF-8, except if the program was > compiled with those resources. > > > 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. > > Yes, verifying this would be good, thanks. >
Re: [PATCH] Use UTF-8 active code page for Windows host.
> From: Costas Argyris > Date: Tue, 11 Apr 2023 14:50:53 +0100 > Cc: bug-make@gnu.org, psm...@gnu.org > > > AFAIK, GetACP can never return UTF-8, except if the program was > > compiled with those resources. > > In the scenario I am describing, Make was compiled with the resource, > so GetACP should return UTF-8 on the one hand.On the other hand > though, since Make is running in Windows version < 1903, it shouldn't > return UTF-8 because this functionality is not supported in that version. That is what will happen, AFAIK.
