Just checking to see if there is still interest in this feature.
On Thu, 18 May 2023 at 17:49, Costas Argyris
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 buil
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
> explan
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,
023-05-17 at 22:55 +0100, Costas Argyris wrote:
> > From a quick search there appear to be many ways
> > to do this, but some of them are GNU Make-specific,
> > and I believe these Makefiles (Basic.mk and those
> > included by it) have to work with any Make, not just
res --version'.
But I'm not sure how this is best done from within a
Makefile that has to be processed on Windows by
any Make program.
On Wed, 17 May 2023 at 19:34, Costas Argyris
wrote:
> Here is the patch with the Basic.mk.template and mk/Windows32.mk
> changes.I tried to keep most of th
no need to
worry about the fact that it doesn't ship with windres.
MSVC always has its own resource compiler available.
If you still need the check for windres for the gcc case, please let me
know.
On Wed, 17 May 2023 at 14:10, Paul Smith wrote:
> On Wed, 2023-05-17 at 12:47 +0100, Cos
t
Basic.mk is an untracked file which is listed in .gitignore, so how
would you like me to show you these latest changes?
On Tue, 16 May 2023 at 19:05, Costas Argyris
wrote:
> Thanks for that info - I tried doing exactly as you said and I'd say I'm
> almost there, except for the final lin
-15 at 17:48 +0100, Costas Argyris wrote:
> > 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
> > 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 /
e in a version of Windows earlier
than 1903 and the --version output returned the local code page
(not UTF-8), which is what Eli was expecting, so no surprises there.
Please let me know what you think about this patch.
Thanks
On Tue, 11 Apr 2023 at 14:56, Eli Zaretskii wrote:
> > From: Co
903, it shouldn't
return UTF-8 because this functionality is not supported in that version.
But yes, I will make sure to check this in practice.
On Tue, 11 Apr 2023 at 14:46, Eli Zaretskii wrote:
> > From: Costas Argyris
> > Date: Tue, 11 Apr 2023 14:42:30 +0100
> > Cc: bug-mak
t down to check it later when I have the implementation.
If Paul is also OK with forgetting about Basic.mk for UTF-8 support,
sounds like we have a plan.
On Tue, 11 Apr 2023 at 13:29, Eli Zaretskii wrote:
> > From: Costas Argyris
> > Date: Tue, 11 Apr 2023 12:01:20 +0100
> > Cc:
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,
Hi and sorry to bother you again.
I haven't received any response so
I was wondering if there is still
interest in doing this.
On Tue, 28 Mar 2023, 17:43 Costas Argyris, wrote:
> Being able to know whether UTF-8 is supported or not is a valid
> concern. How about adding this infor
requests to install something
they did well without previously. Some would consider this a
regression.
Makes sense, see above response.
On Tue, 28 Mar 2023 at 12:22, Eli Zaretskii wrote:
> > From: Costas Argyris
> > Date: Mon, 27 Mar 2023 23:04:52 +0100
> > Cc: bug-make@gnu.org
&g
, Paul Smith wrote:
> I apologize for being incommunicado: for the last week I've been
> fighting the mother of all head colds. The only good thing I can say
> about it is that it was not COVID.
>
> I'm sort of back on my feet.
>
>
> On Sat, 2023-03-25 at 23:12 +00
ter branch of the Git repo (disabling the
maintainer mode when building allowed me to build
from Git by not turning warnings into errors).
On Sat, 25 Mar 2023 at 13:36, Eli Zaretskii wrote:
> > From: Costas Argyris
> > Date: Sat, 25 Mar 2023 13:19:00 +
> > Cc: psm.
d for UTF-8 for
both toolchains?
On Sat, 25 Mar 2023 at 12:09, Eli Zaretskii wrote:
> > From: Costas Argyris
> > Date: Tue, 21 Mar 2023 15:08:52 +
> > Cc: bug-make@gnu.org, Paul Smith
> >
> > > You can submit diffs against the last released version here as
, Paul Smith wrote:
> On Tue, 2023-03-21 at 12:52 +0000, Costas Argyris wrote:
> > When trying from git, which was my first attempt, I was getting
> > compilation warnings which were turning themselves into errors,
> > so I never managed to build.
> >
> > When
/cgit/make.git/tree/maintMakefile
On line 32 it sets -Werror so I think that's what I am facing.
In that case, as I said, my patch was already from the 4.4.1 tarball
so it should be OK.
On Tue, 21 Mar 2023 at 13:32, Eli Zaretskii wrote:
> > From: Costas Argyris
> > Date: Tue, 21 Ma
it detects the toolchain etc, so I may need some help to speed
things up.But definitely planning to do so in the coming days, or
weekend at worst.
On Tue, 21 Mar 2023 at 03:23, Eli Zaretskii wrote:
> > From: Costas Argyris
> > Date: Mon, 20 Mar 2023 21:47:27 +
> > Cc: bug-
, Eli Zaretskii wrote:
> > From: Costas Argyris
> > Date: Mon, 20 Mar 2023 14:58:39 +
> > Cc: bug-make@gnu.org, Paul Smith
> >
> > Still my concern would be: assuming that we actually learn something
> > from this test, how would we know:
> >
&g
) Which of the above (#2) set of functions could be called with UTF-8
input that would cause them to break?
On Mon, 20 Mar 2023 at 14:05, Eli Zaretskii wrote:
> > From: Costas Argyris
> > Date: Mon, 20 Mar 2023 13:45:14 +
> > Cc: bug-make@gnu.org, Paul Smith
> >
&g
to
work in UTF-8 for free it seems.
On Mon, 20 Mar 2023 at 14:05, Eli Zaretskii wrote:
> > From: Costas Argyris
> > Date: Mon, 20 Mar 2023 13:45:14 +
> > Cc: bug-make@gnu.org, Paul Smith
> >
> > > That's most probably because $(wildcard) calls a Win32 API th
potential
blocking issue for Make switching to UTF-8 on Windows by embedding the
UTF-8 manifest at build time.
On Mon, 20 Mar 2023 at 11:54, Eli Zaretskii wrote:
> > From: Costas Argyris
> > Date: Sun, 19 Mar 2023 21:25:30 +
> > Cc: bug-make@gnu.org, Paul Smith
> &g
thing more.
This advice is for how to use UTF-8 in the C runtime if you don't have
ACP == UTF-8.
The Unicode -W APIs are different compared to the -A APIs in that
they don't even look at the current ANSI code page, they just use UTF-16.
On Sun, 19 Mar 2023 at 17:01, Eli Zaretskii wrote:
> >
rc.c exists
If anything, it could be worth a mention in the doc.
On Sun, 19 Mar 2023 at 14:38, Eli Zaretskii wrote:
> > From: Costas Argyris
> > Date: Sun, 19 Mar 2023 13:42:52 +
> > Cc: bug-make@gnu.org
> >
> > Does this support require Make to be linked a
ndows?
Assuming all questions are answered first, would it be OK to work on the
build_w32.bat changes in a second separate patch, and keep the first one
focused only on the Unix-like build process?
Thanks,
Costas
On Sun, 19 Mar 2023 at 06:44, Eli Zaretskii wrote:
> > From: Costas Argyris
>
Hi
This is a proposed patch to enable UTF-8 support in GNU Make running on
Windows host.
Today, the make process on Windows is using the legacy system code page
because of the "A" functions called in the source code.This means that
any UTF-8 input to make on Windows will break.A few
29 matches
Mail list logo
