bug-make
[Top][All Lists]
Advanced

[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: Mon, 15 May 2023 17:48:29 +0100

> > On Tue, 2023-04-11 at 15:29 +0300, Eli Zaretskii wrote:
> > > I agree with the list.  As for Basic.mk, we can forget about it
> > > from my POV.  Paul should make the call, but from my POV that
> > > file was unmaintained and therefore unsupported.
> >
> > Why do we think it's unmaintained / unsupported?
>
> Because I never use it when building the MinGW port of Make.

I see.  I never use MinGW, as I don't have it installed.  The Basic.mk
model is only useful for systems where you can't run configure and
generate a Makefile that way.  For systems where configure can't be
invoked it provides a makefile framework (versus a bat file) that can
be used if you already have a previous GNU Make available (or once you
build one once with the bat file).


As I have said before, I wasn't successful in getting the Basic.mk
approach to work on Windows, as I was getting various errors all
over the place.    They started with CC being undefined, but even
after I defined it to 'gcc' this just took me to various link errors, at
which point I thought that this approach is not really maintained.
That was in contrast with the other two approaches on Windows
host, namely configure and .bat file, both of which worked as
expected.

So my question now is:    Is the Basic.mk approach a mandatory
prerequisite for the UTF-8 feature?    Do the UTF-8 build changes
for Windows host have to be extended over there as well, or can
we do without it, and say that a UTF-8 build for Windows works
only with the configure and .bat file approaches (assuming there
is a resource compiler available, of course).

Note that, as agreed, in the latest patch I made the resource
compiler (and hence building with UTF-8 manifest) optional, and
added this information to --version output.    This means that even
if Basic.mk doesn't support the UTF-8 feature, the user would
still know it by means of --version.    That would be the same as
if one of the other approaches was used and there was no
resource compiler available (gcc or tcc without windres on the
path).

So, can this feature proceed without changes in Basic.mk?

On Sat, 6 May 2023 at 19:54, Paul Smith <psmith@gnu.org> wrote:
On Sun, 2023-04-30 at 17:27 +0300, Eli Zaretskii wrote:
> > From: Paul Smith <psmith@gnu.org>
> > From: Paul Smith <psmith@gnu.org>Date: Sun, 30 Apr 2023 09:55:55 -
> > 0400
> >
> > On Tue, 2023-04-11 at 15:29 +0300, Eli Zaretskii wrote:
> > > I agree with the list.  As for Basic.mk, we can forget about it
> > > from my POV.  Paul should make the call, but from my POV that
> > > file was unmaintained and therefore unsupported.
> >
> > Why do we think it's unmaintained / unsupported?
>
> Because I never use it when building the MinGW port of Make.

I see.  I never use MinGW, as I don't have it installed.  The Basic.mk
model is only useful for systems where you can't run configure and
generate a Makefile that way.  For systems where configure can't be
invoked it provides a makefile framework (versus a bat file) that can
be used if you already have a previous GNU Make available (or once you
build one once with the bat file).

reply via email to

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