Re: [PATCH] Use UTF-8 active code page for Windows host.
Please find attached the latest patch with everything done so far, including the inconsistency I mentioned in my previous email. This now has all 3 build approaches, namely: 1) configure 2) Basic.mk 3) build_w32.bat treating the resource compiler optionally, and building and embedding the UTF-8 resource if it is found.This applies for all supported compilers. I think this has everything discussed and agreed so far. Please let me know what you think. On Thu, 18 May 2023 at 12:38, Costas Argyris wrote: > I think this should be added to README.git. Without these > explanations, the purpose of Basic.mk and its auxiliary files, and of > their intended usage, is completely unclear. > > I believe this was going to Paul.From my side, these explanations > were really helpful. > > On to the Basic.mk patch, please see the latest one attached in this email. > > After regenerating Basic.mk from .\bootstrap.bat, I tried running it with > both msvc and gcc values for TOOLCHAIN and they both worked fine. > > I also tried the 'no resource compiler' case by temporarily renaming > 'rc.exe' (msvc) and 'windres.exe' (gcc) to something else so they are > not found on the Windows path, and the build just went through with > no errors and produced non-utf8 GNU Make binaries. > > As you will see, in mk/Windows32.mk I used: > > ifneq (, $(shell where $(RC) 2>nul)) > > to tell if a program is on the Windows path.It seems to be working fine > in both cases of 'found' and 'not-found', but I am no GNU Make expert so > please let me know if this is correct. > > A little inconsistency is that in build_w32.bat I didn't implement a check > for 'rc.exe' because I assumed it's always going to be in the Windows > path if the compiler 'cl.exe' is, but in mk/Windows32.mk I did implement > the check even for 'rc.exe' - I can add the check in build_w32.bat to be > consistent in a next update, it should be easy. > > Also just checking - the configury approach, when building for Windows > host, can't be used with msvc or tcc, right?It needs to find gcc > targeting Windows, and therefore checking for windres (already > implemented) should be sufficient, right? > > On Thu, 18 May 2023 at 06:31, Eli Zaretskii wrote: > >> > From: Paul Smith >> > Cc: bug-make@gnu.org >> > Date: Wed, 17 May 2023 18:04:55 -0400 >> > >> > To remind: the purpose of these is to provide a makefile-based way to >> > _develop_ GNU Make itself, on platforms where we can't run ./configure >> > to get an automake-generated makefile. >> > >> > If you need to build GNU Make from scratch there's not much benefit >> > from using Basic.mk, because it will just rebuild everything every time >> > just like the build_w32.bat etc. files. You don't save anything. >> > >> > But if you're doing ongoing development (edit/build/test cycle) and you >> > don't want to have to recompile all files every time you change >> > something, and you can't run ./configure, then you can use an already- >> > built GNU Make and these makefiles to shorten your development cycle. >> >> I think this should be added to README.git. Without these >> explanations, the purpose of Basic.mk and its auxiliary files, and of >> their intended usage, is completely unclear. >> > From f7d5cf83e5ceaa0d008f9b6b0e57d05ec541ef9a Mon Sep 17 00:00:00 2001 From: Costas Argyris Date: Sat, 25 Mar 2023 21:51:41 + Subject: [PATCH] Add UTF-8 resource when building for Windows host, if a resource compiler is available. As a result, the produced GNU Make Windows executable will use UTF-8 as its ANSI code page, enabling it to work with UTF-8 encoded Makefiles, understand UTF-8 paths passed to it, etc. These build process changes apply to all 3 ways that GNU Make can be built for Windows: 1) configure 2) Basic.mk 3) build_w32.bat When building with VS the resource compiler should always be available. When building with GCC or TCC, it depends on the availability of 'windres'. If a resource compiler is not available, don't fail the build but just proceed without the UTF-8 resource, effectively ignoring this feature. The UTF-8 resource only has an effect when GNU Make is running on a minimum target version of: Windows Version 1903 (May 2019 Update). When the built GNU Make is running on an earlier version of Windows, the embedded UTF-8 resource has no effect at all. Code page information gets added to --version output to tell users what code pages are being used by any combination of GNU Make build (with or without the UTF-8 resource) and Windows version that GNU Make is running on (earlier than 1903 or not). Signed-off-by: Costas Argyris --- .gitignore| 2 ++ Basic.mk.template | 6 -- Makefile.am | 11 +++ README.git| 2 +- build_w32.bat | 46 --- configure.ac | 5 + mk/Windows32.mk | 17 src/main.c| 5 + src/w32/utf8.manifest | 8
Re: [PATCH] Use UTF-8 active code page for Windows host.
I think this should be added to README.git. Without these explanations, the purpose of Basic.mk and its auxiliary files, and of their intended usage, is completely unclear. I believe this was going to Paul.From my side, these explanations were really helpful. On to the Basic.mk patch, please see the latest one attached in this email. After regenerating Basic.mk from .\bootstrap.bat, I tried running it with both msvc and gcc values for TOOLCHAIN and they both worked fine. I also tried the 'no resource compiler' case by temporarily renaming 'rc.exe' (msvc) and 'windres.exe' (gcc) to something else so they are not found on the Windows path, and the build just went through with no errors and produced non-utf8 GNU Make binaries. As you will see, in mk/Windows32.mk I used: ifneq (, $(shell where $(RC) 2>nul)) to tell if a program is on the Windows path.It seems to be working fine in both cases of 'found' and 'not-found', but I am no GNU Make expert so please let me know if this is correct. A little inconsistency is that in build_w32.bat I didn't implement a check for 'rc.exe' because I assumed it's always going to be in the Windows path if the compiler 'cl.exe' is, but in mk/Windows32.mk I did implement the check even for 'rc.exe' - I can add the check in build_w32.bat to be consistent in a next update, it should be easy. Also just checking - the configury approach, when building for Windows host, can't be used with msvc or tcc, right?It needs to find gcc targeting Windows, and therefore checking for windres (already implemented) should be sufficient, right? On Thu, 18 May 2023 at 06:31, Eli Zaretskii wrote: > > From: Paul Smith > > Cc: bug-make@gnu.org > > Date: Wed, 17 May 2023 18:04:55 -0400 > > > > To remind: the purpose of these is to provide a makefile-based way to > > _develop_ GNU Make itself, on platforms where we can't run ./configure > > to get an automake-generated makefile. > > > > If you need to build GNU Make from scratch there's not much benefit > > from using Basic.mk, because it will just rebuild everything every time > > just like the build_w32.bat etc. files. You don't save anything. > > > > But if you're doing ongoing development (edit/build/test cycle) and you > > don't want to have to recompile all files every time you change > > something, and you can't run ./configure, then you can use an already- > > built GNU Make and these makefiles to shorten your development cycle. > > I think this should be added to README.git. Without these > explanations, the purpose of Basic.mk and its auxiliary files, and of > their intended usage, is completely unclear. > diff --git a/Basic.mk.template b/Basic.mk.template index e3a83a20..ce273a1f 100644 --- a/Basic.mk.template +++ b/Basic.mk.template @@ -59,6 +59,8 @@ BUILT_SOURCES = OBJECTS = $(patsubst %.c,$(OUTDIR)%.$(OBJEXT),$(prog_SOURCES)) +RESOURCE_OBJECTS = + OBJDIRS = $(addsuffix .,$(sort $(dir $(OBJECTS # Use the default value of CC @@ -99,7 +101,7 @@ RM.cmd = rm -f $1 # $(call CP.cmd,,) CP.cmd = cp $1 $2 -CLEANSPACE = $(call RM.cmd,$(OBJECTS) $(PROG) $(BUILT_SOURCES)) +CLEANSPACE = $(call RM.cmd,$(OBJECTS) $(RESOURCE_OBJECTS) $(PROG) $(BUILT_SOURCES)) # Load overrides for the above variables. include $(firstword $(wildcard $(SRCDIR)/mk/$(lastword $(subst -, ,$(MAKE_HOST)).mk))) @@ -108,7 +110,7 @@ VPATH = $(SRCDIR) all: $(PROG) -$(PROG): $(OBJECTS) +$(PROG): $(OBJECTS) $(RESOURCE_OBJECTS) $(call LINK.cmd,$^) $(OBJECTS): $(OUTDIR)%.$(OBJEXT): %.c diff --git a/mk/Windows32.mk b/mk/Windows32.mk index 57226eb1..6e357ea7 100644 --- a/mk/Windows32.mk +++ b/mk/Windows32.mk @@ -30,6 +30,8 @@ P2W = $(subst /,\,$1) prog_SOURCES += $(loadavg_SOURCES) $(glob_SOURCES) $(w32_SOURCES) +utf8_SOURCES = $(src)w32/utf8.rc $(src)w32/utf8.manifest + BUILT_SOURCES += $(lib)alloca.h $(lib)fnmatch.h $(lib)glob.h w32_LIBS = kernel32 user32 gdi32 winspool comdlg32 advapi32 shell32 ole32 \ @@ -41,6 +43,7 @@ LDFLAGS = # --- Visual Studio msvc_CC = cl.exe +msvc_RC = rc.exe msvc_LD = link.exe msvc_CPPFLAGS = /DHAVE_CONFIG_H /DMK_OS_W32=1 /DWIN32 /D_CONSOLE @@ -54,6 +57,7 @@ msvc_LDFLAGS = /nologo /SUBSYSTEM:console /PDB:$(BASE_PROG).pdb msvc_LDLIBS = $(addsuffix .lib,$(w32_LIBS)) msvc_C_SOURCE = /c +msvc_RC_SOURCE = msvc_OUTPUT_OPTION = /Fo$@ msvc_LINK_OUTPUT = /OUT:$@ @@ -68,6 +72,7 @@ debug_msvc_LDFLAGS = /DEBUG # --- GCC gcc_CC = gcc +gcc_RC = windres gcc_LD = $(gcc_CC) release_gcc_OUTDIR = ./GccRel/ @@ -79,6 +84,7 @@ gcc_LDFLAGS = -mthreads -gdwarf-2 -g3 gcc_LDLIBS = $(addprefix -l,$(w32_libs)) gcc_C_SOURCE = -c +gcc_RC_SOURCE = -i gcc_OUTPUT_OPTION = -o $@ gcc_LINK_OUTPUT = -o $@ @@ -87,6 +93,7 @@ release_gcc_CFLAGS = -O2 # --- +RES_COMPILE.cmd = $(RC) $(OUTPUT_OPTION) $(RC_SOURCE) $1 LINK.cmd = $(LD) $(extra_LDFLAGS) $(LDFLAGS) $(TARGET_ARCH) $1 $(LDLIBS) $(LINK_OUTPUT) CHECK.cmd = cmd /c cd tests \& .\run_make_tests.bat -make ../$(PROG) @@ -96,9 +103,11 @@ RM.cmd
