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

[Costas Argyris]

Just checking to see if there is still interest in this feature.

On Thu, 18 May 2023 at 17:49, Costas Argyris <costas.argyris@gmail.com> wrote:

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 <costas.argyris@gmail.com> 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 <eliz@gnu.org> wrote:

> From: Paul Smith <psmith@gnu.org>
> 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.