You can submit diffs against the last released version here as well.
In that case, I am simply re-attaching the patch I originally sent in
this thread, because that was already developed and built on 4.4.1
tarball which is still the latest AFAICT.
Just reminding that these changes are in Makefile.am and configure.ac
so you would have to build using that approach to actually get a
UTF-8 Make on Windows host.
The other two files of the patch, utf8.manifest and utf8.rc will be
useful for the build_w32.bat approach as well because they will
be reused by it (I don't see a reason why not).
I'm not aware of it, but then I don't cross-build Make, and rarely
build it from Git anyway.
I think it's more of a 'build from Git' problem than a cross-compile
problem.
There is a maintMakefile in the root which only exists in the Git repository
and not in the tarball:
https://git.savannah.gnu.org/cgit/make.git/tree/maintMakefile
On line 32 it sets -Werror so I think that's what I am facing.
In that case, as I said, my patch was already from the 4.4.1 tarball
so it should be OK.
On Tue, 21 Mar 2023 at 13:32, Eli Zaretskii <e...@gnu.org> wrote:
> > From: Costas Argyris <costas.argy...@gmail.com>
> > Date: Tue, 21 Mar 2023 12:52:54 +0000
> > Cc: bug-make@gnu.org, Paul Smith <psm...@gnu.org>
> >
> > > If so, could you please post it again, rebased on the current Git
> > > master?
> >
> > There is an issue here: I noticed that when I was trying to build
> > (cross-compile) Make for Windows using a gcc + mingw-w64
> > cross-compiler (using Autotools, not build_w32.bat), there was a
> > big difference depending on whether I was using the Make source
> > code from git or the tarball.
> >
> > When trying from git, which was my first attempt, I was getting
> > compilation warnings which were turning themselves into errors,
> > so I never managed to build.
> >
> > When I used the sources extracted from the tarball though, this
> > simply wasn't the case so I was able to cross-compile just fine.
> >
> > Then the problem was how to track my changes, since I don't
> > have git any more. What I did just to get a patch posted was
> > to simply 'git init' a repository in the extracted sources just so
> > I could use 'git diff' and so forth. That way, I created the patch
> > I originally posted.
> >
> > The problem now is that in order to rebase on the current Git
> > master, I'd have to use Git, so I'll fall back to the original problem
> > of not being able to build because of the warnings being treated
> > as errors.
>
> If this gives you so much trouble, just post the diffs against the
> last release's tarball, and I will take it from there.
>
> > Is this a known issue?
>
> I'm not aware of it, but then I don't cross-build Make, and rarely
> build it from Git anyway.
>
> > Or is it just that not many people are
> > cross-compiling for Windows using gcc and autotools (i.e. not
> > using build_w32.bat)?
>
> Not sure. I think the MSYS2 folks do use the configury, but they use
> it on Windows, not on GNU/Linux (i.e., they build natively, not by
> cross-compiling).
>
> > That being said, I haven't tried to build the Git source code
> > using build_w32.bat, so for all I know maybe that doesn't
> > lead to the warnings/errors I got with autotools (mostly because
> > that would be a native compile, as opposed to the cross-compile
> > I am doing with autotools).
>
> You can submit diffs against the last released version here as well.
>
> > > And would you please consider working on changing build_w32.bat as
> > > well?
> >
> > Absolutely, I haven't forgotten about this. I haven't looked into
> > that file at all though, so I don't know how it configures its Makefiles,
> > how it detects the toolchain etc, so I may need some help to speed
> > things up. But definitely planning to do so in the coming days, or
> > weekend at worst.
>
> Thanks. Please don't hesitate to ask questions.
>
From f042d4b82111624dfe84bb85758c9b61c76ece5f Mon Sep 17 00:00:00 2001
From: Costas Argyris <costas.argy...@gmail.com>
Date: Sat, 18 Mar 2023 14:13:21 +0000
Subject: [PATCH] Use UTF-8 active code page for Windows host.
This allows the make process on Windows to work in UTF-8 in multiple levels:
1) Accept a Makefile that is encoded in UTF-8 (with or without the BOM, since it already gets ignored anyway).
2) Accept a UTF-8 path (input -f argument) to a Makefile (that could itself be encoded in UTF-8, as per #1).
3) Launch make from a current directory that has UTF-8 characters.
and any combination of the above, since the entire make process will use UTF-8.
This is already the case in Linux-based systems, but on Windows this change is required in order to support Unicode because the "A" APIs currently used will assume the legacy system code page, destroying any UTF-8 input.
This change sets the code page to be used by the "A" APIs to the UTF-8 code page, thereby eliminating the need to update all calls of "A" functions to "W" functions to support Unicode.
That is, the source code can stay the same with the "A" functions, but instead of them using the legacy code page they will be using the UTF-8 code page.
---
Makefile.am | 10 ++++++++++
configure.ac | 5 +++++
src/w32/utf8.manifest | 8 ++++++++
src/w32/utf8.rc | 3 +++
4 files changed, 26 insertions(+)
create mode 100644 src/w32/utf8.manifest
create mode 100644 src/w32/utf8.rc
diff --git a/Makefile.am b/Makefile.am
index c29c235..60a4e5b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -46,6 +46,8 @@ w32_SRCS = src/w32/pathstuff.c src/w32/w32os.c src/w32/compat/dirent.c \
src/w32/subproc/misc.c src/w32/subproc/proc.h \
src/w32/subproc/sub_proc.c src/w32/subproc/w32err.c
+w32_utf8_SRCS = src/w32/utf8.rc src/w32/utf8.manifest
+
vms_SRCS = src/vms_exit.c src/vms_export_symbol.c src/vms_progname.c \
src/vmsdir.h src/vmsfunctions.c src/vmsify.c
@@ -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
diff --git a/configure.ac b/configure.ac
index cd78575..8cbf986 100644
--- a/configure.ac
+++ b/configure.ac
@@ -444,6 +444,7 @@ AC_SUBST([MAKE_HOST])
w32_target_env=no
AM_CONDITIONAL([WINDOWSENV], [false])
+AM_CONDITIONAL([HAVE_WINDRES], [false])
AS_CASE([$host],
[*-*-mingw32],
@@ -451,6 +452,10 @@ AS_CASE([$host],
w32_target_env=yes
AC_DEFINE([WINDOWS32], [1], [Build for the WINDOWS32 API.])
AC_DEFINE([HAVE_DOS_PATHS], [1], [Support DOS-style pathnames.])
+ # Windows host tools.
+ # If windres is available, make will use UTF-8.
+ AC_CHECK_TOOL([WINDRES], [windres], [:])
+ AM_CONDITIONAL([HAVE_WINDRES], [test "$WINDRES" != ':'])
])
AC_DEFINE_UNQUOTED([PATH_SEPARATOR_CHAR],['$PATH_SEPARATOR'],
diff --git a/src/w32/utf8.manifest b/src/w32/utf8.manifest
new file mode 100644
index 0000000..dab929e
--- /dev/null
+++ b/src/w32/utf8.manifest
@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
+ <application>
+ <windowsSettings>
+ <activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings";>UTF-8</activeCodePage>
+ </windowsSettings>
+ </application>
+</assembly>
diff --git a/src/w32/utf8.rc b/src/w32/utf8.rc
new file mode 100644
index 0000000..62bdbdc
--- /dev/null
+++ b/src/w32/utf8.rc
@@ -0,0 +1,3 @@
+#include <winuser.h>
+
+CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "utf8.manifest"
--
2.30.2
