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: Tue, 11 Apr 2023 12:01:20 +0100

Thank you both for your input.

I think you should move the assignment of UTF8OBJ out of the if-
statement here, and only put the update of make_LDADD into the if-
statement.  That should be sufficient to have make ignore that target,
if there's no WINDRES available.


I'll make that change, thanks.

I will say that I think this is at the very edge of what we can accept
without copyright assignment.  If this change gets larger, or if you
want to contribute more in the future, we'll need to have paperwork.


I think this change will get larger, because of Eli's suggestion:

Being able to know whether UTF-8 is supported or not is a valid
concern.  How about adding this information to what "make --version"
shows?


I agreed with that suggestion and proposed a plan, but didn't receive
final confirmation on it.

As far as I can tell, the only scenario where GNU Make is not built
with UTF-8 is if it gets built with tcc, which doesn't have a resource
compiler.    Both gcc and msvc have resource compilers (gcc through
binutils which gcc depends on anyway).    But since tcc is a supported
compiler as well, and we don't want to break it for the sake of UTF-8,
then we must provide users with a way to tell if Make was built with
UTF-8 support or not.

I think outputting this info can be as simple as adding a call to GetACP
in some appropriate place in the source code.    Note that this is going
to be a windows-specific call.    If you can point me at some candidate
locations in the source code for adding that call, it would greatly speed
things up.    Otherwise I would just try to find where the --version output
is computed and try and add a windows-specific branch somewhere
there.

There is one more complication about this: As we have stated before,
this work only has a positive effect on Windows Version 1903 or later.
Earlier versions will still work, but won't get UTF-8.    So would it make
any sense if we reported UTF-8 in --version for versions of Windows
earlier than 1903?    Perhaps the check should include both Windows
version and GetACP - thoughts?

If that change is made, which sounds like it will, this will push us over
the edge it seems, thereby requiring paperwork.

To summarize, I think the list of things do be done is:

1) Make build optional with respect to UTF-8:    If windres is available,
use it, if not, just build without UTF-8 support (current behavior).
2) Implement Paul's suggestion above to avoid having an empty target
if HAVE_WINDRES is not set.
3) Add active code page used in "make --version" output, for Windows.
Potentially also check Windows version.
4) Can we officially forget about bringing the UTF-8 changes to Basic.mk?
As I have said before, I haven't managed to build using these Makefiles.
Actually, having the code page output by --version would greatly help with
this as well - if one built GNU Make using Basic.mk, they wouldn't get
UTF-8 support but this would still be readable in --version so no surprises.

If we all agree on that list, I can make these changes when I find some
time and post the updated patch.    Once we have the patch approved,
we can start on the paperwork before actually committing anything.

Does that sound reasonable?

Thanks,
Costas

On Sat, 8 Apr 2023 at 05:32, Paul Smith <psmith@gnu.org> wrote:
On Fri, 2023-04-07 at 08:29 -0400, Paul Smith wrote:
> > Also, I'm still waiting for Paul to approve the changes to Posix
> > configury part of your patch.
>
> Sorry I will make every effort to get to it today.

The configure part looks OK to me.  This change to Makefile.am seems
not quite correct to me however:

@@ -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

Here if HAVE_WINDRES is not set, then UTF8OBJ is empty, and you create
a recipe with an empty target.  Now, this works in GNU Make (and is
ignored) but some other versions of make may not like it.

I think you should move the assignment of UTF8OBJ out of the if-
statement here, and only put the update of make_LDADD into the if-
statement.  That should be sufficient to have make ignore that target,
if there's no WINDRES available.

After that if Eli is happy with it he can push it to Git.

I will say that I think this is at the very edge of what we can accept
without copyright assignment.  If this change gets larger, or if you
want to contribute more in the future, we'll need to have paperwork.

Thanks for your contribution to GNU Make!

reply via email to

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