Just some comments on the non-configury questions: 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. Most of the files under src/w32/ don't repeat the 'w32' in their name, but some do, so I can see this going either way. Finally, would we want to install the manifest file together with the executable, and if so, should its installation name be make.exe.manifest? I think the answer here is 'no'. The manifest file gets embedded in the executable, so it is literally part of it, so there is no need to have it next to it as a separate file. In fact, that is the strong point of this approach, that the manifest gets embedded at build time so the user doesn't know or see anything about it and Make just works in UTF-8 encoding. Having embedded the manifest in the executable, I am not even sure if it's a good idea to repeat the manifest by having it next to the executable as a separate file (I guess Windows just ends up ignoring it anyway). On the remaining work: I have started to do some work on bringing the changes over to build_w32.bat. This is much simpler than the configure approach so it shouldn't take long, I do have a couple general questions though: 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). 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? On Sat, 25 Mar 2023 at 12:09, Eli Zaretskii <e...@gnu.org> wrote: > > From: Costas Argyris <costas.argy...@gmail.com> > > Date: Tue, 21 Mar 2023 15:08:52 +0000 > > Cc: bug-make@gnu.org, Paul Smith <psm...@gnu.org> > > > > > 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). > > OK. > > Paul, I'd appreciate your review as well, as I'm less familiar with > the Posix configury of Make, and could easily miss some subtle issue. > > Looking at the patch now, I have a few minor comments: > > > --- 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'], > > I think instead of using "if HAVE_WINDRES" it would be better to have > UTF8OBJ to be computed by configure, leaving it empty on builds that > don't target Windows. That's because AC_CHECK_TOOL test for 'windres' > might not be the bets future proof text: users could have that > installed for reasons unrelated to the build target. > > If my suggestion is accepted, the make_LDADD addition will not be > needed; instead make_LDADD will always mention $(UTF8OBJ), and the > value will be empty when not building for Windows. > > Also, I'd name the files slightly differently, something like > w32-utf8.*, to make their relation to Windows more evident. > > Finally, would we want to install the manifest file together with the > executable, and if so, should its installation name be > make.exe.manifest? >
