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

Costas Argyris <[email protected]> Sat, 18 Mar 2023 16:57:35 +0000
Newsgroups gmane.comp.gnu.make.windows
Message-ID <CAHyHGCn=JJ_nZEcLfJg1dUU+6RB09zEEeKb5jG4XuQEvDiMjOA@mail.gmail.com>
--000000000000dc25e805f72f97cc
Content-Type: multipart/alternative; boundary="000000000000dc25e505f72f97ca"

--000000000000dc25e505f72f97ca
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I just realized that there is a Windows-specific mailing list, so
forwarding here.

---------- Forwarded message ---------
From: Costas Argyris <[email protected]>
Date: Sat, 18 Mar 2023 at 16:37
Subject: [PATCH] Use UTF-8 active code page for Windows host.
To: <[email protected]>


Hi

This is a proposed patch to enable UTF-8 support in GNU Make running on
Windows host.

Today, the make process on Windows is using the legacy system code page
because of the "A" functions called in the source code.    This means that
any UTF-8 input to make on Windows will break.    A few examples follow:

######################
C:\Users\cargyris\temp>cat utf8Makefile.mk
hello :
        @echo =EF=B9=8F
        @echo =E2=9D=8E
C:\Users\cargyris\temp>mingw32-make -f utf8Makefile.mk
=C3=AF=C2=B9
=C3=A2=C5=BD

C:\Users\cargyris\temp>mingw32-make -f =E2=9D=8E\utf8Makefile.mk
mingw32-make: ?\utf8Makefile.mk: Invalid argument
mingw32-make: *** No rule to make target '?\utf8Makefile.mk'.  Stop.

C:\Users\cargyris\temp>cd =E2=9D=8E

C:\Users\cargyris\temp\=E2=9D=8E>mingw32-make -f utf8Makefile.mk
mingw32-make: *** INTERNAL: readdir: Invalid argument.  Stop.

C:\Users\cargyris\temp\=E2=9D=8E>mingw32-make -f =E2=9D=8E\utf8Makefile.mk
mingw32-make: ?\utf8Makefile.mk: Invalid argument
mingw32-make: *** INTERNAL: readdir: Invalid argument.  Stop.
######################

Hopefully the Unicode symbols are showing correctly in the email.    I used
these:

https://www.compart.com/en/unicode/U+FE4F
https://www.compart.com/en/unicode/U+274E

The attached patch incorporates the UTF-8 manifest into the build process
of GNU Make when hosted on Windows, and forces the built executable to use
UTF-8 as its active code page, solving all problems shown above because
this has a global effect in the process.    All existing "A" calls use the
UTF-8 code page now instead of the legacy one.    This is the relevant
Microsoft doc:

https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-=
code-page

With the patch, after building make, the above cases now work on Windows:

######################
C:\Users\cargyris\temp>cat utf8Makefile.mk
hello :
        @echo =EF=B9=8F
        @echo =E2=9D=8E
C:\Users\cargyris\temp>make -f utf8Makefile.mk
=EF=B9=8F
=E2=9D=8E

C:\Users\cargyris\temp>make -f =E2=9D=8E\utf8Makefile.mk
=EF=B9=8F
=E2=9D=8E

C:\Users\cargyris\temp>cd =E2=9D=8E

C:\Users\cargyris\temp\=E2=9D=8E>make -f utf8Makefile.mk
=EF=B9=8F
=E2=9D=8E

C:\Users\cargyris\temp\=E2=9D=8E>make -f =E2=9D=8E\utf8Makefile.mk
=EF=B9=8F
=E2=9D=8E
######################

This change might also fix other existing issues on Windows having to do
with filenames and paths, but I can't point at something particular right
now.

Would a patch like that be considered?

Thanks,
Costas

--000000000000dc25e505f72f97ca
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I just realized that there is a Windows-specific mailing l=
ist, so forwarding here.<br><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">---------- Forwarded message ---------<br>From: <stro=
ng class=3D"gmail_sendername" dir=3D"auto">Costas Argyris</strong> <span di=
r=3D"auto">&lt;<a href=3D"mailto:[email protected]">costas.argyris@g=
mail.com</a>&gt;</span><br>Date: Sat, 18 Mar 2023 at 16:37<br>Subject: [PAT=
CH] Use UTF-8 active code page for Windows host.<br>To:  &lt;<a href=3D"mai=
lto:[email protected]">[email protected]</a>&gt;<br></div><br><br><div dir=3D=
"ltr">Hi<div><br></div><div>This is a proposed patch to enable UTF-8 suppor=
t in GNU Make running on Windows host.</div><div><br></div><div>Today, the =
make process on Windows is using the legacy system code page because of the=
 &quot;A&quot; functions called in the source code.=C2=A0 =C2=A0 This means=
 that any UTF-8 input to make on Windows will break.=C2=A0 =C2=A0 A few exa=
mples follow:</div><div><br></div><div>######################</div><div>C:\=
Users\cargyris\temp&gt;cat utf8Makefile.mk<br>hello :<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 @echo =EF=B9=8F<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 @echo =E2=9D=8E<b=
r>C:\Users\cargyris\temp&gt;mingw32-make -f utf8Makefile.mk<br>=C3=AF=C2=B9=
<br>=C3=A2=C5=BD<br><br>C:\Users\cargyris\temp&gt;mingw32-make -f =E2=9D=8E=
\utf8Makefile.mk<br>mingw32-make: ?\utf8Makefile.mk: Invalid argument<br>mi=
ngw32-make: *** No rule to make target &#39;?\utf8Makefile.mk&#39;.=C2=A0 S=
top.<br><br>C:\Users\cargyris\temp&gt;cd =E2=9D=8E<br><br>C:\Users\cargyris=
\temp\=E2=9D=8E&gt;mingw32-make -f utf8Makefile.mk<br>mingw32-make: *** INT=
ERNAL: readdir: Invalid argument.=C2=A0 Stop.<br></div><div><br></div><div>=
C:\Users\cargyris\temp\=E2=9D=8E&gt;mingw32-make -f =E2=9D=8E\utf8Makefile.=
mk<br>mingw32-make: ?\utf8Makefile.mk: Invalid argument<br>mingw32-make: **=
* INTERNAL: readdir: Invalid argument.=C2=A0 Stop.<br></div><div>##########=
############<br></div><div><br></div><div>Hopefully the Unicode symbols are=
 showing correctly in the email.=C2=A0 =C2=A0 I used these:</div><div><br><=
/div><div><a href=3D"https://www.compart.com/en/unicode/U+FE4F" target=3D"_=
blank">https://www.compart.com/en/unicode/U+FE4F</a><br></div><div><a href=
=3D"https://www.compart.com/en/unicode/U+274E" target=3D"_blank">https://ww=
w.compart.com/en/unicode/U+274E</a><br></div><div><br></div><div>The attach=
ed patch incorporates the UTF-8 manifest into the build process of GNU Make=
 when hosted on Windows, and forces the built=C2=A0executable to use UTF-8 =
as its active code page, solving all problems shown above because this has =
a global effect in the process.=C2=A0 =C2=A0 All existing &quot;A&quot; cal=
ls use the UTF-8 code page now instead of the legacy one.=C2=A0 =C2=A0 This=
 is the relevant Microsoft doc:</div><div><br></div><div><a href=3D"https:/=
/learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-pa=
ge" target=3D"_blank">https://learn.microsoft.com/en-us/windows/apps/design=
/globalizing/use-utf8-code-page</a><br></div><div><br></div><div>With the p=
atch, after building make, the above cases now work on Windows:</div><div><=
br></div><div>######################<br></div><div>C:\Users\cargyris\temp&g=
t;cat utf8Makefile.mk<br>hello :<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 @echo =EF=
=B9=8F<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 @echo =E2=9D=8E<br>C:\Users\cargyris\=
temp&gt;make -f utf8Makefile.mk<br>=EF=B9=8F<br>=E2=9D=8E<br><br>C:\Users\c=
argyris\temp&gt;make -f =E2=9D=8E\utf8Makefile.mk<br>=EF=B9=8F<br>=E2=9D=8E=
<br><br>C:\Users\cargyris\temp&gt;cd =E2=9D=8E<br><br>C:\Users\cargyris\tem=
p\=E2=9D=8E&gt;make -f utf8Makefile.mk<br>=EF=B9=8F<br>=E2=9D=8E<br></div><=
div><br></div><div>C:\Users\cargyris\temp\=E2=9D=8E&gt;make -f =E2=9D=8E\ut=
f8Makefile.mk<br>=EF=B9=8F<br>=E2=9D=8E<br></div><div>#####################=
#<br></div><div><br></div><div>This change might also fix other existing is=
sues on Windows having to do with filenames and paths, but I can&#39;t poin=
t at something particular right now.</div><div><br></div><div>Would a patch=
 like that be considered?</div><div><br></div><div>Thanks,</div><div>Costas=
</div></div>
</div></div>

--000000000000dc25e505f72f97ca--

--000000000000dc25e805f72f97cc
Content-Type: application/x-patch; 
	name="0001-Use-UTF-8-active-code-page-for-Windows-host.patch"
Content-Disposition: attachment; 
	filename="0001-Use-UTF-8-active-code-page-for-Windows-host.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_lfe40b400>
X-Attachment-Id: f_lfe40b400

RnJvbSBmMDQyZDRiODIxMTE2MjRkZmU4NGJiODU3NThjOWI2MWM3NmVjZTVmIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBDb3N0YXMgQXJneXJpcyA8Y29zdGFzLmFyZ3lyaXNAZ21haWwu
Y29tPgpEYXRlOiBTYXQsIDE4IE1hciAyMDIzIDE0OjEzOjIxICswMDAwClN1YmplY3Q6IFtQQVRD
SF0gVXNlIFVURi04IGFjdGl2ZSBjb2RlIHBhZ2UgZm9yIFdpbmRvd3MgaG9zdC4KClRoaXMgYWxs
b3dzIHRoZSBtYWtlIHByb2Nlc3Mgb24gV2luZG93cyB0byB3b3JrIGluIFVURi04IGluIG11bHRp
cGxlIGxldmVsczoKCjEpIEFjY2VwdCBhIE1ha2VmaWxlIHRoYXQgaXMgZW5jb2RlZCBpbiBVVEYt
OCAod2l0aCBvciB3aXRob3V0IHRoZSBCT00sIHNpbmNlIGl0IGFscmVhZHkgZ2V0cyBpZ25vcmVk
IGFueXdheSkuCjIpIEFjY2VwdCBhIFVURi04IHBhdGggKGlucHV0IC1mIGFyZ3VtZW50KSB0byBh
IE1ha2VmaWxlICh0aGF0IGNvdWxkIGl0c2VsZiBiZSBlbmNvZGVkIGluIFVURi04LCBhcyBwZXIg
IzEpLgozKSBMYXVuY2ggbWFrZSBmcm9tIGEgY3VycmVudCBkaXJlY3RvcnkgdGhhdCBoYXMgVVRG
LTggY2hhcmFjdGVycy4KCmFuZCBhbnkgY29tYmluYXRpb24gb2YgdGhlIGFib3ZlLCBzaW5jZSB0
aGUgZW50aXJlIG1ha2UgcHJvY2VzcyB3aWxsIHVzZSBVVEYtOC4KClRoaXMgaXMgYWxyZWFkeSB0
aGUgY2FzZSBpbiBMaW51eC1iYXNlZCBzeXN0ZW1zLCBidXQgb24gV2luZG93cyB0aGlzIGNoYW5n
ZSBpcyByZXF1aXJlZCBpbiBvcmRlciB0byBzdXBwb3J0IFVuaWNvZGUgYmVjYXVzZSB0aGUgIkEi
IEFQSXMgY3VycmVudGx5IHVzZWQgd2lsbCBhc3N1bWUgdGhlIGxlZ2FjeSBzeXN0ZW0gY29kZSBw
YWdlLCBkZXN0cm95aW5nIGFueSBVVEYtOCBpbnB1dC4KClRoaXMgY2hhbmdlIHNldHMgdGhlIGNv
ZGUgcGFnZSB0byBiZSB1c2VkIGJ5IHRoZSAiQSIgQVBJcyB0byB0aGUgVVRGLTggY29kZSBwYWdl
LCB0aGVyZWJ5IGVsaW1pbmF0aW5nIHRoZSBuZWVkIHRvIHVwZGF0ZSBhbGwgY2FsbHMgb2YgIkEi
IGZ1bmN0aW9ucyB0byAiVyIgZnVuY3Rpb25zIHRvIHN1cHBvcnQgVW5pY29kZS4KClRoYXQgaXMs
IHRoZSBzb3VyY2UgY29kZSBjYW4gc3RheSB0aGUgc2FtZSB3aXRoIHRoZSAiQSIgZnVuY3Rpb25z
LCBidXQgaW5zdGVhZCBvZiB0aGVtIHVzaW5nIHRoZSBsZWdhY3kgY29kZSBwYWdlIHRoZXkgd2ls
bCBiZSB1c2luZyB0aGUgVVRGLTggY29kZSBwYWdlLgotLS0KIE1ha2VmaWxlLmFtICAgICAgICAg
ICB8IDEwICsrKysrKysrKysKIGNvbmZpZ3VyZS5hYyAgICAgICAgICB8ICA1ICsrKysrCiBzcmMv
dzMyL3V0ZjgubWFuaWZlc3QgfCAgOCArKysrKysrKwogc3JjL3czMi91dGY4LnJjICAgICAgIHwg
IDMgKysrCiA0IGZpbGVzIGNoYW5nZWQsIDI2IGluc2VydGlvbnMoKykKIGNyZWF0ZSBtb2RlIDEw
MDY0NCBzcmMvdzMyL3V0ZjgubWFuaWZlc3QKIGNyZWF0ZSBtb2RlIDEwMDY0NCBzcmMvdzMyL3V0
ZjgucmMKCmRpZmYgLS1naXQgYS9NYWtlZmlsZS5hbSBiL01ha2VmaWxlLmFtCmluZGV4IGMyOWMy
MzUuLjYwYTRlNWIgMTAwNjQ0Ci0tLSBhL01ha2VmaWxlLmFtCisrKyBiL01ha2VmaWxlLmFtCkBA
IC00Niw2ICs0Niw4IEBAIHczMl9TUkNTID0Jc3JjL3czMi9wYXRoc3R1ZmYuYyBzcmMvdzMyL3cz
Mm9zLmMgc3JjL3czMi9jb21wYXQvZGlyZW50LmMgXAogCQlzcmMvdzMyL3N1YnByb2MvbWlzYy5j
IHNyYy93MzIvc3VicHJvYy9wcm9jLmggXAogCQlzcmMvdzMyL3N1YnByb2Mvc3ViX3Byb2MuYyBz
cmMvdzMyL3N1YnByb2MvdzMyZXJyLmMKIAordzMyX3V0ZjhfU1JDUyA9IHNyYy93MzIvdXRmOC5y
YyBzcmMvdzMyL3V0ZjgubWFuaWZlc3QKKwogdm1zX1NSQ1MgPQlzcmMvdm1zX2V4aXQuYyBzcmMv
dm1zX2V4cG9ydF9zeW1ib2wuYyBzcmMvdm1zX3Byb2duYW1lLmMgXAogCQlzcmMvdm1zZGlyLmgg
c3JjL3Ztc2Z1bmN0aW9ucy5jIHNyYy92bXNpZnkuYwogCkBAIC05MCw2ICs5MiwxNCBAQCBlbHNl
CiAgIG1ha2VfU09VUkNFUyArPSBzcmMvcG9zaXhvcy5jCiBlbmRpZgogCitpZiBIQVZFX1dJTkRS
RVMKKyAgVVRGOE9CSiAgICAgPSBzcmMvdzMyL3V0ZjguJChPQkpFWFQpCisgIG1ha2VfTERBREQg
Kz0gJChVVEY4T0JKKQorZW5kaWYKKworJChVVEY4T0JKKSA6ICQodzMyX3V0ZjhfU1JDUykKKwkk
KFdJTkRSRVMpICQ8IC1vICRACisKIGlmIFVTRV9DVVNUT01TCiAgIG1ha2VfU09VUkNFUyArPSBz
cmMvcmVtb3RlLWNzdG1zLmMKIGVsc2UKZGlmZiAtLWdpdCBhL2NvbmZpZ3VyZS5hYyBiL2NvbmZp
Z3VyZS5hYwppbmRleCBjZDc4NTc1Li44Y2JmOTg2IDEwMDY0NAotLS0gYS9jb25maWd1cmUuYWMK
KysrIGIvY29uZmlndXJlLmFjCkBAIC00NDQsNiArNDQ0LDcgQEAgQUNfU1VCU1QoW01BS0VfSE9T
VF0pCiAKIHczMl90YXJnZXRfZW52PW5vCiBBTV9DT05ESVRJT05BTChbV0lORE9XU0VOVl0sIFtm
YWxzZV0pCitBTV9DT05ESVRJT05BTChbSEFWRV9XSU5EUkVTXSwgW2ZhbHNlXSkKIAogQVNfQ0FT
RShbJGhvc3RdLAogICBbKi0qLW1pbmd3MzJdLApAQCAtNDUxLDYgKzQ1MiwxMCBAQCBBU19DQVNF
KFskaG9zdF0sCiAgICAgdzMyX3RhcmdldF9lbnY9eWVzCiAgICAgQUNfREVGSU5FKFtXSU5ET1dT
MzJdLCBbMV0sIFtCdWlsZCBmb3IgdGhlIFdJTkRPV1MzMiBBUEkuXSkKICAgICBBQ19ERUZJTkUo
W0hBVkVfRE9TX1BBVEhTXSwgWzFdLCBbU3VwcG9ydCBET1Mtc3R5bGUgcGF0aG5hbWVzLl0pCisg
ICAgIyBXaW5kb3dzIGhvc3QgdG9vbHMuCisgICAgIyBJZiB3aW5kcmVzIGlzIGF2YWlsYWJsZSwg
bWFrZSB3aWxsIHVzZSBVVEYtOC4KKyAgICBBQ19DSEVDS19UT09MKFtXSU5EUkVTXSwgW3dpbmRy
ZXNdLCBbOl0pCisgICAgQU1fQ09ORElUSU9OQUwoW0hBVkVfV0lORFJFU10sIFt0ZXN0ICIkV0lO
RFJFUyIgIT0gJzonXSkKICAgXSkKIAogQUNfREVGSU5FX1VOUVVPVEVEKFtQQVRIX1NFUEFSQVRP
Ul9DSEFSXSxbJyRQQVRIX1NFUEFSQVRPUiddLApkaWZmIC0tZ2l0IGEvc3JjL3czMi91dGY4Lm1h
bmlmZXN0IGIvc3JjL3czMi91dGY4Lm1hbmlmZXN0Cm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4
IDAwMDAwMDAuLmRhYjkyOWUKLS0tIC9kZXYvbnVsbAorKysgYi9zcmMvdzMyL3V0ZjgubWFuaWZl
c3QKQEAgLTAsMCArMSw4IEBACis8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCIg
c3RhbmRhbG9uZT0ieWVzIj8+Cis8YXNzZW1ibHkgbWFuaWZlc3RWZXJzaW9uPSIxLjAiIHhtbG5z
PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOmFzbS52MSI+CisgIDxhcHBsaWNhdGlvbj4KKyAg
ICA8d2luZG93c1NldHRpbmdzPgorICAgICAgPGFjdGl2ZUNvZGVQYWdlIHhtbG5zPSJodHRwOi8v
c2NoZW1hcy5taWNyb3NvZnQuY29tL1NNSS8yMDE5L1dpbmRvd3NTZXR0aW5ncyI+VVRGLTg8L2Fj
dGl2ZUNvZGVQYWdlPgorICAgIDwvd2luZG93c1NldHRpbmdzPgorICA8L2FwcGxpY2F0aW9uPgor
PC9hc3NlbWJseT4KZGlmZiAtLWdpdCBhL3NyYy93MzIvdXRmOC5yYyBiL3NyYy93MzIvdXRmOC5y
YwpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi42MmJkYmRjCi0tLSAvZGV2L251
bGwKKysrIGIvc3JjL3czMi91dGY4LnJjCkBAIC0wLDAgKzEsMyBAQAorI2luY2x1ZGUgPHdpbnVz
ZXIuaD4KKworQ1JFQVRFUFJPQ0VTU19NQU5JRkVTVF9SRVNPVVJDRV9JRCBSVF9NQU5JRkVTVCAi
dXRmOC5tYW5pZmVzdCIKLS0gCjIuMzAuMgoK
--000000000000dc25e805f72f97cc--