[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Costas Argyris
Subject: Re: [PATCH] Use UTF-8 active code page for Windows host.
Date: Sat, 25 Mar 2023 23:12:46 +0000

Here is the new patch that includes the changes in build_w32.bat
required to build GNU Make with UTF-8 on Windows.

I have tested it with all 3 supported toolchains:

.\build_w32.bat          (uses MSVC)
.\build_w32.bat gcc
.\build_w32.bat tcc

with/without --debug and with/without --x86 for MSVC.

In all cases, it produces the expected UTF-8 Make executable.

gcc and tcc must find 'windres' from binutils to compile the
UTF-8 resource file into an object file.

I have also tested the Autotools approach (on Windows this
time, as the above, in contrast to the cross-compile I did
initially).    From an MSYS2 shell:

./bootstrap         (generates configure)
./configure         (generates Makefiles)
and we get a UTF-8 make.exe in the source dir.

I also gave the Basic.mk approach a shot and, despite my
best efforts, I couldn't get it to work with either toolchain.
There were just so many problems that it seems broken to
me, unless I wasn't using it correctly.    I followed the steps
in README.git -> Building From Git for Windows:


and then from README.W32 -> Building with (MinGW-)
GCC using GNU Make:

make -f Basic.mk
make -f Basic.mk TOOLCHAIN=gcc

but I was hitting some pretty fundamental errors like CC
not being defined, I manually defined it and then got tons
of link errors at which point I gave up.    If these are
functional and we want to support them with UTF-8, I
would need some help to get them working first.

For convenience, I have carried the previous changes
along so this patch has everything done so far, that is,
the changes in both the Autotools approach (tested
both in cross & native compile) and the build_w32.bat
approach.    Also, this time everything was done from
the current master branch of the Git repo (disabling the
maintainer mode when building allowed me to build
from Git by not turning warnings into errors).

On Sat, 25 Mar 2023 at 13:36, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Costas Argyris <costas.argyris@gmail.com>
> Date: Sat, 25 Mar 2023 13:19:00 +0000
> Cc: psmith@gnu.org, bug-make@gnu.org
> > Also, I'd name the files slightly differently, something like
> > w32-utf8.*, to make their relation to Windows more evident.
> Note that in the patch, these files are put under the w32 dir:
> src/w32/utf8.manifest
> src/w32/utf8.rc
> so their relation to Windows is already showing from that.

I'll leave that to Paul.

> 1) In build_w32.bat, there are 3 compilers supported:
> MSVC, gcc and tcc (Tiny C Compiler).    I can see the changes
> working for MSVC and gcc, but what about tcc?
> AFAICT, it has no resource compiler to compile the .rc file
> to an object file.    It can link against the object file though,
> assuming that it was produced by windres in the first place:
> https://github.com/TinyCC/tinycc/blob/mob/win32/tcc-win32.txt#L92
> But if one has tcc on its own and no windres, it doesn't
> seem possible to do it, so we need to decide if we are
> still going to build but without UTF-8 support, or error
> out, or try to find windres for compiling the .rc file and
> still use tcc for the rest (kind of a mixed approach).

Either the TCC build will not support this feature, or installing the
manifest (at least in some cases) is not such a bad idea after all.

> 2) From README.W32, there is another way to build
> Basic.mk
> which sources mk/Windows32.mk when building for Windows.
> mk/Windows32.mk has a TOOLCHAIN variable that can be
> either "msvc" or "gcc" (no tcc option here).
> Should mk/Windows32.mk also be updated for UTF-8 for
> both toolchains?

I don't know what is the status of these *.mk files and whether we
want to keep supporting them.  I have never used them.  Paul?

Attachment: 0001-Use-UTF-8-active-code-page-when-building-for-Windows.patch
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]