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

Does this support require Make to be linked against the UCRT run-time library, or does it also work with the older MSVCRT? I haven't found anything explicitly mentioned about this in the official doc: https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page Also, it i

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

On Sun, 2023-03-19 at 13:42 +, Costas Argyris wrote: > I cross-compiled Make for Windows using gcc (mingw-w64) and the > autoconf + automake + configure + make approach, so it clearly worked > for me, but I didn't imagine that this wasn't the standard way to > build for Windows host. There is

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

On Sat, 2023-03-18 at 16:37 +, Costas Argyris wrote: > The attached patch incorporates the UTF-8 manifest into the build > process of GNU Make when hosted on Windows, and forces the > built executable to use UTF-8 as its active code page, solving all > problems shown above because this has a gl

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

> From: Costas Argyris > Date: Sun, 19 Mar 2023 13:42:52 + > Cc: bug-make@gnu.org > > Does this support require Make to be linked against the UCRT > run-time library, or does it also work with the older MSVCRT? > > I haven't found anything explicitly mentioned about this in the official > do

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

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sun, 19 Mar 2023 10:27:16 -0400 > > Other people (like Eli who is the primary maintainer of GNU Make for > Windows) have other environments and do more vigorous testing. But I > don't believe Eli uses autotools on Windows, either. I do use autot

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

> From: Paul Smith > Date: Sun, 19 Mar 2023 10:32:36 -0400 > > It would be nice if there was a regression test or two created that > would show this behavior. If we add tests for this feature (and I agree it's desirable), we should generate the files with non-ASCII names for those tests as part

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

On Sun, 2023-03-19 at 16:47 +0200, Eli Zaretskii wrote: > If we add tests for this feature (and I agree it's desirable), we > should generate the files with non-ASCII names for those tests as > part of the test script, not having them ready in the repository and > the tarball. Agreed for sure; plu

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

> Date: Sun, 19 Mar 2023 16:38:08 +0200 > From: Eli Zaretskii > Cc: bug-make@gnu.org > > > From: Costas Argyris > > Date: Sun, 19 Mar 2023 13:42:52 + > > Cc: bug-make@gnu.org > > > > Also, since the above experiments seem to suggest that we are not > > dropping existing support for non-ASCI

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

OK, but how is the make.exe you produced built? I actually did what you suggested but was somewhat confused with the result.Usually I do this with 'ldd', but both msvcrt.dll and ucrtbase.dll show up in 'ldd make.exe' output, and I wasn't sure what to think of it. However, your approach with o

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

> From: Costas Argyris > Date: Sun, 19 Mar 2023 16:34:54 + > Cc: bug-make@gnu.org, psm...@gnu.org > > > OK, but how is the make.exe you produced built? > > I actually did what you suggested but was somewhat confused with the > result.Usually I do this with 'ldd', but both msvcrt.dll and

[bug #63856] .WAIT does not work as special target on command line.

Additional Item Attachment, bug #63856 (project make): File name: sv63856_fix2_part1.diffSize:11 KB File name: sv63856_fix2_part2.diffSize:15 KB

[bug #63856] .WAIT does not work as special target on command line.

Follow-up Comment #2, bug #63856 (project make): Paul, please disregard sv63856_part1.diff and sv63856_part2.diff. sv63856_fix2_part1.diff and sv63856_fix2_part2.diff contain updated versions of this fix. ___ Reply to this item at:

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

That's not a good experiment, IMO: the only non-ASCII character here is U+274E, which has no case variants. And the characters whose letter-case you tried to change are all ASCII, so their case conversions are unaffected by the locale. OK I think this is a better one, it is using U+03B2 and U+039

Two 'make -p' timestamp issues

In some unusual, timing-dependent cases on some platforms, 'make -p' can generate output that incorrectly makes it look like the system clock ran backwards, when it didn't. Also, there's a torture-test case (system clock in the far past or future) where 'make -p' can dump core. Proposed patc